small medium large xlarge

29 Apr 2010, 23:16
Ken Maskrey (5 posts)

It seems like it’s better to have two different apps, an iPhone version and an iPad version for the same function unless it’s something scales well like maybe a game. The UI capabilities are just so much better on an iPad that you have to use split-views and popovers…keeping iPhone table views just makes your app look bad.

If you start putting in all these conditionals to check what device you’re in, that seems like it will make the code get messy pretty quickly. So then it seems like two separate Xcode projects, one for iPhone and one for iPad are the way to go, but that means maintaining two separate projects for one system. Of course, for a system in deployment (in the App Store) changes should be well defined and well contained. Sound about right?

So, going this route, will the user have to buy both versions of the app if he wants to use it on both an iPhone and an iPad assuming the App has a cost? The user of course can run his iPhone version of the app on an iPad in compatibility mode to get by if need be, but all the cool stuff for an iPad UI would be in the specialized iPad app.

Does this sound about right? That, in order to get the most out of an iPad and not have lots of conditionals throughout the code, that separate projects specific to the iPhone and iPad would be the better way to go????

I’m about to go “all in” and convert my iPhone table-view based app to iPad using the good stuff (splits and popovers), creating separate projects (the code is mature enough that future changes should be well contained), and thus, separate apps in the App Store. I’m just looking for a sanity check.

30 Apr 2010, 17:25
Ken Maskrey (5 posts)

Okay, so I’m replying to my own query but I had another thought on this. I suppose that at the app delegate level I could do a single check as to whether this is an iPhone vs iPad then construct the whole hierarchy that way. Again, essentially two sets of code but contained in one project and generating a universal binary.

On the surface, this, at least today, seems like the better solution. thoughts?

06 May 2010, 12:47
Daniel H Steinberg (98 posts)

You can do much of what you want through the nibs that you load (as in our example). So yes you can do much of what you want at this top level. But depending on how much reuse you want to take advantage of, there may be more checks to make down stream. As we’ve shown in the book, these checks need not be the explicity checks for platform.

You must be logged in to comment