iOS: Updating Two Single Applications to a Universal Application


I was recently working for an organisation where “The Business” (I hate that term, but I’ll stick with it throughout this article as that’s what they’re commonly referred to at said organisation) wanted to take their separate iPhone app and iPad app, and merge them to create one “universal” app for the App store. What they didn’t realise was, it’s not very easy. I’m going to try explain how I believe it can be done in a few clear steps, using XE Currency as a case study.

Going Universal:

It makes sense to go universal when beginning development for iOS. The benefits are clear. When a user searches for your company name or brand name in the App Store, only one app will be returned in search results. Once they’ve downloaded your universal application, the app can determine what device the user is on (i.e. an iPad, iPhone 4, or iPhone 3GS) and launch the correct experience. It’s also easier with a universal app to manage updates and roll out new features to all users, no matter what their device of choice is.

The Issue:

Unfortunately a lot of organisations have an issue where users will search for their app by name, via the iPad App Store app, or via iTunes, and both their iPhone and iPad apps are returned in results.* Why? They probably built their iPhone app within a year or so after the 3GS was released and the App Store was launched. Then along came the iPad, so they went and built an iPad app in a separate code base. The two apps are not related to each other in many ways, apart from the fact that they may be served from the same build box, or use the same API or something.

The organisation then tries to be clever and name their iPad app with some distinction from their existing iPhone offering, using terms like “HD” or “for iPad” in the name, but the icon, description, and features are usually very similar. This is the root cause of the issue.

The Solution:

So, when “The Business” asks to go “universal”, what can you do? Basically, it comes down to 4 steps:

  1. Identify the app with the the highest amount of downloads.
  2. Add the code from the less popular app to the code of the more popular app – this is now your universal app.
  3. Release an update of the universal app, with a new description that explains the change (update the icon and screenshots too if necessary).
  4. Update the description of the less popular app advising users to remove that current version of the app and download the new universal app, which is now available.

Why does the number of downloads for each app matter? Because the app you choose to not be the basis of your universal app will lose support over time (bug fixes, new features etc) and will therefore need to be deleted by all the users who have that version. In order to use your app again, those users will have to then search for your universal app and install again. You want to inflict that hassle on the least amount of your users as possible, hence selecting the least popular of your two apps for removal.

Case Study:

To make more sense of these steps, let’s follow them through with a real-life example: XE Currency.

Step One: Identify the app with the highest amount of downloads.

This is just a guess as I’m not involved with the XE Currency iOS team at all, but I’m fairly sure that their iPhone app will have received more downloads than their iPad app based on the number of iPhones/iPod Touch’s shipped over the last 3-4 years vs. the number of iPads over the same time period. I don’t know of many iPad app’s which have higher download numbers than their iPhone siblings.

Step Two: Add the code from the less popular app to the code of the more popular app – this is now your universal app.

The team behind XE Currency then merged the code of their less popular iPad app with the code of their more popular iPhone app.

Step Three: Release an update of the more popular (now universal) app, with a new description that explains the change (update the app’s icon and screenshots if necessary).

The XE Currency iPhone app update was then available in the App Store to all existing iPhone users, with information about their shift to universal highlighted in the update text: iPhone and iPad apps combined into universal app:

Step Four: Update the description of the less popular app, advising users to remove the current version of the app and download the new universal app, which is now available.

The XE Currency iPad app was then updated with a new description and icon, which highlights the move to universal. The description clearly states to new users that they should search and download the new universal app, with a different name, which is now available. Note the new icon’s use of an “!” to alert users of the change:

What’s Next?

Once you’ve completed the above steps, it will pay to monitor the level of usage from your now “old” app to see if people haven’t updated, or simply haven’t seen the new updates and are still carrying on their merry way. If usage carries on, it may pay to push out another update reminding users of the change – and then (depending on the level of success of the universal app) give up on them. Seriously, a line has to be drawn somewhere and you can only support two code bases etc for so long before cost outweighs the benefits.

In the future, I hope Apple makes this process easier as iOS 5 brings over the air updates which may facilitate some sort of automation around merging apps to one universal app. In the meantime, the benefits of going universal are clear and despite the short term hassle for your users (which may result in a drop in usage or a few negative tweets etc), you’re well positioned to release feature updates and bug fixes for all devices and users ongoing. There’s also the chance that Apple may release new products in the future, which will require a consolidated approach (did someone say an App Store for Apple TV?).

If you found this article useful, interesting, or disagree in any way, feel free to comment below.

*Searching the App Store on an iPhone will only return iPhone compatible apps, so the iPhone isn’t a problem scenario.


  • carl says:

    What if both the iPhone and iPad apps are paid apps. When you ask the users of the less popular to convert to the new universal App, won’t they have to buy the App again?

  • Phil says:

    As long as the user used the same App Store account info to download both apps, The App Store will pick up that the updated (now universal) app has already been purchased and is now available for download across multiple devices at no extra cost.

    Users can view all previously purchased apps within the App Store app in the Updates tab under “Purchases”. If a user has already downloaded an iPad app and it has gone universal, on their iPhone they will be able to see the app under “Purchases” and can download at no additional cost.

  • Sly says:

    Thanks a lot for this nice article.

    Does anybody have some details or is able to point me to an article how the situation looks today? Today means, we are having iOS 9 and iOS 10 in place. Has anything changed here dramatically? The question is if there is a better way to deinstall the old app and install the universal app, without explaining all the details to the user and making all the manual work.

    A second interesting questions is how to handle data that has been stored by the app locally on the device. The point is here, if the new installed universal app can access data that has been created by the old app. Fortunately this has to be solved only for device with the “lower amount of downloads”. As far as I know, there is a concept called App Groups that has been introduced with iOS 8. This approach seems to support a way to share data between different apps. Does anybody has experience with that in context of moving two apps to one universal app?

Leave a Reply

Your email address will not be published.