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

views:

1489

answers:

+4 Q:

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

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?

+8 A:

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.

John Rudy 2010-02-16 20:46:37

THANKS! this seems to be the logical approach to me, specially with this app of mine that use large images that would make the executable be large for the iphone. Anyway I think this may be the best approach even for new apps, unless you are willing to code for the same OS in both platforms and you have small graphics.

Digital Robot 2010-02-16 20:52:49

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.

BarrettJ 2010-02-16 20:50:50

the problem is this: the guy have an iPhone using OS 2.0. He bought my application. I move to 3.2. This guy and others are now pissed because the app stopped working for them. The other problem is this: does iTunes or the Appstore app on the iPhone allows a guy using OS 2.0 to download a 3.0 version of the application? If yes this is worst, because the new version (not working on the guy's device) will overwrite a working version. I am not sure if the iPhone version is checked when you are buying/downloading an item.

Digital Robot 2010-02-16 20:59:26

At the very least you could put a warning saying not to download this version if you're using 2.0, but I do believe there's a way to flag it so it won't display as an available update. The version they're already running will remain working (assuming there's no web service involved). At some point you are going to have to abandon the users who don't want to upgrade their OS past 2.0 - whether it's when 3.2 comes out or when 4.3 or 5.8 comes out is up to you, but as a frequent buyer of iPhone apps, I would be much more pleased with you adding new features than supporting old OSs.

BarrettJ 2010-02-16 21:08:25

+9 A:

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.

Tim Sullivan 2010-02-16 21:05:07

+1; this is probably the right answer.

John Rudy 2010-02-16 21:11:27

+3 A:

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

jamone 2010-02-16 21:14:04

Thanks! Yes, my problem is the 32% of ipod touch users with 2.x...

Digital Robot 2010-02-16 22:25:52

I've said it before, but that 32% is not a very good target audience. If they won't bother to pay $5 for a full OS upgrade, why would they pay for your application? In any case, that number might shrink now that the 3.0 update is free for iPod touches: http://www.iphonealley.com/current/30-software-update-now-free-for-ipod-touch

Brad Larson 2010-02-16 23:37:59

Also of note is those stats don't show Beyond Christmas really, and iPod touch sales always go through the roof at Christmas. Those 32% on 2.x will probably drop significantly. Also since people have more time off they may get around to updating. I know my parents don't update theirs unless they have a few days off.

jamone 2010-02-17 13:55:05

ansaurus

tags:

views:

answers:

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

related questions