iPhone devsugar: The need for multiple ipa delivery

App Store clutter remains an ongoing issue. In addition to "business card" applications that offer little or no functionality beyond a simple web page^[1], there are lite editions, demo editions, full editions, and even in the case of Tweetie 2, completely new applications providing upgraded functionality.

Each of those applications must be registered with a unique app identifier, each one takes up a separate slot when installed on your iPhone's home screen, each application occupies a separate App Store listing, complete with its own screen shots, marketing material, reviews, and so forth. Each one must be managed by you in iTunes, where you must decide which to sync, which to keep, and so forth.

Add to the mix, the possibility that we're likely to see iPad- and iPhone-specific application releases in the near future in addition to the Universal Application solution that Apple has been heavily promoting. That's because iPad applications offer developers the opportunity to re-imagine their interfaces, adding features without the constraints of the iPhone's small screen and modal interaction limitations. An iPad app that adds significant new functionality may branch off and become yet another related app in a single application family.

Together, this means that an application family might include four or more applications: free versions, paid version, device-specific versions, and various upgrade options, all of which offer a single branding and some core overlap of features, despite differences in price and platform.

In my recent write-up, I proposed that Apple might be able to consolidate many versions of an application into a single product using multiple iPhone application files, aka a "multi-ipa" solution. Each component of this family would install to the same application slot and would use the same application identifier, that code that every developer must register with Apple. An application's identifier uniquely identifies each iPhone OS product to the device it lives on and to the App Store ecosystem.

The way I picture this working is this. Each member of a multi-ipa family would have a built in priority, specified in the bundle's Info.plist. That's the file that tells iPhone OS how the application bundle fits into the operating system. It works the same way that Info.plist files work on Mac OS X. In this case, the ipa with the highest priority gets installed. It's iTunes that makes the final call.

So imagine if a person downloads a free, iPhone-only demo version of a game and then later upgrades to a full-featured paid version. The paid version's higher priority wins out against the free versions, so iTunes knows to install the paid ipa into the same slot that the free version currently occupies. Right now, that doesn't happen. You end up using two slots and two application identifiers. Should a person then buy an iPad upgrade to this app (assuming here that it's not a universal application), then iTunes will sync the iPad-specific ipa to their iPad device rather than the iPhone version, eliminating any need to use pixel doubling to play the game.

As I previously wrote, Apple could offer a "Complete my App" feature to allow customers to buy the iPad-specific enhancements only when and if they eventually buy an iPad device. This approach depends on iTunes storing more than one version of the application, i.e. multiple ipa archive files, so that it can sync the best match to each device.

In each of these cases, it's iTunes that decides which ipa to install. The multiple ipa delivery system allows separate versions of the same application to coexist in the iTunes Mobile Applications folder. The latest, best-featured and most device-specific version always wins.

For Apple, for developers, and for consumers, there's pressure to both consolidate these families of apps and, at the same time, there's reasons to keep them separate. Both Apple and consumers win when just one listing and one device slot are dedicated to what is, essentially, a single application with multiple expressions of itself. App Store instantly declutters to a great degree; a single listing now takes care of both free and paid versions.

Developers may resist this. In the case of lite/demo and paid apps, split-personality multiple-listing can be a blessing for developers. Negative reviews for free applications can be mitigated by providing a completely separate product, whose reviews are culled only from paid customers.

That's been a big part of many developers' decisions not to migrate to in-app purchases, where the same app can exist in both demo and paid mode. With in-app purchase, users try out the application and, if they like what they use, can unlock the full version from within the demo app itself. Unless Apple offers some kind of free-version review block, developers will rationally keep picking the latter choice and design separate products for free and full versions. Apple, of course, can change its policy on this practice any time it chooses.

Paid upgrades are, on the other hand, a consolidation win for developers. One thing we do know for sure, Apple is likely to introduce paid upgrades in the near future. Existing customers can upgrade for a small fee; new customers must buy in at the full price. Admittedly, consumers who bought earlier app versions, believing they had bought in "for life" to all future innovations are going to be displeased to realize that a buy once, upgrade forever business model is unsustainable. It's a tempest that App Store is simply going to have to weather. Just don't expect customers to be happy about it.

So what's your take on this? Do you think Apple should go full-out in consolidating apps together? Or should they continue to allow separate trial and paid versions? Do you think the notion of a separate iPhone and iPad purchase has a future? Or will Apple push ahead with a priority on Universal application delivery? What do you think is the direction that App Store will be taking on these issues? Let us know in the comments.

^[1]Apple is, even now, in the process of house-cleaning those applications to trim down App Store bloat