ATS & https demands for iOS

 ATS & https demands for iOS

New Apple ATS and https demands for Iphone and iPad (iOS) from 2017. Read about what you are going to have to implement in your app to secure a smooth transition. 

If you have been working with iOS apps in the last couple of years, or more precise since the release of iOS 9, you might have noticed that Apple has introduced App Transport Security (also known as ATS). 

ATS is, in short, about all the web-communication in apps which support iOS 9 or newer versions that in principle has to be directed through https instead of http. ATS is enforced by the NSURLSession class and all APIs that are using this class is automatically activated from iOS 9 and newer versions. 


Prerequisite for support of https

Your app has to be implemented so that it communicates via https and not http. 

The content provider that your app is using will have to support and display via https. 

The challenge with ATS arise if your content provider do no support https. They should of cause support https, but if they don’t then start by asking them to exclude https. This will solve the problem and all you have to do is to implement the first point above. 

We all know that the world is not that simple and there is no way that we can garanti that we can get https support from tomorrow, which is why Apple has been so kindly as to offer multiple exceptions for ATS which can be included in the Info.plist filen: 


NSAppTransportSecurity : Dictionary {

    NSExceptionDomains : Dictionary {

        <domain-name-string> : Dictionary {

            NSIncludesSubdomains : Boolean

            NSExceptionAllowsInsecureHTTPLoads : Boolean

            NSRequiresCertificateTransparency : Boolean

            NSExceptionRequiresForwardSecrecy : Boolean

            NSExceptionMinimumTLSVersion : String



    NSAllowsArbitraryLoads : Boolean

    NSAllowsArbitraryLoadsInMedia : Boolean

    NSAllowsArbitraryLoadsInWebContent : Boolean

    NSAllowsLocalNetworking : Boolean



You can among other things indicate NSExceptionDomains and this way allow http for one or multiple domains. If the domain already supports https but not an older standard you can also place exceptions for this by using one of multiple keys. You also have the possibility to enable ATS completely by setting the NSAllowsArbitraryLoads key to yes. 

Until now its been possible to add exceptions and as mentioned, to enable ATS completely if your content provider couldn't be persuaded to put a SSL binding up, which should be possible from 2017.


No excuses any longer. Except when it’s a really good one…  

Apple announced under a WWDC 2016 lecture that ATS will be in demand from the end of 2016 (see it here) 

That announcement has create some uncertainty as to what that means for ones existing apps, and what to do when you can’t get that https connection from a third party provider that you been wishing for more that a year? Purely technically ATS is still going to function as iOS 9 but with a few couple of possible exceptions. 

New is in the app store review. More of the possible exceptions, like for exemple to deactivate ATS completely or just for one domain will demand some good arguments from the beginning of 2017 — with the chance of having weak arguments and your app update could be rejected by Apple.


What to do now? 

You should examine wether your content provider or third party components already from today supports https with TLS 1.2. If yes, all you need to do is to adapt your app to communicate via https and lean back knowing that everything is okay. 

If you are having content providers, which are not supporting ATS then you should examine if they can upgrade their connection within a foreseeable future. 

If https is not or will not be a possibility then you should for apps that are released for iOS 9 consider if your argumentation is good enough for getting your next app through the review. If your app still isen’t released for iOS 9 or later, and you are in the process of preparing this you will have to setup your Info.plist with the relevant exceptions. And if you are using one of the below keys then consider if your argumentation is good enough to ret through the app review.  




You can read more about some of the scenarios where Apple is considering to let its apps slip through without https, and you can also see which scenarios do not need argumentation to get through the review process. 



This leaves us with the following conclusion

All iOS apps with a couple of specific exceptions are going to have to use https from 2017. You might bypass this demand for https if you can argument that https is not possible for your app, 

you can ignorer the demand for https if your app is build for a specific iOS8 or earlier version. It is excepted that apps, which a released within the end of 2016 will be able to use http. Updating in 2017 will demand https instead. 

By Brian Hansen

iOS Developer at Touchlogic