Paul Lynch's Pages

I did a review last week of the iPad release, based on the Programming Guide and Human Interface Guidelines, for a customer. The aim was to find out what changes I would have to make to their iPhone application; this post is to give my impressions, on that very brief survey, of what changes developers will have to look out for. I am sure that further announcements will reveal many more.

If the documentation is to be believed, any iPhone app will run exactly on the iPad as on the iPhone, just in a small compatibility window.  No changes required to work this way.

If you want to work as a native app, then you will have to convert your project, and use conditional preprocessor directives to insert code that varies between platforms, and create a Universal application.  There are plenty of “ifs” and “buts” hidden beneath that statement.

For most developers, there are some standard changes that all apps will require, connected with the different size display of the iPad, and Apple’s change of UI emphasis with regard to orientation.

• check that your views support resizing appropriately; this should be all configurable in IB.  iPhone views aren’t resized, but iPad ones (presumably) can be; and this configuration will let you use the same nibs for both iPhone and iPad, in many cases.
• always support device rotation to any orientation.  A lot of iPhone apps only work in portrait, which already sucks on the iPhone.  There are also additional loading screens (Default.png), one for each orientation; it isn’t clear if Apple will auto-rotate Default.png to suit; they should, but this is Apple after all.
• Navigation bars are de-emphasised.  It isn’t entirely clear what this really means, as a lot of application designs depend on them, and that won’t change on iPad, no matter what Apple say about “information flattening”.  The alternative, if it applies, is to flatten your content into split views and popover windows.  Taking a typical deep data hierarchy based application, your top level navigation might be put into the “master” pane of the split view in landscape mode, although this won’t always make sense.  This master pane would then also be the popover pane for portrait orientation.

A big change is document support, which was required for the iWork apps.  Each app now can have a document directory that will be sync’ed to the desktop; these folders are all isolated from each other, in line with the security sandboxing on iPhoneOS.

Other significant changes that may or may not impact developers are:

• new CoreText framework (matching the one on MacOS X) for text layout apps – primarily book readers, perhaps?
• gesture recognisers.  About time!  I’ve been writing my own since 2.2 (when I started with iPhoneOS development).  I’ll just swap out mine for Apple’s; the way they work is basically the same.
• UIBezierPath.  Another one that should have been there in 2.0; only has relevance if you are using custom views, and most people with that requirement will be using CoreImage or OpenGL, so no impact to them.
• Input Views and Input Accessory Views.  App specific additions to the keyboards, which were undesirable before this.
• Media Player Framework API changes, mostly connected with new resizing behaviour so that it doesn’t always become full-screen.

What I don’t like about this is the very clunky requirements for Universal app builds.  I hope that there will be further clarifications which make this more transparent for developers, as the process required isn’t at all clear.