Inside the iPad SDK: Bigger screens, continued frustrations

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. So 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. And 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've got 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 Andrew Donoho, an iPhone app developer who runs the Donoho Design Group, notes, 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.

There's more to the larger iPad screen than having more room for your elements. It also affects your user interactions: When Donoho writes iPhone apps, he consciously limits himself to an 8-by-12 grid of touchable spots. The human fingers just don't have the resolution to reliably hit spots in a finer grid in the iPhone's screen, he says. But the iPad's larger screen size increases that grid's size, thus allowing more hit spots.

Sorry, the bigger screen doesn't mean Mac-like windows and dialog boxes

But don't think the bigger screen means you can port your existing Mac OS X applications or use the familiar Windows and Mac OS X UI elements such as windows and dialog boxes.

[ Stay up on tech news and reviews from your smartphone at | Get the best iPhone apps for pros with InfoWorld's business iPhone apps finder. | See which smartphone is right for you in our mobile "deathmatch" calculator. ]

The iPad is still a touch-based device, so UI elements that require the precision of a mouse -- as many windows and dialog boxes do -- won't cut it. The iPad SDK reinforces that desktop-aversion by offering just a few more controls for touch-based interaction to extend the familiar iPhone UI metaphors, not replace or augment them with desktop metaphors.

The UISplitViewController, for instance, lets you divide the screen into two separate views that work together. What the Mac developers used to call a nonmodal dialog long ago now is recast as a popover, another way to add a small layer when some optional controls are helpful. The popovers, though, are meant to be more closely connected to the window underneath. They're not really extra floating windows.

It's clear Apple doesn't want to encourage the sea of windows that often appear on desktops. Nor is Apple fostering the kind of cut-and-paste multitasking among apps common on desktops or laptops. While there are new routines for creating PDF files, most of the OS design seems to be signaling that the iPad shouldn't be used for heavy work: A few emails or touchups to a presentation are fine, but real information synthesis should be left to desktops and their big keyboards.

Most new libraries are for content

The iPad is more a device for consuming content than creating it, and several new libraries emphasize this.

Many of the more popular iPad apps will probably deliver words to the iPad screen, and that's why the iPad's iPhone OS 3.2 includes the beefier CoreText routines. The package first appeared in Mac OS 10.5 and is now one of the most flexible ways to display fonts on the screen. There are fonts, font descriptors, font collections, and layout engines to arrange the glyphs from these fonts on the screen.

If you want your text to move, the Core Animation code comes with a CATextLayer routine to move the text around. The iPhone developer had to make do with basic text routines, but the iPad developer gets more tools for text designers to take advantage of the iPad's screen.

Still, despite the Mac OS X origins of these routines, there are differences that might get in your way. Several methods for the CATextLayer, for instance, come with notes that say that implicit animation is available only when compiled for Mac OS X 10.6. Some iPad developers report glitches using the funkiest routines that lay out text along curves. I suspect these omissions are the result of smart decisions by Apple engineers who wanted to curb the API to save on battery consumption. Who wants to blow all of that battery life on words floating around the screen on weird paths?

Still, I bet that book designers -- and game designers -- will love what they can do with these routines. I'm sure that the best textbooks will soon include full animation, video, and simulation when they start appearing for the iPad. It might not even be fair to continue to use the word "book" to describe how nonfiction content will be delivered. All you need to do is compare a 30-year-old cookbook with a modern one and see what a talented book designer can do when equipped with a Mac and some good layout software. Now imagine tossing a programmer into the mix.

But don't get too excited: The iPad's single-window model means that a click on a URL in an e-book transfers control from the e-book to Safari. Even if the publication is delivered through Safari, clicking on a link hides the current screen and moves to another. This single-window model is going to discourage the kind of foraging and wandering common to desktop Web users -- and that many designers use as their interaction model.

Be prepared for app rejections and runarounds

iPhone developers have been complaining about Apple's complex, often unstated rules about the App Store ever since the first iPhone SDK. That won't change with the iPad App Store.

The App Store rejected my app several times when I failed to choose correct settings for the flags in the Info.plist file. This long collection of switches in this file influences everything from the acceptable devices (iPad, iPhone, or both) to bytecode generation by the compiler. Apple has constructed several menu options with templates that try to set all of these switches to the correct configuration, but if you take a slightly different path, as I did, you'll end up confused.

[ Also from InfoWorld: Read Peter Wayner's "iPhone App Store roulette: A tale of rejection." ]

The third time I submitted the application, though, it sailed into the store after sitting in the review queue for just one day. All the fiddling with the flags and the icons worked out. It may not be the most polished book reading app, but it's an easy way to get Cory Doctorow's Makers for free. (You can get my free iPad Makers app at the App Store, as well as the iPhone version.)

Figuring out how to build an acceptable Universal Application is yet another skill that forces the developer to mix together knowledge from documentation with folk wisdom from colleagues. Sometimes the App Store will flag a mistake when you upload the app, but I had to wait for official rejection letters -- the good news is that they came after a much-improved wait time of about two days.

When I built my sample version of Cory Doctorow's Makers app, starting with an HTML version I'd previously created, the app started working almost immediately in the simulator. But I spent several days trying to upload it to the App Store.

Although there are now copious videos and some instructions that are often useful, there's also a great deal of complexity to work through -- and it's only half automated. To make matters worse, the rapid evolution of the iPad App Store platform means that the automation isn't always consistent. The Application Loader tool, for instance, kept rejecting my binary, but I could get it to upload successful through the Apple developer Web site.

Apple's often arbitrary rules also surfaced. For example, I lost one hour trying to upload a 512x512 image that is supposed to be displayed for customers, but the iTunes Connect Web site just kept rejecting my form by saying the image couldn't be found. After I filed a bug report, Apple told me the problem was resolved at the end of the day. Although this glitch was fixed, someone out there rejected the app because the 512x512 version of the icon allegedly didn't match the 57x57 pixel version, even thought I swear I built them from the same image. Perhaps this was caused by the way that the Make function doesn't seem to recognize changed icons. Sheesh.

A good deal of the trouble continues to come from the seemingly endless provisioning process. Every piece of software kept telling me that some certificate was going to expire in four days, but I couldn't figure out how to get a new one. After an hour of clicking, I just uploaded my code and it seemed to take after a few hours of fiddling. Then when it did expire, all of the provisioning profiles stopped working and I couldn't simply push the Modify button successfully.

At least half of the time I devoted to this app was spent in this hell. It's almost enough to make me wish that someone would figure out a cheap way to crack public key cryptography apart so no one is forced to dance for these routines.

Still, there are bright signs. The response time for submitted apps is now measured in days or even hours, not the weeks that dominated last year when everyone who wanted a yacht was writing iPhone code. The App Store now collects some crash reports about the stack location where trouble began, and it even shares some of these with developers. It offers more options for developers to connect with the customers in whatever limited form that might be. There is more and better documentation for most of the cases except for mine. All of this makes life a bit easier to live inside the concertina wire.

But there still are moments when the automation inadvertently speaks the truth about Apple's chosen role for developers in this universe: When I started a project and pushed the button to create some new templates, XCode kindly added two new lines to the comments at the top of these new files. The first began, "Created by Peter Wayner" and the second said, "Copyright Apple Inc 2010." The notice just applies to the template code -- I think -- but the symbolism is unmistakable.

Related stories

* "iPhone development tools that work the way you do"

* "The cross-platform option: Web apps for smartphones"

* "SDK shoot-out: Android vs. iPhone"

* "iPhone App Store roulette: A tale of rejection"

* "Hate Apple's App Store? Developing for Kindle won't be any freer"

* "Want to get rich with iPhone apps? Only a very few do"

This story, "Inside the iPad SDK: Bigger screens, continued frustrations" was originally published by InfoWorld.

Copyright © 2010 IDG Communications, Inc.

7 inconvenient truths about the hybrid work trend
Shop Tech Products at Amazon