New in iOS 7: What developers need to know
The revamped UI, dynamic type, new multitasking modes, and 64-bit support point to new classes of apps -- and devices
Apple's execution on iOS 7 and Xcode 5 is yin and yang. In the Xcode 5 IDE, the UI scarcely changed, yet beneath that surface major improvements were made to the tools. In iOS 7 it was the UI that underwent major changes. To support this makeover, some Cocoa Touch frameworks also underwent modifications, and new frameworks were added.
This article is your guided tour of what has changed in iOS 7. Since there are so many changes, I have limited my coverage to those features that I think are most significant over the long term.
[ Also on InfoWorld: Review: Xcode 5 makes better, faster, stronger iOS and OS X apps | How iOS 7's new APIs change the game for business | Keep up with key Apple technologies with the Technology: Apple newsletter. ]
Content is king
Let's start with that UI. Simply put, in iOS 7 a lot of the chrome that made up the interface elements in iOS 6 -- such as borders on buttons and glossy hues that rendered navigation bars and tabs opaque -- is gone. In iOS 7, most UI controls lack borders and are translucent. Alerts and dialogs now display panels that present the choices as strings rather than as a gleaming array of buttons or controls. The new interface seems barren at first, but its simple, stark look grows on you. Instead of a dark screen that presents a clot of UI elements, now you have a bright, wide-open space that's clean and uncluttered.
Apple struck a delicate balance here. Although the appearance of the UI elements has changed, their behavior and the gestures you use with them have not. For example, a swipe to the left in a table cell still presents a delete or choice panel. After the initial jolt of the UI's different appearance wears off, you quickly get your bearings and resume work because things behave as before. If you think this was a simple thing to achieve, ask any Windows user who migrated to Windows 8 what it means to attempt a UI makeover without considering the consequences of eliminating or moving key controls.
Why risk an overhaul of the UI? The purpose was to give more screen real estate to the app developer. Buttons, tabs, navigation bars, and other controls are translucent, which allows the screen to display more content. Even the status bar at the top of the screen, which displays the signal strength and battery level, is translucent. That change alone gives you an extra 64 pixels (portrait mode) to 52 pixels (landscape mode) to work with.
To fully grasp the scope of this change, the revised Cocoa Touch class
UIControllerView, which is the nerve center for an app's screen display and user interactions, now owns the entire screen. Previously,
UIViewController had access only to that portion of the screen that wasn't occupied by the status bar, plus any navigation bar and tabs. A new set of properties for this class allows the view window to use the traditional iOS 6 dimensions or to expand its layout to the edges of the screen. Or you can extend the view window preferentially in one direction -- say, toward the top or right.
This shift to the emphasis of content is a huge deal. All of those pixels in Retina displays that formerly went toward the rendition of UI controls are now available for content display. That said, content under a control (such as the navigation bar) is blurred slightly, by design. However, this still lets you present a bigger picture to the user so that they can readily navigate through a lot of material, even on a small screen.
For arranging an app's UI elements, Apple notes that developers should use Xcode's automatic layout feature as much as possible. That is, let iOS handle the positioning of the UI elements on the screen. This implies that in the future we'll be seeing iOS platforms with different screen sizes.
No more bling: a dialog in iOS 6 (left) compared to its counterpart in iOS 7 (right).