Code Watch: What’s not to like about iOS 7’s APIs?

Mobile development continues to advance with Apple’s new iOS 7 APIs. While most people have been chattering about the new, flatter interface, I have grown more and more excited about the new changes and capabilities of the underlying OS. The changes are extensive, ranging from new design requirements (such as a new set of icons sizes) to entirely new programming models, such as that of Sprite Kit.

Some changes are fussy, such as views having their origins behind the top status bar as opposed to vertically beneath it. This affects many applications, especially those control-heavy line-of-business applications most commonly written by SD Times readers. Other changes are elegant, such as the addition of perspective and 3D buildings in map views simply by setting an “MKCamera” at the desired viewpoint and setting “ShowsBuilding” to true.

My favorite new APIs, though, are the ones that suggest entirely new applications. The aforementioned Sprite Kit is one, which makes 2D physics-based games distractingly easy, but I think the most significant for SD Times readers are the APIs relating to iBeacons and Multipeer Connectivity.

iBeacons are a new capability that combine large-scale geofencing with fine-grained radio-based ranging. iBeacons are associated with a GUID rather than a list of hardcoded locations, so as soon as a new storefront or location is added, a company’s iBeacon-based app works with the new facility, notifying the app every time a user comes within range. Once the user is within Bluetooth range of the iBeacon, the app can start finer-grained ranging, offering department-specific specials, creating a receipt when the user walks up to the register, etc.

Today, only iOS devices can serve as iBeacons, but there is already one company (www.estimote.com) that intends to create low-cost hardware, and Apple says that they will release a Bluetooth profile, opening the possibility of broad support.

Multipeer Connectivity is another radio-range capability that allows devices that are either in Bluetooth range or on the same network loop to advertise, discover, and communicate easily. While this capability has always been there with Bonjour/zeroconf networking, MPC is vastly easier to program.

I see iBeacons and MPC as having a powerful synergy. Perhaps I have a dirty mind, but I feel certain that we’re about to see a bunch of businesses competing to be The Great Hook-Up App. (On the other hand, there are only 2¹²² GUIDs, so not every kink will be available.)

On the more mundane level, the combination of ad hoc location and ranging plus ad hoc communication and data transfer suggests any number of major opportunities for restaurants, conferences and convention centers, or any other business where short-range communication among strangers may be valuable. Although iBeacons are non-directional, overlapping iBeacons can be used to divvy up an area with arbitrary precision.

Another set of APIs I’m excited about are collectively known as Text Kit. Apple’s standard naming technique is to divide APIs into lower-level “core” APIs and easier-to-use “kit” APIs. Prior to iOS 7, it was difficult to make iOS applications with good-looking text: You could either use the famously-difficult Core Text APIs, or you could embed a “UIWebView” and use standard CSS and HTML. The Text Kit APIs are a little confusing initially, as they are designed to work with potentially book-sized text volumes, but once their relationships fall into place, it is straightforward to create complex, great-looking typography, complete with complex text-reflows, multi-column formatting, and virtually everything else that could be desired. (Admittedly, typography is one of those domains where “everything else that could be desired” is probably infinitely complex.)

One API that I haven’t been able to see in action is the new Core Motion namespace. This namespace provides APIs for background movement processing, such as a step-counting API and for determining if a GPS update was from walking, running, or driving. It’s easy to program against, but I’ve yet to find a device on which it is enabled. This API is clearly primarily designed to take advantage of the new M7 chip in the iPhone 5s (which I strongly suspect will also be a component of the rumored iWatch).

Speaking of processors, Apple surprised everyone with the announcement that the iPhone 5s uses a 64-bit A7 chip. The good news is that the 64-bit A7 runs 32-bit apps in compatibility mode, so it’s a non-breaking change, but few observers expected to see a 64-bit phone until circa 2015. It seems like a pretty odd voluntary call given the increased size of pointers and data structures.

So far we haven’t seen any Apple hardware that pushes the 32-bit addressable-memory limit of 4GB. Yeah, no phones, no tablets, no… What was that? Oh yeah, I guess a totally revamped Apple TV based on iOS would probably need 64 bits to compete with the Xbox One and PS4, wouldn’t it? And oh yeah, what’s that about a new namespace called Game Controller and APIs that are specifically documented as only responding to “hardware keyboard inputs”? Huh.

In other speculation, one interesting note is that the new iOS APIs have a different “feel” to them. They’re a little looser, a little less classically object-oriented, and a few previously-unusual techniques are more commonly relied on (such as the operating system handing back a completion handler in a delegate object event). Whether this is a sign of new standards or new leadership is hard to say, but one worries that it’s related to some of the APIs (Sprite Kit, for instance) resulting in more segfaults than usual (is “explode-y” a term?). Everything works when called in the proper order, but iOS has typically been more robust against such typical development-time mistakes.

Everyone is waiting to see consumer sentiment to the new iOS 7 UI, and I don’t make any claims to insight there. From a programmer’s perspective, though, all the action is in the APIs, and there, I think, Apple has done an excellent job.

Larry O’Brien is a developer evangelist/advocate for Xamarin. Read his blog at www.knowing.net.