Porting an iPhone app to iPad — single application, or fork?

Question

I have an iPhone application I am about to modify for the iPad.

My problem is: the application is designed to work for iPhone OS 2.0 and if I make it for the iPad, I will have to design it for OS 3.2.

I cannot change the iPhone version, because I risk some of my users with old versions of the iPhone not being able to run the app.

Obviously I can make an hybrid application that can work on iPad/iPhone OS 3.2 and iPhone/iPhone OS 2.0, but this will be a hell to maintain, with many API call changes and such.

Which is the best approach: a hybrid version or a separate code fork for the iPad?

Answer 1

Set your Base SDK to iPhone 3.2 Device. Set your iPhone Deployment Target to 2.0. Use AvailibilityMacros when you call iPhone 3.2 APIs. Then create the different UI code for the iPad and make a universal app. That is the best of all worlds. Except that you won't get a new purchase if the person has an iPhone and already purchased your app. If you are more interested in getting more income because of the iPad version (perhaps the iPad version has far more functionality?) Then you should fork your code so you can set a different price point for the iPad app. If I understand correctly you could always keep the fork in the same xcode project so you can still utilize the shared Models and Controllers and when you build just choose which target to build for. Thus you as a dev get the best of both worlds.

Per the admob stats: iPhone OS Statistics if your customers are only iPhone then people not in 3.0 < 3%. That's a pretty small number for me, they can easily upgrade for free so I wouldn't hold your app back just for them. Perhaps your app might convince a few more people to upgrade also. Now if your app supports iPod Touch then your target market is still 32% 2.X

Answer 2

1) Fork the code, but...

2) Create a Universal application.

Basically, make a new version that will only support OS3.2 from here on out. That single version can contain both the updated iPhone application and the new iPad application, allowing you to easily codevelop them in the future, and reuse view controllers and models between them. This is how Apple would like you to do it. Check out the docs on universal applications.

Answer 3

Fork your code. You're probably going to want a new UI or new graphics code to accommodate the larger screen anyway, so you're really looking at a "new" app that uses a lot of your existing classes.

Answer 4

Does your app have a subscription component (that is making you money after the initial purchase) or a service contract?

If the answer is no, I'd highly consider just moving everything to 3.2 - do you really want to be back porting changes? Users who are still using 2.0 OS (probably a small minority, even including jailbreakers as 3.1 has been jailbroken for quite a while) don't have to upgrade to the new version. The expectation with iPhone apps is that new versions will be free, not that new versions will be free and always work on an old operating system.

As a user who keeps my OS up to date, I would actually be upset if you spent a lot of time working on supporting users who aren't upgrading; I feel your time would be better spent adding new features.