iPad SDK Details Revealed
Join the DZone community and get the full member experience.Join For Free
The iPad SDK comes with new routines for the added screen real estate and new formatting capabilities for ebooks. Other than that, it's pretty much just like writing an iPhone application. Although there's not a revolution in what you can do with the SDK, it's good news for iPhone developers who want to jump right in to iPad development. There's just a few traps that the iPhone savvy developer should know about.
Although the iPad SDK will work with unmodified iPhone OS 3.0 code, developers shouldn't rely on this compatibility. These unmodified apps will run in an iPhone simulator with menu options for fitting the app to the bigger screen, but they don't do a very good job. They tend to just blow up the iPhone screen size. iPhone developers will need to rethink the user interface.
It was because of the iPhone's insufficient screen size that Apple decided to wait for the iPad before it released mobile versions of Keynote, Numbers, and Pages from their iWork suite. The iPad is much better for productivity apps because they require extra screen space. There are also new routines for creating PDFs. One of the biggest advantages of the larger screen is the increased number of hit points (squares activated by touch) you can put on the UI.
The iPhone SDK didn't have as many text routines as the iPad either. The iPad SDK routines have fonts, font collections, font descriptors, and layout engines. For text animation, there's a CATextLayer routine. The routine isn't as full-featured as the Mac OS X 10.6 version, and the iPad version can cause some glitches for more complex animations. However, this was probably done to save battery life. The text animation should open up a whole new realm of possibilities for ebook development.
You won't find any windows or dialog boxes on the iPad interface, but there are some new tools for split interfaces that the iPhone didn't have. The UISplitViewController can divide the screen into two separate views for one application. One view may contain an options menu while the other contains the application's main interface.
Finally, iPad developers won't find many improvements in the iPad App Store compared to the iPhone shop. You might end up spending a lot of time pouring over documentation to try and find the correct settings to get your app accepted. The helper tools aren't always consistent and the process becomes even more complex if you're making an app that is compatible on both the iPad and the iPhone. However, the response time for submitted apps is getting shorter, the documentation has gotten better, and Apple now collects some crash reports that may indicate where the problem occurred.
Opinions expressed by DZone contributors are their own.