Inside the iPad SDK: Bigger screens, continued frustrations

The bigger screen size will require new UI thinking, but don't expect to create desktop-like apps -- or an easier approval process

The wraps are off, and the iPad is now in real users' hands. So what can developers create for the iPad using the iPhone OS 3.2 SDK that Apple released in late January? Apple required developers to keep the SDK details secret until the iPad's shipment this past weekend, but now everyone is free to discuss the extended dance remix of the iPhone.

As a test of the new software API and the infrastructure supporting it, I've built several prototype iPad apps and even uploaded one, a free version of Cory Doctorow's Makers, to the iTunes App Store.

[ How does the iPad stack up now that it is real? Find out in Paul Venezia's first look review of the iPad. | Take InfoWorld's tour of alternative iPhone app SDKs. ]

Most of the iPad platform will be quite familiar to anyone who's developed applications for the iPhone because the API is an extension of the iPhone API, just as the iPad SDK is an extension of the iPhone OS SDK (which is why it's technically named the iPhone OS 3.2 SDK, not the iPad SDK). There are several new routines for using all of the extra screen space, and most of the other elements are pretty close to what iPhone developers know well.

Apple is very interested in providing games, books, and other content-delivery mechanisms, but forget about shell scripts or doing anything that's not officially blessed with a documented part of the API. So, outside of taking advantage of the larger screen and accessing the expanded formatting capabilities for e-books, creating software for the iPad will be mostly business as usual for iPhone developers.

Still, although the move to the iPad is generally simple for iPhone developers, it's filled with enough complexity to leave some confusion. Here's what you should know about creating apps for the iPad.

Using all that new screen real estate
Everyone will love the iPad's bigger screen because designing for the relatively tiny iPhone screen was a merciless exercise in simplifying everything until it fit. Swiping between panels of widgets won't be a thing of the past, but it will be much less common on the iPad. Programming the iPad is like ditching that studio apartment in Manhattan and moving to a ranch in Big Sky, Montana.

First, avoid the temptation of relying on the iPad's iPhone-app compatibility. Sure, the iPad SDK will work with iPhone OS 3.0 code with no changes; it just compiles and starts right up in the so-called iPhone Simulator. Sure, there are several nice menu options in Interface Builder and Xcode for converting your old small-screen iPhone app into one for the iPad's larger screen. They're generally helpful, but they have limits: One does nothing to the size of your views, while the other one seems to make them fatter to fit the bigger screen. I had to make some but not all of them taller on my own.

While that resizing assistance is helpful, it won't make your apps work well in the iPad's larger screen real estate. You just get a version of your iPhone app that fills more of the screen. As noted by Andrew Donoho, an iPhone app developer who runs the Donoho Design Group, moving to the iPad requires rethinking your user interface. You should think of iPad apps as different form your iPhone apps, even if the underlying logic is shared.

"The smaller screen forced you to break things into smaller bits of functionality," Donoho notes. "The iPad app is going to be more complex because it's expected to do more. An iPhone 3G S could probably run the new Keynote app or the Numbers app [Apple is releasing] for the iPad, but the [iPhone's] screen is totally useless for a productivity app. What you're seeing is new capabilities because of the screen real estate." In other words, the UI difference is a key reason why Apple didn't bother with iPhone OS versions of Keynote, Numbers, and Pages -- the trio of Apple's iWork office productivity apps -- until the iPad.

1 2 3 4 Page 1
Page 1 of 4
How to choose a low-code development platform