As more iOS devices hit the marketplace, developers should reevaluate their approach to building apps intended to run on all devices. When the iPhone was first introduced, developers were not concerned with creating a single codebase designed to run on multiple devices. There were no other devices. When the iPod Touch entered the marketplace, the interfaces – size and resolution – were nearly identical to the first-generation iPhone. It was very easy to develop, compile, and publish a universal app compatible with both devices. Today, it is not too difficult to develop a single app that will run on all current iOS devices.

The process

Apple Xcode makes coding universal binaries simple, but not automatic. There is a little extra work – both in the planning and coding phases – to make a scalable universal app. The first step in developing a universal app is to select “Universal” from the Devices menu (Figure A). Xcode will create a project with code for the iPhone, iPod, and iPad devices. Two storyboard files are created and added to the universal project. One storyboard file supports the screen size and resolution of the iPhone and iPod devices, while the second storyboard file is specific to the iPad family of products.

Figure A

In addition to the device-specific storyboard files (Figure B), a universal project will include two separate areas for controlling the deployment settings for each type of device – independently. The supported orientations, app icons, and launch images for the iPad and iPhone/iPod devices are managed within different sections of the summary tab under the project settings (Figures C and D).

Figure B

Figure C

Figure D

As you can see, Xcode has built-in support for developing universal apps. If the developer’s intention is to maintain a common experience across all devices, simply follow the same design and flow patterns in each storyboard, compile, and run. If it is necessary to have a different experience on each device, however, additional coding will be necessary.

In the Advanced App Tricks section of the iOS Programming Guide, Apple uses the example of developing a universal app that supports launching in landscape orientation on an iPad and portrait orientation on iPhone and iPod devices. The Info.plist is a great way to use Meta data for controlling certain aspects of an iOS app. Adding specific keys to the Info.plist file is a simple and scalable way to manage parameters outside the codebase. Take a peek at the List Key Reference for a complete listing of parameters that can be defined in the Info.plist file.

A name/value pair within the Info.plist file is structured as follows:


The <key> tag identifies the property, and the <string> tag encloses the value. In the above example, every device supported by our universal app will launch in landscape mode. To target a specific device, we append one of the three device types to the key. If we need the iPhone devices to launch in portrait mode, for example, we would add the following code to the Info.plist file:


The acceptable values are iphone, ipad, and ipod.

Beyond the interface

Sometimes it is necessary to create conditional code paths for supporting device-specific functionality. Apple has included a macro for easily determining the current device type. The UI_USER_INTERFACE_IDIOM macro is part of the UIKit framework, and is available for use in all apps. If the device is an iPad, the value returned from the macro will be UIUserInterfaceIdiomPad. If the device is either and iPhone or iPod Touch, the value returned is UIUserInterfaceIdiomPhone.

Use the macro any time it is necessary to branch or run device-specific routines. A typical conditional statement would look like the following:

If (UI_USER_INTERFACE_IDIOM() == UIUserInterfacePhone) {
// Place iPhone/iPod specific code here...
// Place iPad-specific code here...

Developers are constantly looking for ways to minimize the amount of code required to develop an iOS app. One way, of course, is to maintain a library of classes, methods, and functions for reuse. It is important to consider the possibility of using these classes in universal apps. With that in mind, you should develop classes with conditional code paths where necessary.

Final thoughts

There are pros and cons in developing universal apps. From a maintenance and support perspective, one code base is easier to manage. Also, a universal app approach means that a single release – updates and patches – covers all devices at the same time. Business requirements, however, may override the feasibility of developing and releasing a universal app. Sometimes it may be desirable to have a different price point for an iPhone app than the same app released for the iPad. Currently, the App Store supports only one price for each app.

Also read: