The term “iOS 5” means different things to different people. To the general public, it means a whole new face for iOS devices, with new apps like Reminder, new icons like Newsstand, new interface like notification banners and the Notification Center, and new features like Reader in Mobile Safari and hourly forecasts in Weather. But to a developer, iOS 5 also means the iOS 5 SDK (software development kit) that comes with Xcode 4.2, released at the same time as iOS 5 itself. The SDK represents the toolbox, the built-in bag of tricks that an app can take advantage of.
Most existing apps have probably not been significantly affected by users shoving iOS 5 onto their devices; my own apps, for example, seem to be running precisely as they were under iOS 4. (A sad casualty, however, is Stanza, which is toast on my devices; but then, somehow one already suspected that Amazon had bought Lexcycle for the sole purpose of killing it.) But many developers are rushing (or have already rushed, during the beta period preceding the official release) to recompile their apps with the iOS 5 SDK, making those apps iOS 5-native and enabling them to take advantage of the expanded toolbox that the iOS 5 SDK brings.
Those changes, in turn, will affect what you see on your device’s screen. As more and more apps adopt iOS 5, iOS 5 SDK features will become part of your own user experience. So what are some of these features, and how might they manifest themselves in your daily usage?
The main place to look for answers is Apple’s own release notes for iOS 5. I can’t tell you anything you couldn’t ferret out for yourself by perusing that document; but in case you’d prefer that I peruse it so you don’t have to, here are some thoughts about the main changes you can expect to see as the iOS 5 SDK catches hold among developers.
Hey (Hey) You (You), Get Onto iCloud -- The big story, as is perfectly obvious from the amount of space devoted to it in the release notes, is iCloud. iCloud offers developers the opportunity to store an app’s documents and other data online in a way that’s intended to be convenient and even transparent to the user. Thus, a user could work on a document using Device A, then later pick up Device B and, in essence, find the very same document there, in the very same state.
It will help to think of iCloud as having two different purposes: backup and sync. The iCloud backup is largely just a substitution of wireless technology for something you were already doing every time you hooked your device to your computer and backed it up in the course of a sync. But iCloud sync is a way of sharing data across applications running on different devices. In the past, this sort of thing has been implemented through a variety of ad hoc solutions (such as Dropbox integration, or even building your own server); iCloud’s promise is a universal solution that all Lion and iOS apps can use fairly easily.
Your first 5 GB of iCloud storage are free, so developers will expect a significant proportion of their users to have iCloud space that their apps can use. Moreover, iCloud can also store small preference files that don’t count against a user’s iCloud storage quota. I think the result will be that many apps will integrate iCloud, and that users, in their turn, will soon expect iCloud integration in their iOS experience. For example, if I’ve entered my New York Times paywall username and password into the NYTimes app running on my iPod touch, I’m going to be miffed if I have to enter it again into the NYTimes app running on my iPad, when I know darned well that the app itself could be taking advantage of iCloud to share my preferences between instances of itself.
More broadly, I also wonder whether the document-oriented nature of iCloud may not constitute an invitation for apps to become document-centric in a way that previously they were not. Unfortunately, as far as I can tell, iOS 5 does nothing to help apps provide a uniform interface to let the user manage documents; iOS has no Finder, so each app must forge its own way of displaying documents and helping the user operate on them. Compare, for example, the Pages “document manager” screen with the GoodReader “manage files” pane; from an interface perspective, they have basically nothing in common.
Who Built the ARC -- The next big change called out in the release notes is ARC (automatic reference counting). This is the sort of feature only a programmer could love; it happens right down at the level of the programming language, Objective-C, in which iOS apps are written. But it’s an important change to the user, in one respect: If things go as planned, ARC should mean that apps will crash less often.
The reason is, simply, that Objective-C is not a very good language, and one of the ways in which it’s not very good is memory management. Up to now, memory management has been handled manually by the programmer; this, in turn, has meant not only that writing an app for iOS is an unusually fussy and tiring business, but also that memory management itself is a prime opportunity for the programmer to make a mistake that will result in the app either leaking memory and eventually crashing, or attempting to access an object that has gone out of existence and (you guessed it) crashing.
Unfortunately, for a variety of reasons, it’s difficult for Apple to take the step they really should have taken long ago, namely, to make some other language the native iOS programming language. It’s easier for them to adopt a different compiler (LLVM), which can take the programmer’s Objective-C code and do things with it that couldn’t be done by the previous compiler (GCC). In particular, LLVM can now insert, automatically, the manual memory management code that the programmer has up to now had to write by hand. That’s ARC.
Memory management in an iOS program is still manual, but, thanks to ARC, it’s written by the compiler instead of the programmer; the programmer effectively omits all the memory management code and lets the compiler write it instead. Since the compiler is more reliable at this sort of routine task than the programmer, memory management should be more correct more of the time (and the programmer won’t be so bored and can apply creativity to making the program do its actual tasks).
So, as iOS apps are rewritten using ARC, certain kinds of crash may become less frequent. Of course, there are other kinds of crashes; in particular, multithreading is still hard and will still probably be a source of trouble.
Structure My Screen -- In iOS 5, the ways in which apps can physically lay out their interfaces are expanded. For example, without getting too technical, on the iPhone especially the unit of view substitution has been, up to now, the screen itself: a primary view, managed behind the scenes by something called a view controller, took over the entire screen and responded to things like rotation of the device; and the programmer was not supposed to use a view controller except to manage this primary whole-screen view. The framework then provided a limited number of ways in which a view controller could manage other view controllers, such as the navigation interface and the tab-bar interface — which is why those styles of interface are so common.
But in iOS 5, the programmer is at last permitted to write a custom view controller that manages other view controllers; so I would expect to see completely new interface management idioms. It will be easier, for example, to split the screen into panes and have each pane do its own navigation between views. Moreover, iOS 5 gives the programmer more control over the transition animation when one view is substituted for another. There is much room here for creativity and originality.
A completely new style of application supported by the system is the page-based application. In effect, this lets any programmer implement the look of iBooks (including the snazzy page-curling animation), except that the view shown on each “page” can be any view whatever. For example, my Greek and Latin vocabulary apps display flashcards, with the user scrolling left or right to reach the next or previous “card”; I could now probably convert this quite easily to a book metaphor where the user pages between cards, and in the process I could remove a lot of code where I was inventing just the sort of wheel (e.g. preparing the next card before the user scrolls to it) that the page-based application hands me on a plate.
Wild, Wild Widgets -- Changes involving the onscreen widgets that the user can see and touch should be extremely obvious. Some of these are legitimate, system-based versions of things that programmers were doing for themselves by a variety of sometimes dubious means, and that’s a good thing — fighting the framework is a lot of work, and it’s risky, so the more the framework gives programmers the capabilities they clearly want, the better.
Prepare for your screen to become much more colorful! In previous iOS versions, the supplied widgets came either in a single color scheme or in a limited set of optional color schemes. A switch (the thing that says ON and OFF) was blue when ON and that was that; now it can be any color. That sort of thing is true for most of the standard widgets that constitute the interface. Custom images can be added to most widgets, and it’s easy for the programmer to enforce a uniform custom color scheme throughout an app.
A number of widgets are altered in subtle ways; a switch, for example, now has a round sliding part instead of a square. Alerts (tiny dialogs with buttons) can now accept text input. A completely new widget is the stepper, allowing the user to increase or decrease a number by tapping. Table views are more powerful. A split view, like what you see in landscape orientation on the iPad in our TidBITS News app, is no longer forced to hide the “master” view into a popover summoned by a toolbar button when the user rotates to portrait orientation.
Drawing effects such as blurring, previously available only in Mac OS X, are now provided also in iOS. Applications now have direct access to the hardware for dimming the backlight on the device (previously, only Apple’s own iBooks could do this). Any application can display the dictionary definition for a selected word.
Conclusion -- Let’s sum up. Based on the changes in the capabilities with which iOS 5 endows the programmer, what changes can you, the user, expect to see as more and more iOS 5-native apps come online? Data, such as documents and preferences, will be optionally stored in the cloud and thus shared between instances of an app on different devices. Apps should run more reliably as it becomes easier for programmers to avoid memory-management mistakes. The screen should become a brighter, peppier place, as programmers endow their widgets with color. And interfaces generally should become more expressive and more original, as programmers are able to let you navigate between subviews in novel ways.
The genius of iOS is that it allows the programmer to do much with little. There are remarkably few built-in widgets; yet they are sufficient to endow the tiny iPhone screen with great power and ease of use. To me, iOS 5 (from the programmer’s point of view) is a natural development, based largely on Apple’s own observation of the ways in which programmers have pushed at the boundaries of what the framework was readily permitting them to do; it’s an evolution, a coherent growth, gently expanding the programmer’s range of abilities while continuing to respect the conventions that have made iOS such a hotbed of great apps.