You’ve read the WWDC announcements of all the cool stuff coming in iOS 9. As a mobile PM or tech lead, now is the last change to ask yourself if your app needs any updates to be “iOS 9 ready”?

Based on past history Apple tends to push major iOS version updates around the middle of September, often aligned with their Autumn special event. That means there are less than 30 days left to squeeze through a last app update so that users switching to iOS 9 in September can keep on using your app as normal.

A simple approach

The quickest and easiest way to approach this is to huddle up with your iOS developers and review the iOS 9 changelog point by point. While doing this, take a piece of paper and draw a line down the middle of the page;

the left column is “Must Do” — changes you’re going to have to make so that your app keeps running as-is on iOS

the right column is “Nice to Have” — things you are planning to do in the but are not required for your app to continue to function as normal when iOS 9 hits the streets.

Must Do

Unlike iOS 7, which made apps that failed to react suddenly look really ugly, the good news is there isn’t too much in iOS 9 that you really have to do by September but there are two or three things you probably want to take a look at…

App Transport Security (ATS)

Thanks to Yuri Samoilov

Apple is making a big push on privacy and part of that is nudging app developers to use HTTPS (SSL) instead of HTTP so all backend calls.

That means your app should use SSL for requests to your REST api plus any 3rd party services such as analytics. From the changelog…

“ATS prevents accidental disclosure, provides secure default behavior, and is easy to adopt; it is also on by default in iOS 9 and OS X v10.11.”

So it’s on by default from iOS 9! You can explicitly disable it for your app or whitelist specific domains for access via unsecured HTTP but you must take action here. If you do nothing and your various backends have no HTTPS support, expect trouble with iOS 9 in September.

“If you’re developing a new app, you should use HTTPS exclusively. If you have an existing app, you should use HTTPS as much as you can right now, and create a plan for migrating the rest of your app as soon as possible.”

As I read that, that means if you’re launching a new app after September 2015, it’s going to get rejected if you’re not using SSL for all connections. Meanwhile existing apps are going to have some grace; based on similar changes in the past, Apple may allow as much as a year, until iOS 10, before enforcing. By that time all backend services your app consumes (REST APIs, image hosting, 3rd party analytics etc. etc.) must all be served via SSL.

For more info see Frederick Jacob’s write up of Apple iOS 9: Security & Privacy Features and Configuring App Transport Security Exceptions in iOS 9 and OSX 10.11 by Steven Peterson.

Custom URL Schemes vs. Privacy

If you’re using, for example, the Facebook or Google+ SDKs for social logins or have features where users can launch a 3rd party app from yours, via a custom URL scheme, you probably need to whitelist those apps.

Facebook does a good job of summarising this here and Stack Overflow has a hint about Google+ here. Meanwhile it’s worth reviewing a Quick Take on iOS 9 URL Scheme Changes.

ENABLE_BITCODE=NO

Apple introduced a bunch of new compile time and runtime things under the moniker “App Thinning”. There’s a nice introduction in The Skinny on App Thinning and some slides with practical detail here. That said, if you haven’t yet already verified your app is “Bitcode ready”, you probably need to disable this option by default in Xcode 7. Some more hints on stackoverflow about this.

Nice to Have

Otherwise some things to play close attention to in that changelog and plan for in 2015/16… (these ones you can Google yourself)

Search, Universal Links and Extension Points: in short, improving the discoverability of your app and it’s content i.e. more organic installs and traffic. Google this one, read everything you can about it…

iPad Multitasking could also be a nice to have for you app, depending on what your app does.

And a whole host of other stuff that you should review with your developers…

Over to you…