iPad Tutorial for iOS: How To Port an iPhone Application to the iPad

What it will look like when we're done!

What it will look like when we're done!

I recently ported several of my apps from the iPhone to the iPad, and thought it would be useful to share some of what I learned along the way.

In this iPad tutorial, I’ll show you how to port an iPhone application to the iPad. We’ll take a simple app I wrote that displays a list of board games and lets you rate them, and we will port it to the iPad.

Along the way, we will cover how to test the device you’re running on, how to handle autosizing and orientation, how to make different versions of a XIBs for the iPad, how and when to use the new iPad elements, and more!

You may find it helpful to go through the iPad tutorials on How to use UISplitView and How to use UIPopoverController before you start, but it is not required.

The iPhone App We’ll Port

The app we’ll be porting is a simple app called “PortMe” that contains some of the elements found in many iPhone apps – table views, standard view controllers, and editing capability.

So grab a copy of the iPhone app we’ll port and check it out!

You’ll see that there are three view controllers. The first is a table view of the list of board games. The second is a view controller with a XIB to show the details for a board game. The third is a table view that lets the user rate a board game.

Look over the app and make sure you’re familiar with the structure. Once you’re done – let’s get to porting!

Upgrade Target for iPad

The initial step to port an iPhone to the iPad is almost misleadingly easy. Simply expand Targets and select “PortMe”, then click “Project\Upgrade Current Target for iPad”.

You have two options here – one universal application, or two device-specific applications. If you choose “One universal application”, that will allow you to make an app that customers can buy once, and have it work on both the iPhone or the iPad. If you want customers to purchase them separately, you may wish to choose “Two device-specific applications.”

In our case we’re going to make a Universal application, so click that and click OK.

Let’s take a look at what this did for us. The first thing it did was to create a new file called “MainWindow-iPad.xib” inside the “Resources-iPad” folder.

If you open it up and double click the Window, you’ll notice a big iPad sized Window. The XIB also contains the objects that were in the old XIB – the navigation controller with the PortMeGameListController set as the root view controller.

Another thing this did was to set our project to link against the 3.2 SDK. You’ll notice that compiling for the 3.2 SDK isn’t even an option anymore (at least once you switch off of the old SDK for the first time):

We can see this in the Target Info as well; it changed the Base SDK to “iPhone Device 3.2” and the Targeted Device Family to iPhone/iPad:

Well, let’s see what it looks like! Make sure “Simulator – 3.2” is selected, and run the sucker. You’ll see the first screen doesn’t look too bad because the table view auto-resizes to the screen, but our second view controller doesn’t fare nearly so well.

So we learned our first lesson of iPad porting – it’s not as simple as selecting the “Upgrade Current Target for iPad” option! Now we get to the fun and interesting part – reworking our app to work with the larger screen size and new requirements/opportunities.

Let’s start by fixing that messed up view!

Autosizing

When I set up the sample project, I just dragged over several UI elements into the view, and paid no attention whatsoever to the autosizing attributes – as could be a common case when an iPhone app is made without rotation support.

But now that we want our app to support both the small and big screen as well as (eventually) be able to support rotation, autosizing becomes very important. With autosizing, we can tell each UI element how it should react when the size of its parent view changes.

The easiest way to see this working is by trying it out ourselves! Open up PortMeGameDetailsController.xib, and double click the view.

For the top two labels (board game name and type), we want the labels grow in width as the view grows in width. So select those two labels and go to the third tab in the inspector. Down in the Autosizing section, set click on the light red areas until you get it looking like the following:

The animation to the right shows you the behavior based on your selection; in this case, it means that the labels should grow in width as the view expands, and they should maintain their current distance from the top, left, and right.

Now let’s take care of the rest. Set the UIImageView like the following:

This means that the UIImageView should grow in both width AND height as the view expands, and stay anchored to the edges of the view.

Set the text view like the following:

Set the label like the following:

And finally, the button like the following:

Let’s see how it looks! Make sure you save the XIB, then compile and run the project and you’ll see a new and improved view:

Definitely an improvement!

However there’s one major problem: if you try to rotate the simulator with “Hardware\Rotate Left” – the iPad rotates but the app doesn’t! And since supporting all orientations is a requirement for iPad apps, that would mean instant rejection at this point.

Luckily, since we’ve set our autosizing attributes correctly for our view (and since UITableViewController already supports rotation), we can fix with just a couple lines of code.

Add the following code to the end of PortMeGameListController.m, PortMeGameDetailsController.m, and PortMeGameRatingController.m:

- (BOOL)shouldAutorotateToInterfaceOrientation:
    (UIInterfaceOrientation)toInterfaceOrientation {
    return YES;
}

Compile and run the app, and now you should be able to rotate the phone to any direction and have the elements move correctly:

So far so good! However, our major problem at this point is we’re still thinking in an iPhone mindset. On the iPad, there is so much screen real estate, that we want to make the most use of it rather than forcing users to drill down to multiple levels unnecessarily.

And this is exactly what the UISplitViewController and UIPopoverController are for! So let’s see how we can use these in our app – while reusing our existing view controllers along the way.