If you’ve been vacationing on the far side of the moon, you may be unaware that Apple released a mess of hardware and software two weeks ago, including iOS 6. If you’re back on Earth and you haven’t installed iOS 6 by now, you’ve doubtless noticed your iOS device (assuming that it’s of fairly recent vintage) trying to gain your attention by badging various icons and generally nagging you to upgrade your system software. At the same time, numerous apps have already been revised for compatibility with iOS 6, and this process can be expected to continue for a while. The excitement is palpable.
For me, though, the exciting part of a new iOS release isn’t the visible system-level changes and built-in apps. iPad finally gets a clock? It’s about time. (Ha ha.) Customizable photo streams? Whatever. Facebook integration? Gag me with a spoon. Siri can launch apps? Should have done this all along. And if Apple feels like jumping the shark by throwing the Google Mobile Maps service out the window in favor of its own maps, that’s fine.
To me, the fun of iOS is programming it. iOS is a wonderful platform to program; that’s why I wrote a book about it (“Programming iOS 5”). What interests me about a new iOS release is what it lets developers do. And you should care about this too, because what developers can do affects what they’ll build into apps when writing or rewriting them to adopt iOS 6 features. And that, in turn, affects what you will see and what you’ll be able to do.
Almost a year ago (see “How iOS 5 Will Affect Developers — and You,” 17 October 2011), I described certain aspects of the then newly released iOS 5 from a developer’s point of view, and made some predictions (which turned out to be extraordinarily accurate and prescient) about how these would affect what users would see on the screens of their iOS devices. This article attempts to do the same for iOS 6. As in my earlier article, I stress that there’s nothing here you couldn’t deduce for yourself; my sources are mostly Apple’s own release notes.
Pay No Attention to That Man Behind the Curtain -- Some of the most far-reaching changes are those that occur far upstream from end users, in the realm of the tools developers use.
For instance, Objective-C, the native programming language of iOS’s Cocoa touch world, has gained a few elegant shortcuts. None of these are earth-shattering — certainly nothing as fundamentally revolutionary as Automatic Reference Counting, on which I reported in my earlier article — and none of them will mean anything to you if you’re not an Objective-C programmer, so I’ll spare you the technical details of such things as autosynthesis. But trust me when I say that these changes, while small, are part of an Apple agenda of rationalizing Objective-C (to the extent that it can be rationalized, given the age and complexity of its underpinnings), and will mean a lot to developers, in this simple sense: they won’t have to write as much code, so they’ll be able to put more time and effort into what matters to end-users, namely the actual functionality of the app.
Xcode, the milieu in which iOS programmers work, has evolved to version 4.5, and again this will generally mean less work for developers to achieve goals they were previously accomplishing in a more frustrating, time-consuming way, even though you won’t know that’s happening. Take, for example, storyboards, introduced in Xcode 4.2 as a way of letting developers describe graphically the relationship and transitions between the “scenes” of an app (where a “scene” means, roughly, the interface that currently occupies the screen as a whole). It sounds convenient, but in fact storyboards were originally implemented in a half-baked way. In my book about programming iOS 5, for example, I pointed out that to use a storyboard to design a simple animation-free “modal view” transition was much more work than doing the same thing without the storyboard, because the storyboard interface provided no way to specify “no animation”, and no way to get back from the modal view to the view that triggered the animation. In Xcode 4.5, that and other storyboard limitations are removed, making storyboards more inviting to work with.
Another interface design feature of Xcode 4.5 and iOS 6 is the introduction of “constraints”, a new way of describing how interface elements should automatically move and resize themselves when the surrounding interface changes its size. Interface rearrangement has always been a challenge for iOS developers, as the interface must reconfigure itself any time the user rotates the device and the interface rotates to compensate. The early API for describing automatic interface rearrangement worked well for simple interfaces, but complex layout rearrangements among multiple interface elements had to be coded by hand, or (more probably) avoided entirely by keeping the interface fairly simple.
Constraints were already available to desktop developers starting with Mac OS X 10.7 Lion, and you may already have seen their effects without realizing it. For example, look at how, in 10.7 Lion and 10.8 Mountain Lion, in Apple Mail, when you make the mailbox list on the left wider or narrower, the Delete button in the toolbar slides along to match. Before constraints, such an effect was virtually impossible; the layout of a toolbar was a separate world from that of the main window interface, and followed its own rules. With constraints, that behavior requires effectively no code at all; it can be designed directly in Xcode. Now that iOS 6 implements constraints, iPhone and iPad users may expect to see some similar increase in the sophistication of interface layout.
All the Lonely Frameworks, Where Do They All Belong? -- iOS 6 has piled on some additions and changes to various specialized frameworks, and developers of certain kinds of app will want to take advantage of them.
The new maps architecture allows apps to interact more easily with the Maps app: instead of displaying its own map, an app can tell the Maps app to display a point of interest. Moreover, there’s a new API for letting apps provide turn-by-turn directions, and such an app can share its knowledge with other apps, such as the Maps app, so that they can display those directions as well.
The new Passbook app (see “Passbook’s Best Is (Probably) Yet to Come,” 20 September 2012) functions as a library for passes (a pass, in general, is any sort of redeemable ticket or token). Vendors can provide passes through email or the browser; apps can also communicate with Passbook to create, delete, and manage passes. The Twitter framework of iOS 5, allowing any app to offer the opportunity to send a tweet, has been expanded to include Facebook and Weibo. Apps can now communicate with the Reminders app. You can expect to see apps taking advantage of these expanded powers, along with improvements in the Game Center and in-app purchase delivery.
You’ll also notice that your iOS device running iOS 6 evinces a new wariness about letting apps access your various libraries of information. I have always found it sadly ironic that in the supposedly “sandboxed” world of iOS, an app must obtain the user’s explicit permission in order to display an image from the Photos library — on the dubious grounds that such an image might contain GPS coordinates, and GPS coordinates constitute oh-so-sacred location data — while any app, without the user’s knowledge, is perfectly free to manipulate your Contacts library however it likes, including relaying all the email addresses to a server in the Ukraine, changing all the phone numbers to ring up a pizza delivery service, or just wantonly deleting all the data. In iOS 6, the user is notified the first time an app tries to access a library, and is free to grant or deny such access, just as with Location Services.
A Box of Toys -- This is the stuff that makes me feel like a greedy, selfish kid ripping the wrapping off presents: the shiny new changes in the toolbox, the repertoire of interface widgets that Apple gives its developers to play with. What did you bring me this year, Apple???
The major new widget that will have the biggest impact on app interfaces is the collection view. A collection view is like a table view on steroids. A table view is the scrolling column of cells commonly seen in any master–detail app where a list must be displayed; Settings, Mail, and Music are familiar examples. A collection view breaks the bonds of the single vertically scrolling column, so you can expect, in short order, to see horizontally scrollable rows of data, multicolumn tables, and grids of information.
Such things were not impossible in the past, but they could be quite tricky for programmers to construct, especially if you had many rows or columns of information to display. You can’t simply form the whole grid display in advance to make a vast user-scrollable view; that would cause the device to run out of memory, and your app would be summarily killed. Instead, you have to work one screenful at time, loading the data and forming its visual representation as needed — that is, as the user is about to scroll that representation onto the screen — and freeing up memory when the user can no longer see a representation.
A table view does this dynamic memory management automatically for the programmer, which is why a table can be very long; but it’s limited to a single vertically scrolling column. Programmers who wanted a horizontally scrolling table, or a scrolling grid, as in the Photos app, could perhaps create it as a one-off with some serious effort and ingenuity; but it wasn’t easy, and such interfaces are not common, especially when the data is of any size, and are sometimes rather sluggish. The collection view generalizes the entire notion and makes it easy, and implements it efficiently.
Moreover, the collection view generalizes the notion of layout. Thus the lines of represented data don’t have to be regular; they don’t even have to be straight lines! Apple’s WWDC 2012 videos demonstrate a collection view being used to implement Cover Flow View, as seen in Mac OS X’s Finder or iTunes, where items appear to twist and change size as they scroll across the screen; the videos even show a collection view displaying photos in a circle. So you can expect the collection view to form the basis of some very interesting interface in iOS 6 apps.
Most of the other widget changes in iOS 6 rationalize and tighten up what iOS was already doing; they fall less into the category of “new” and more into the category of “totally obvious and why didn’t you do this long ago?” For example, iOS knows how to draw text in multiple styles, as Mail and iBooks prove, but developers couldn’t use such text in the labels, button titles, and editable text fields that permeate the interface; now they can. More drawing effects available on the desktop are now possible in iOS; for example, we can now easily invert an image’s colors, make interesting tiling patterns, and perform new image transitions. Page view controllers now allow pages simply to slide, without the telltale “page turn” animation. The march of color and customizability begun in iOS 5 (and noted in my earlier article) now encompasses additional basic widgets; watch for switches that say something other than “ON” and “OFF” (at long last!), along with wild-looking steppers and more.
Many other changes will have no obvious visible manifestation, but will mean a lot to developers. For example, Apple has changed how developers signify whether a certain view rotates to compensate when the user rotates the device; you were probably unaware that the old architecture for doing this was challenging and inflexible, but developers weren’t, and will rejoice. Similarly, table views now let the developer control easily whether the user can tap to highlight a cell, and section headers and footers are more efficiently managed. Still deeper under the hood, iOS now acquires from OS X some cool collection classes, such as NSMapTable, that only a programmer could love — and does.
Evolutionary Magic -- It’s easy for end users of an iOS device to let the magic of the interface lull them into a sense of acceptance and entitlement: it just works, and most users don’t care how. When I look at an iOS app’s interface and behavior, however, my first impulse is always to try to guess how the app works under the hood and how it accomplishes its magic. Knowing more about how iOS works from the developer point of view makes the magic more impressive, not less.
The iOS SDK — the developer toolbox for programming apps — was revolutionary when it first appeared (as the iPhone SDK), an ingenious rethinking of Mac OS X’s Cocoa aimed at a device with a small screen, a slow processor, limited memory, and only the user’s fingers to tell it what to do. Since then, the changes have been mostly evolutionary. iOS has grown, to be sure — there’s a reason why the second edition of my book is 200 pages longer than the first edition — but mostly it has become cleaner, clearer, more flexible, and more sensibly architected on every release. Linguistic features like blocks and ARC have made Objective-C more elegant and less tedious. Interface widget management tools such as custom view controller containment and view appearance proxies have provided clean, reliable, efficient ways to obtain effects that visionary programmers and designers previously had to accomplish with fragile hacks.
iOS 6 is no exception. It has grown from iOS 5 like a tree: it’s taller and has a few more branches, but what’s really important is that its roots are deeper and more solid. Many sentences in my book where I complain of a missing feature, an inconsistency, a hole in Apple’s logical thinking, can now be deleted. What’s new in iOS 6? It makes developers happier. And in the long run, as their apps come down the pipeline, that’s going to make you happier.