Designing for iPad

All of the apps we have built so far can run on an iPad. We can simply install the same apps on an iPad device and they will work the same as on an iPhone. Because of the difference in screen size and resolution, iPhone apps will run in a window on an iPad.

A 2x button in the bottom right of the screen will scale up the app for a better fit on the iPad screen, but that tends not to look very nice as the graphics get pixelated.

It is important to take the iPad’s screen size into consideration when developing apps in order to provide a better user experience. More space and a different aspect ratio means that you can put more information on screen and have a different layout.

The starting point to building apps for iPad is simple; You just select the iPad device from the drop-down when creating a new project in Xcode.

Split Navigation

iPad projects have the possibility of using the UISplitViewController for navigation, which can present two view controllers side-by-side. This type of layout is commonly used for Master-Detail relationships, like for example a table view and a detail view populated by a selected cell.

Much like the UITabBarController, the UISplitViewController is a base view controller and should only be used as the initial view controller of your app.

The simplest way to build a split view controller layout is to start with a Master-Detail Application for iPad.

If you examine the Storyboard, you’ll notice that the initial view controller is the UISplitViewController, and that it is connected to two UINavigationControllers, one for the Master relationship (on the left), and the other for the Detail relationship (on the right). The master navigation controller is connected to a UITableViewController, and the detail navigation controller is connected to a simple UIViewController.

The master and the detail can be accessed from the split view controller’s viewControllers array. This array holds only two elements, the first being the master and the last being the detail.

Both the master and detail view controllers have references to their parent split view controller that is automatically set in their splitViewController property. This property is used to link the master view controller to the detail view controller.

[self.splitViewController.viewControllers lastObject] references the detail navigation controller. The topViewController of this navigation controller is the detail view controller.

You can use this reference to pass information to the detail view controller.


If you run the app, you’ll notice that both views are visible in landscape orientation.

However, in portrait orientation, the master is hidden by default.

It slides in from the left, partly covering the detail, when the Master button in the navigation bar is tapped.

You’ll also notice that the Master button is only visible when the device is in portrait orientation. This does not happen automatically, but through delegation.

The detail view controller conforms to the UISplitViewControllerDelegate protocol and is set to be the split view controller’s delegate.

When the split view controller switches to portrait orientation, it calls its delegate’s splitViewController:willHideViewController:withBarButtonItem:forPopoverController: method. The third parameter to this method is the UIBarButtonItem that will present the master view controller when tapped. The delegate can therefore add this button to the navigation bar.

When the split view controller switches to landscape orientation, it calls its delegate’s splitViewController:willShowViewController:invalidatingBarButtonItem: method. The third parameter is the UIBarButtonItem that is not necessary anymore, and should be removed from the navigation bar.

If you always want the master view controller to be displayed, the delegate must implement splitViewController:shouldHideViewController:inOrientation: and return NO. Note that by doing so, splitViewController:willHideViewController:withBarButtonItem:forPopoverController: and splitViewController:willShowViewController:invalidatingBarButtonItem: do not get called anymore.


The UIPopoverController is used to display a view controller temporarily. Unlike a modal view controller, a popover does not take over the entire screen, but is layered on top of the main view in a special type of window.

The popover controller’s content is a UIViewController, which can be accessed using the contentViewController property. You can easily create a popover in the Storyboard by creating a Popover style segue between any two view controllers.

You can also create it in code.

Header Source

Note that if you are also responsible for dismissing the popover programmatically. You can use the popoverVisible property to check whether the popover is displayed or not.

The easiest way to set a popover controller’s size is by setting the view size of its contentViewController, but you can also set it in code using setPopoverContentSize:animated:.

The UIPopoverControllerDelegate can be notified when a popover is closed by implementing the popoverControllerDidDismissPopover: method.


Modal views are presented on iPad in the same way as on iPhone. However, it will sometimes not look good for a presented view to take up the entire screen. You can set the modalPresentationStyle property on the presented UIViewController for a different style.

Possible styles are:

  • UIModalPresentationFullScreen – The default, like on iPhone.
  • UIModalPresentationPageSheet – Full height, but always in portrait size (even if the view is in landscape).
  • UIModalPresentationFormSheet – Centered in the view, with everything around dimmed.
  • UIModalPresentationCurrentContext – Same as the parent view controller.

Universal Applications

Universal applications are apps that run on both iPhone and iPad.

To create a Universal app, you just select the Universal device from the drop-down when creating a new project in Xcode.

This will generate two Storyboards: MainStoryboard_iPad.storyboard and MainStoryboard_iPhone.storyboard. This is where following the MVC pattern comes in handy. Each Storyboard is a different View, and they use the same Model (data). If both Views have similar feature sets, they will probably use the same Controller too.

In your view controller, you can detect which type of device the code is running on by checking the userInterfaceIdiom property of the current UIDevice.

  1. Paul Hegarty. Lecture 7 Slides. iPad and iPhone Application Development. Stanford, Nov 16 2011.

  2. View Controller Programming Guide for iOS. Apple, Visited Oct 23 2012.

Comments are closed.