Back to Mobile View

Skip to Content

TUAW Deals

Should you be building universal apps for App Store?

Universal apps. They're the solution for delivering your iPhone OS application to both the iPhone and the iPad and having it run natively on each without silly make-do's like pixel doubling. It's a way to ensure that your app "fits" each platform, providing art and interfaces that match the target screen. Or, as Apple puts it, "Developers can now start planning for universal applications, allowing them to take full advantage of the technologies found on iPad, iPhone, and iPod touch with a single binary."

Right now, I've got a bug up my sleeve about the whole issue. I'm not convinced that it's the right solution for a lot of apps. Just because you *can* merge an iPhone app with an iPad app, and sell one product, you shouldn't -- unless the functionality is significantly the same for both platforms.

The thing is this: once you start programming iPad, it becomes clear that you can do things that don't make sense on the iPhone. And so your apps start to morph. They evolve to something significantly different. New features. New ways of interacting. Bigger possibilities and a much more computer-like experience, even in a mobile setting.

So at what point do you pull the plug? When do you say, I'm going to sell an iPhone version and an iPad version and they are different enough to justify the need for another purchase?

From a design and coding point of view, it's obvious that Universal Apps quickly become Frankencode. Separate projects (or, more realistically, separate targets with some shared code base and some platform-specific class files) greatly increase code readability and maintainability, even when the two projects share a great majority of features.

Consider the most Model-View-Controllerized app you can imagine. Even an app that offers glorious orthogonality between its visual design and its underlying code logic will suffer from universalization. It's just natural fallout from the conditional coding needed to deal with reality; the iPhone-based interaction modes that used to require multiple screens can now join together into simplified iPad interfaces.

I also think that developers may unnecessarily limit themselves by asking the fatal question: "How will this also work on the iPhone?" Should you be hamstringing your iPad application by forcing device iPhone limits onto its features? Do you really want to list products in App Store that state "Not all features available on the iPhone?" Sure, people who own both products will get to take advantage of those features but for a while, the vast majority of your customers will continue to be iPhone and iPod touch users. Will you be sending them the right message?

Let's not kid ourselves. From the consumer point of view, it's clear what they'll want. Consumers will not want to purchase the "same" application twice. Even if, for example, you're shipping a desktop-worthy full-featured iPad application versus a limited iPhone-style version, you're likely to alienate users if you provide the same product with (for iPad) and (for iPhone) suffixes.

Unfortunately, Apple hasn't even put the idea (let alone the realization) of a single-purchase multi-ipa solution on the table. "Multi-ipa" refers to a purchase that includes separate iPhone archive files (ipa) for iPad and for iPhone platforms. That kind of solution would offer the best of both worlds. Separate projects for the most stable coding experience with a single purchase for the best consumer experience. Being able to set price points for one or both ipas, with a "Complete my App" purchase could do a lot to let developers walk away from Universal solutions, where those universal apps don't really make as much sense as they should.

For now, don't hold your breath. Apple doesn't seem to be going in that direction.

If you end up going with two products, consider some sort of cross-promotion to lessen the financial impact. It's a little tricky to do that right now but you might be able to swing something using in-app purchases plus unique coupon ids plus non-consumable unlockables. You're showing the customer that you appreciate their purchases and loyalty but are committed to providing the best possible app experience on each platform.

For the moment, I'm leaning towards limiting Universal Apps to apps like games that provide substantially similar experiences on both platforms, although I'm certainly willing to be convinced otherwise. Add in a few iPad-specific changes where they apply, but if the two products have diverged enough that you have to put up a "Notice to iPhone users" about limited functionality, perhaps it's time to rethink your approach.

So what's your take on this? Are you planning to deliver any iPad-only applications? Or are you committed to the Universal Application route? What are the questions that developers should be asking themselves before picking one or the other? Do you think Apple might bow to pressure to provide multiple ipa delivery solutions if developers yelled loud enough? Let me know in the comments.

Thanks, Glen Aspeslagh

Universal apps. They're the solution for delivering your iPhone OS application to both the iPhone and the iPad and having it run natively...