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.
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.
Making text legible
Another way Apple put those extra screen pixels to use was to support better typography. iOS 7 implements dynamic type: typefaces that can scale to all sorts of sizes and still retain their shape and weight. Instead of point sizes or type families, you simply specify a style and let iOS handle the details.
There are a number of style types to choose from, and they parallel those found in HTML tags: Headine 1, Headline 2, Subheadline 1, Subheadline 2, Body, Footnote, Caption 1, and Caption 2. If necessary, you can tweak the size and character spacing, again using semantic terms rather than actual point sizes. Support for dynamic type, ligatures, kerning, and accessibility type sizes are supported throughout the OS.
A new framework, TextKit, implements the dynamic type features. It is a high-level text layout API layered over the low-level CoreText text layout engine. All text-related UI elements (such as UILabel, UITextField, and UITextView) now use TextKit to manage text layout. TextKit can readily arrange styled text into paragraphs, columns, and pages. For complex layouts in which graphics are combined with text, you simply provide a Bezier path that outlines the graphic. TextKit lays out the text and avoids placing text within the path. This goes a long way toward supporting more sophisticated content delivery.
Better multitasking
For the record, iOS was a full-blown multitasking OS from the very beginning. At its core iOS uses the same Mach kernel and BSD libraries as its desktop sibling, OS X. Certain apps, such as Mail, Music, and Clock, ran in the background. However, Apple restricted access of third-party apps to the multitasking capabilities for security purposes, and the early hardware was limited in processing power, memory, and battery life anyway.
In iOS 4, limited multitasking was introduced to support apps that performed background audio playback, background location tracking, and push notifications. In iOS 7, several new background modes have been added: background fetch, remote notifications, and background transfers. The purpose behind these new modes is to keep your app's data current at all times -- even if the data updates come from a remote server.
Background fetch allows an app to fetch information periodically. To implement this, you notify iOS of the fetch interval using a UIApplication method call. Based on the interval, iOS periodically launches your app. Your app then invokes a fetch delegate method that grabs the data and exits.
Remote notification allows your app to respond to messages pushed from a server. iOS launches your app when the notification arrives. The app connects to the server, collects the payload, then exits.
Background transfers enable your app to manage larger data transfers. Your app launches and uses a delegate method that starts a session with a server. The delegate handles authentication to the server and possibly multiple transfer operations.
For all three multitasking modes, the app must call a completion handler that reports to iOS if the fetch operation was a success or not. In the event of a failure, iOS can restart your app later to retry the fetch or transfer.
More bang for the bits
iOS 7 is the first 64-bit mobile OS. Arithmetic operations, pointers, and addressing instructions all use 64 bits. Not surprisingly, Xcode 5 can generate 64-bit code to support this capability. In most cases, the wider data lanes can improve application performance; however, those larger values and pointers can also increase memory consumption. Even though there are advantages to migrating your app to 64 bits, it must be done carefully; otherwise, due to memory pressure, your app may actually execute slower.
iOS 7 supports both 32- and 64-bit execution modes so that older apps continue to run. My old iOS climate control app published on iTunes continues to work on iOS 7, although there was a blank area at the top that was an artifact due to the view not using the now-available status bar area. Going forward, developers should build their apps as a "combined binary" that contains 32- and 64-bit versions of the code. This allows the app to execute on platforms not running iOS 7.
The combined binary mechanism should work well, because Apple has done this migration trick before. When Macintosh computers switched from Power Architecture to Intel CPUs, the Xcode tools could make "universal binaries" that contained both Power Architecture and Intel code images. If you've been in the business a long time, you might even recall when the Macs moved from 68K to Power Architecture CPUs, and developers made "fat binaries" that could run on both platforms.
A significant advance
iOS 7 is a great leap forward in many ways. The new UI offers the developer more screen room to play with, even on small devices. The smarter text layout will enable a new category of publication and reader apps, I have no doubt. The 64-bit OS offers better computational throughput. This allows developers to use more powerful algorithms for speech and signal processing, and it will enable new apps to be published that until now were too computationally demanding for a mobile platform. In short, Apple has covered its existing consumer base with a top-notch software release.
This brings me back to the yin and yang of iOS 7 and Xcode 5. Apple touts iOS 7 as a desktop-caliber OS, and when you consider the advanced typography system and greater processing power, you might concede the point. Still, you have to wonder where the company is going with iOS.
Here are some clues we can follow. Apple has been pushing the auto layout features supported in Xcode 5 hard, so you have to figure there will be "iDevices" with different screen sizes. Might there be bigger tablets or even iOS-based laptops? Or "iDocks" that allow iPhones and iPads to use Apple's full-sized monitors and keyboards? iOS and OS X do seem to be on a collision course, so all three possibilities may eventually come to pass.
For the near future, however, I think iOS 7 enables Apple to enter specialized vertical markets or perhaps make a few new ones. In short, the yin and yang of iOS 7 and Xcode are poised to expand the mobile platform's reach beyond the competitive consumer market. The rest will be up to developers.
This article, "New in iOS 7: What developers need to know," was originally published at InfoWorld.com. Follow the latest developments in application development and mobile technology at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.