App Transport Security (ATS) makes iOS apps use HTTPS for connections made through the standard URL loading system and blocks servers that fall short of minimum TLS standards. Your API needs a valid certificate, TLS 1.2 or later and forward secrecy. Fix the server before you add an exception to the app.
What ATS enforces
Apple's documentation says ATS applies by default to apps linked against the iOS 9.0 or macOS 10.11 SDKs or later. It requires that connections made with URLSession use secure URLs, and it blocks cleartext HTTP.
On top of the normal certificate trust check, Apple lists extra requirements for the server:
| Requirement | Detail |
|---|---|
| Certificate key | RSA of at least 2048 bits, or elliptic curve of at least 256 bits |
| Certificate hash | SHA-2 with a digest of at least 256 bits |
| Protocol | TLS version 1.2 or later |
| Cipher | AES-128 or AES-256 |
| Key exchange | Forward secrecy using ECDHE |
The normal checks also apply: an intact signature, an unexpired certificate, a name that matches the server, and a chain that leads to a trusted anchor.
What ATS does not cover
Apple states that ATS does not apply to calls made through lower level networking such as the Network framework or CFNetwork. In those cases the developer is responsible for the security of the connection, and Apple warns that mistakes are easy and costly. Check how your app and its SDKs make connections, because a library using low level calls will not get ATS protections.
Exceptions and why to avoid them
An app can add an NSAppTransportSecurity dictionary to its Info.plist to loosen rules, for example for one domain. Apple's message is consistent: it is always better to fix the server, exceptions reduce the security of the app, and some exceptions need justification when you submit to the App Store.
If a build ships a broad exception, treat it as a finding. Ask what server needed it and whether that server has since been fixed. Global exceptions often outlive the reason they were added.
Steps for an API owner
- Test every API host against the table above, including older staging and partner hosts.
- Check that certificates chain to a trusted public authority and are renewed on time.
- Disable TLS versions below 1.2 and cipher suites without forward secrecy.
- Ask the mobile team for a list of ATS exceptions in each shipped build.
- For every exception, open a ticket to fix the server and remove the exception.
- Review SDKs that open their own connections to see whether they bypass ATS.
ATS and pinning
ATS and pinning solve different problems. ATS sets a floor for transport security. Pinning narrows which certificates the app trusts. Apple notes that with ATS enabled you can no longer loosen trust evaluation, but you can still tighten it, which is how pinning is done. ATS also supports declaring pinned domains and Certificate Transparency requirements in the same configuration.
Why it matters beyond the app
A mobile API often shares hosts with a website, partner integrations and older app versions. Raising a host to the ATS floor helps all of them. It also means an old server with weak TLS shows up quickly, because the iOS app simply fails to connect.
Safeguard's asset discovery helps you find API hosts you may have forgotten, and SBOM and dependency scanning shows the networking libraries inside your builds. You can start with the free scan at gold.safeguard.sh/scan.
Quick check
Does ATS protect every network call my iOS app makes?
No. Apple says it does not apply to lower level interfaces such as the Network framework or CFNetwork, so those connections are the developer's responsibility.
Is it fine to ship a global ATS exception for a legacy server?
Apple recommends fixing the server first. An exception reduces the security of the whole app, and some require justification at submission.
Sources
Last reviewed: 19 October 2026.
