WWDC 2015 introduced iOS 9 to the developer community. As is typical for Apple, this precedes a Fall 2015 introduction, likely tied directly to the release of the next iPhone. On their current tick-tock release schedule, that will be the iPhone 6S just as the 3, 4, and 5 before it.While Apple certainly released a large number of new APIs and enhancements, as well as WatchOS and Swift 2 going open source, most current development work is done on the iOS platform and so I’d like to look at some iOS 9 announcements that may have unexpected impact on the development community.

iOS 9 Open Beta

As Apple did with OSX, they now follow suit on iOS. Traditionally Apple never released beta versions of software nor OS updates to the general public. In the past, a WWDC announcement of a new OS update would mean about a 5 month lead time to prepare applications for the release.

Just last week, Apple released the public beta of iOS 9 to anyone who wants to use it. Early reviews from The Verge and ArsTechnica are cautioning users against jumping in, though the reviews definitely make iPad upgrading look very tempting.

However, low review scores could accumulate as less-tech-savvy early adopters jump into iOS 9 blindly and discover all the fun bugs you haven’t had an opportunity to address. Small teams with limited developer resources could in particular be affected.

As well, debugging and developing on iOS 9 requires installing Xcode Beta 7 and using it in a production environment on production code, and all of the normal risks that come with that. It will be interesting to see how the public beta affects aggregate review scoring.

New Safari Behavior

For collecting analytics on user installs, many applications use a tracking cookie in Safari that is obtained through a redirect to Safari, which then redirects back to the application proper upon completion. iOS 9 now presents transitional applications, such as automatically launching Safari, with a Return to (your app name) button located in the topmost status bar.

The “Return to App” button is a new UI metaphor that users are not accustomed to yet, and is not particularly obvious. As well, after the installation tracking launches Safari and returns to your app, behavior is such that a “Return to Safari” button appears in the status bar. The button does disappear automatically after a short period of time, but could be confusing for users as being some kind of prompt, or suggestion, to leave your app.

The new Safari Services Framework, allowing the presentation of a real Safari view controller which has access to all Safari cookies and website data, may mitigate this issue. When presented, the user can be shown a “Done” button and the presentation should be such that the entire experience feels like an in-app process, rather than the app-safari-app switching method that is commonly seen.

App Transport Security

iOS 9 now defaults to requiring HTTPS for transport connections. This shouldn’t pose a large challenge to developers, but is something that requires extra attention and care.

URL Handling

Two big changes to link handling are introduced with iOS 9.

First, to prevent developers from snooping into users’ privacy, the call to canOpenUrl: is now limited to 50 whitelisted URLs. Previously, it was possible to call this indefinitely to “sniff out” the existence of specific apps on a user’s device. This is a win for consumers, which is typically the direction Apple favors. Developers should note that this call now comes with a cost and should be treated appropriately.

Second, Universal Links have been introduced. This represents a trusted connection between your app and a given URL scheme. Rather than canOpenURL:, Apple wants developers to create explicit trusts and simply call openURL:. If the trust has been established between the in-app associated-domainsentitlement and an apple-app-site-association JSON file on your website, your app can callopenURL: without having to check for availability first. If possible, the app will open the URL. If it cannot open the URL, Safari will take over automatically.

Third, the registered URL scheme methodology used prior to iOS 9 (MyCoolApplication://~) must now be white-listed in the LSApplicationQueriesSchemes key in Info.plist. Failing to do so will result in a silent failure, with a corresponding syslog “This app is not allowed to query for scheme ~~~“. It is suggested that this is a bug, but if so it still remains in last week’s iOS 9 Public Beta.

This can also spell trouble for apps that attempt to provide an “App Store” experience, providing redirected app installs, using canOpenURL: to determine whether a promoted app was previously installed or not. Once all apps have completed their transition to the new Universal App scheme, user experiences will be much better, as well as removing the possibility of URL scheme cross-contamination, where two applications register for the same scheme.

However, the transition looks to have some bumps in the early days that could prove frustrating for developers and users alike.

Auto Layout

Apple showed multitasking for iPad on iOS 9. With a cleanly designed user interaction as well as simply being a much-requested feature on iPad, users with appropriate hardware will likely take advantage of this feature immediately. Given what I have witnessed in code first-hand on a number of projects and what I hear when talking with other developers, the complexity and frustration of using auto-layout has restricted its adoption in many cases.

Does your app rely heavily on auto-layout to do its UI structuring? I’m willing to bet many have not adopted this feature fully enough to feel assured that their app will scale beautifully in the iPad’s new multitasking envornments.


Media Player and Address Book Frameworks have both been deprecated in iOS 9. Media Player usages need to switch over to AVKit/AVFoundation, and Address Book usages should move to the new Contacts Framework.

iOS 9 Changes

What’s New in iOS 9: requires developer account to access