With the release of the iPad back in April companies have been scrambling to take advantage of what this new platform has to offer. Only a little over a week ago the count of native iPad apps approved in Apple’s iPad store was over ten thousand. So with this device flying off the shelves it’d be hard not to want to cash in with a native iPad app. We recently began work on such a port for Mobile Innovations, one of our clients.
In porting your app there are two very important things that need to happen. The first is that the App’s front end needs to be redesigned to take proper advantage of the iPad. With all the screen real estate it offers it gives you a chance to streamline your interface and reduce the number of controls a user has to click through to get where they need to go. Multiple pages can be condensed into a single page, and so on. But that’s not what I’m really here to talk about, I’m a developer and not a graphic designer so let’s talk about what we need to do to build our native iPad App from our iPhone source. So we can take fullest advantage of all the new features while re-using as much of our existing resources as possible.
First, open your project in Xcode and right click over your build target for the iPhone and click the option to upgrade your build target for the iPad.
After which you’ll be presented with another prompt regarding how you want to handle your codebase.
Next select option number two and click “Ok.” Option number two makes the most sense in this case; if you choose the first option you’d be building both targets from the same everything. Now, this is fine for simple apps where you really just want to have the layout flow into the larger screen with only minor differences. Option number two will copy all of your nib files to a separate area, allowing you to customize your user interface for just the iPad, with the interface being built determined by the active build target.
When viewing your Nibs you’ll notice the bullseye icon heading a column of check boxes. The box checked indicates which Nib is being loaded for the current build target.
This gives us all the freedom we want to customize our interface for the iPad to take full advantage of its display. There are still a few more steps to go though before our app is ready. Not all resources will be relevant to a given version of the App. So the next thing to do is to navigate to your project directory and make a copy of your app’s info.plist file into the new Resources-Ipad subdirectory in your project folder (I’d also recommend renaming it to something like appname-iPad-info.plist), then add it to the iPad resources folder in Xcode.
Next we need to tweak some version specific settings. The first of which is setting up version detection since we’re sharing the same source files. There are two methods of detecting which version of an app certain code should run on; one for detecting at compile time and one at run time.
You can detect at run-time using something similar to the following pseudocode:
#ifdef UI_USER_INTERFACE_IDIOM
#define IS_IPAD (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad)
#else
#define IS_IPAD NO
#endif
if (IS_IPAD)
{
// iPad specific code here
}
else
{
// iPhone/iPod specific code here
}
Of course in our case we’re loading separate nibs for two separate versions, so it’s going to be more appropriate to conditionally compile our code using the preprocessor. Run-time detection is generally only useful for universal apps.
Highlight the build target for our iPad app and click the blue info button to open the project settings for it. Scroll down and add a little something like this to your preprocessor settings.
This way now when we need to run different code for different versions of our project we can just write
#ifdef TARGET_OS_IPAD
//iPad specific code
#else
// iPod/iPhone specific code
#endif
Depending on how much code you end up needing to be version specific performing version detection at compile time will offer a much better return speed wise. It also allows you to modify definitions in your header files as well, so that iPod/iPhone apps don’t need to load resources into memory that are only necessary on an iPad. Finally, let’s go back up in our project settings and change our info.plist for this build target.
And that’s it. From there it’s just a matter of reworking your nibs to fit the larger design. Code wise there are some things that do need changing between versions such as how modal inputs like the image picker need to be accessed via popovers in the UI. I can’t say what specific issues anyone else may run into when porting their apps over but with the above you now have everything set up so that you can build two separate apps from the same source and you can re-use as much or as little of your resources as necessary between either version. Just set your target and hit build.
Subscribe