Converting to a Universal App (Part II)

It has taken me longer than I expected to get back to this topic. My earlier post describes the steps that you pretty much have to follow when first converting to a Universal app. Some of the process is automated by Xcode but the steps are likely to always be the same. However once you get the basic setup complete the choices on how to proceed are seemingly endless. So I thought I would take some smaller bites out of what is a big topic.

Preparing the ground

Before attempting any major changes to an existing app it is worth taking some time to refactor and clean up what you already have. This is less satisfying in the short term if you are in a hurry to see something up and running on the iPad but it should pay off in the long run. Some suggestions to take a look at:

Review the Model-View-Controller Design Pattern
Reduce dependencies between classes.
Screen resolution dependencies
Supported orientations
NIB file organisation

Review the Model-View-Controller Design Pattern

Take five minutes to read through the Cocoa Design Patterns section of the Cocoa Fundamentals Guide. Pay particular attention to the section on design guidelines for MVC applications and review your application against it. As far as possible try to get a clean separation of roles between your model, controller and view code. Doing so will (IMHO) make universal iPhone + iPad apps much easier to create and maintain. The model code is likely to be completely reusable between the two versions. Some of the controllers will also likely be shared between versions but it is likely that you will want to change a number of views. Check your controller code for anything that could usefully be moved to the model where it has more chance of being reused.

There are always people who will tell you that Interface Builder is a waste of time and that it is easier and quicker to build UI elements with code. I personally prefer to use IB whenever possible but up to now I would say the choice was really a personal one. Having said when it comes to migrating to a Universal App I think having your view code contained in a NIB file has some advantages compared to mixing it in with your controllers. Firstly it is easier to review each NIB and see how it scales to the new dimensions but also it becomes cleaner to switch between NIB files for the different devices if that is what you end up needing. Of course you can still do that with some conditional code blocks if you want but I think there is a good case for keeping the view code contained in separate NIB files.

Reduce dependencies between classes

This is related to the MVC pattern but the less spaghetti you have between your classes the easier it will be to modify your application for the iPad. I think the key point to check here is that you do not have model classes that depend on view or controller code. This will cause you headaches if you need to change the controller or view code for the iPad version. Ensuring your model only depends at most on other model classes also has the advantage of making it easier to unit test.

Screen resolution dependencies

Apple has long cautioned about making too many assumptions about the characteristics of the device. With the iPad and most probably the next generation of iPhone following this advice is likely to pay off. It may not make too much sense to make drastic changes to your existing app as this point but it is worth reviewing where you have code that assumes a certain screen size. If you can eliminate such assumptions so much the better if not try to isolate the code into methods that can easily be conditionally compiled for each device.

Supported Orientations

If your iPhone app does not already support all orientations and rotating between them now would be a good time to add it. Apple has made it clear that it expects iPad apps to support all orientations and there seems little reason not to do the same for your iPhone app.

NIB File Organization

If you have multiple views all collected into a single main NIB file you may want to consider splitting some of the views out into separate files. Doing this now will make things easier if you need to have different views for each device. Also Xcode will copy your MainWindow NIB file when you first convert your project. That creates a lot of duplication if the views are the same for each device. Separating the common components out into separate NIB files means you can share the code between both versions of the app.