We've got an interesting scenario, with potential confusion from two icons on a device.

We need to transition users to a newer app. Out of necessity, it is a completely new app with a new identifier - not just a new version. When they open the old app, there will be a voluntary option presented to download the new app. Users could still have the old app on their device. So I feel we need to make the app icons look distinct (though on-brand). Right now, I've proposed we add "legacy" to the old app's icon - and let the new app icon look like our existing product. Because we're not doing any rebrand we can't do an icon redesign (like photoshop products often do when we get new versions)

To which, a stakeholder suggested we add "new" to the new app icon. I don't think this is necessary because it confuses branding. There will likely be a few targeted marketing materials to also alleviate confusion - and we can also notify users in the legacy app in case they open it again, when they should really be opening the new one they downloaded.

Before I give my recommendations, I figured I'd see if someone here has run into the same thing and found effective tricks to limit this temporary confusion.

Again - I know it's best to just version our existing app - but that's not an option for business reasons irrelevant to my question.

  • How is this different to an app upgrade? Is there a real difference? Otehrwise simply upgrade the app and you won't need to do anything brand wise
    – Devin
    Commented May 22, 2023 at 23:53
  • The original app will still be available for download - separate from the new one. As I called out in my question - that is a decision with technical and business reasons behind this.
    – turpentyne
    Commented May 23, 2023 at 0:50

3 Answers 3


I've seen some examples where the old icon has its colour changed or made greyscale. For colourblind users, the old icon should have a "legacy" banner, since I suppose the new one can't keep a "new" banner forever.


A general principle is that new things should be made to look the way you will always want them to look and that old versions should be made to look different so that people will realize that the situation has changed. Leaving the old versions alone and putting "temporary" indications on the new versions is counter-productive.

When the ANSI C standard came out (renaming the index() function to be strchr()), many people made changes to code like this:

# if (test for new standard) /* doesn't provide index() function */
#    define index strchr
# endif

That way they could continue to use the old code on the "new" compilers without having to update the code.

This is the exact opposite of what they should have done, as it means that the test will have to remain there forever, the test will have to be updated for each new compiler, and the existing code will retain the deprecated (and eventually obsolete) "index". It also encourages anyone making additions to the code to continue using the obsolete name for consistency to avoid confusion if both names were used.

What they should have done is to change all the existing "index"s to "strchr", and then to add:

# if (test for old standard) /* old libraries use ancient name */
#    define strchr index
# endif

That way, the code will already be correct for all new compilers, and eventually the test and define code will no longer be needed and then can simply be removed.

Most Python documentation made the same mistake. Far too many descriptions start out like:

In Python 2 this would be done by [… long description …] and [… explanation for why this was not a good way to do it …].

and then eventually get around to:

But now Python 3 allows us to [… short simple description …].

This forces people just learning the language to read about how not to do it before they can find out how they should do it.

The correct way would have been to describe the new way, without mentioning that it's new, and then include an easily ignorable aside describing the old behaviour for those people that are familiar with the old way and want to be able to compare it with the new.

Or, for a more classic example, consider the "New College" building in Oxford, UK. It was given that name in 1379, and is still called "New College" today, nearly 700 years later, even though it is now one of the oldest college buildings at the university.

In the case of this new app, the best approach is to design the app and its logo to look how you will want them to appear for the foreseeable future. Do not even hint that there is an old version.

Change the old icon (and perhaps other parts of its interface) to indicate that they are old and that there is a much better version available.
(And then, if people aren't switching quickly enough, keep increasing the annoyance factor.)


First of all, this is a very different approach that you have built a completely new app with a new identifier instead of updating the current app but I am sure you may have your reasons. But to handle the situation, I would suggest two things.

  1. Make sure that all your users with the current app install the new app, by letting them know there is a new better version and that the older version has limited functionality or there are no future updates on that version. (Or whatever the legit reason you have for the new app. For this, I would suggest a block wall which appears when they open the app.
  2. Secondly, it's better in my opinion to write 'New' with the new app instead of writing 'Legacy' with the old version. Lots of users may not even notice or understand what message you are trying to convey but, the word 'New' is definitely going to attract everyone, since everyone wants the new and updated versions of app on their devices.

I have attached images for both of my suggestions for reference. Block screen on app open New App Icon

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.