Now that the final version of the iPad SDK is available and the NDA is lifted, let’s have a look at what is new. I will give an overview of the new features in this post and elaborate on some of them in more detail in the coming days.
It’s called iPhone SDK 3.2, but it’s not for the iPhone
When Apple released the first beta version of the iPhone SDK 3.2 after the iPad announcement in January 2010, nobody was surprised that it only supported iPad development at the time. However, many (including me) expected the new features to come to the iPhone as well once the final version arrived. Turns out this isn’t so and we will have to wait at least until the next SDK version (4.0 in the summer?) for a unified release. And while certainly not all of the new UI features for the iPad would make sense on the iPhone, the 3.2 SDK includes many changes that I’d love to have on the iPhone, too (CALayer drop shadows anyone?). Now let’s start with the overview of the new features:
New iPad-specific user interface elements
Apple has introduced two fundamentally new UI paradigms that make use of the iPad’s larger screen: popovers and split views. Both of them will possibly never make their way to the iPhone because they simply make no sense on the iPhone’s small screen.
Popovers will be ubiquitous in many iPad apps. You often use them where you would go with modal view controllers or deep navigation controller hierarchies on the iPhone. Popovers are managed by the new
Split views allow you to display a master-detail hierarchy side by side on one screen as opposed to the multiple-screen hierarchies managed by
UINavigationControlleron the iPhone. The new
UISplitViewControllertakes two of your view controllers and helps you manage their master-detail relationship.
In addition to the new UI paradigms, modal view controllers on the iPad can not only be presented in full screen, but also as page sheets (full screen in portrait but only portrait width in landscape orientation) and form sheets (centered on screen but smaller than full screen; more like oversized alert views). This is all to reduce full-screen transitions to a minimum, which would be irritating to users on the large iPad screen.
Major non-iPad-related new features
The following features could in principle also work great on the iPhone and I hope that all or most of them make it to the small screen in the next SDK.
Gesture recognizers will finally liberate us from the tedious and error-prone work of trying to reimplement common gestures like swipes and pinches in our own custom views. Never was it easier to write a custom scroll view that only responds to two-finger swipes. This is one of my favorite features in the new SDK.
Custom input views means that you are not limited to the system-provided keyboard layouts anymore for data entry. You can provide completely custom-made input interfaces and make any view or control able to interact with them. That still means a lot of work if all you want is to replace one button on the system keyboard (because you would have to reimplement the whole thing) but it’s great for custom data entry interfaces as Apple demonstrates in their Numbers app.
Core Text and more (with limitations)
The rendering of rich text with different fonts and formatting is quite hard in the iPhone SDK 3.1, and supporting not only rendering but also rich text editing is an almost impossible task. You would basically have to reinvent everything. The new SDK makes this a whole lot easier with its support for Core Text, Apple’s C-based rich text rendering and layouting framework.
Still missing, though, is an enhanced
UITextViewthat actually made use of the new capabilities. So if you want to write a Pages competitor, you get the rendering engine (almost) for free but you still have to write the rich text editor. The difference is that Apple makes this possible now, though not exactly easy. Implementing the massive
UITextInputprotocol is quite a lot of work. I haven’t seen an iPad app on the App Store that has pulled this off yet.
CATextLayerlets us easily render rich text on a Core Animation layer.
We can now include custom fonts in our app bundles and use them just like the system-provided fonts. Yay! Register your fonts with the system by including the
UIAppFontskey in your
UITextCheckeris a new class that provides us with a spell checker.
NSStringgot regular expression support in its search methods (
File sharing support I still haven’t figured out how well this works in practice. Basically, all you need to do is add a
UIFileSharingEnabledkey to your
Info.plistand then your app will be able to share its documents with its host computer via iTunes. Still sounds awfully complicated to me. Instead of relying on iTunes, Apple should mount an app’s Documents folder on the host computer directly. And not just when the USB cable is plugged in but also when both are on the same WiFi network.
Register supported file types Your app can now tell the system which file types it supports (again via
Info.plist) and receive notifications when a file of this type needs to be opened. This is used by apps like Mail that should be able to send arbitrary files they downloaded to the right application to open them. If your app needs to handle files of unknown types, you can use a
UIDocumentInteractionControllerto display those files to the user and let them preview and open them. This is a much-needed step to facilitate interaction between apps on the iPhone OS platform.
External display support The built-for-Keynote feature. If an external display is connected to the iPad, the
UIScreenclass will return more than one screen and your app can create multiple
UIWindowinstances and assign each one to a specific screen.
UIMenuController allows you to create custom popover menus like those that are used for the Copy & Paste functions since OS 3.0. I hope this will make it to the iPhone, too. Until then, Oliver Drobnik has written a replacement called DTMenuController (not free, though).
PDF generation UIKit includes new functions for generating PDF files in your application:
UIBezierPathis an object-oriented wrapper for
MapKit’s reverse geocoder now provides us with a
placemarkproperty to access the results of the reverse geocoding process after they have been reported to the delegate.
That’s it for the overview. You can still find a few more changes in the iPhone OS 3.2 API Diffs. In the next post, I will document what changed in Xcode 3.2.2, and after that, I will pick out some of the new features and talk about them in more detail.