If you have a lot of apps installed, which are likely to produce lots of updates, I think most people would develop selective blindness towards those badge notifications, and would postpone the updates.
Another way to notify the users about an update available for a given app is to send a more vocal push notification (text alert, maybe with sound), assuming that the user agreed to receive such notifications. That may however be perceived as too pushy (or desperate), and that may be why people developed a more elegant way of notifying about updates, in a more appropriate context, which increases the chance of people acting on them. That's by simply showing the notifications when people are launching the old app, like so:
That makes sense, because now the end users are in a context where they demonstrate engagement with the app (they just started it) and the notifications have less chance to be perceived as off-putting. So this is a design idiom that makes sense to be followed.
In some instances the notifications must go further in providing more details about the upcoming update, and possibly assist the user with the upgrade. One such scenario is, for example, if the user moves an app that was initially a stand-alone app, with its own icon on the home screen, to the Newsstand. In that case the icon on the home screen would disappear and a cover corresponding to that app would appear in the Newsstand, like so:
That move has the potential to confuse people, and a notice shown by the old app before the upgrade could clarify the new location.
Another move scenario is moving an app to another developers' account. This tends to happen when a bespoke app is first developed as an experiment, with few expectations, and it's published under the developer's account. If the app is a success, the contracting clients often want to have the app moved to their own account. This is challenging because from Apple's perspective the app in the new account becomes a brand new app, completely independent from the old one. The upgrade prompt should set clear expectations about the old app being discontinued, with all future development and support slated to go in the new one.
If the app has in-app purchasing content, care must be taken to migrate purchases made in the old app to the new one. The usual purchase restoration mechanism provided by Apple is of no use here, because Apple has no notion about the 2 apps being related. So you'll need to roll out your own purchase migration mechanism. For example, when the old app is launched, you could make a snapshot of the past purchases, upload them to a server, and produce a redeemable code that could be used in the new app to restore the purchases. If you already have another way of identifying the users, perhaps through some user account/login scheme, you can use that instead to assist the migration. In iOS 5 and later this is facilitated by the newly introduced Account framework, that allows tying separate apps to the same users through their credentials on social networks like Twitter.
Another consideration would be the transfer of the name of the app. Since there can't be 2 apps with the same name, you'll need to allocate a temporary new name, then delete or rename the old app, to free up the old name, and later apply it to the new app.
Posts
