Use ATS in your iOS app by editing Info.plist, keeping HTTPS enforced by default. Enable exceptions only for trusted, necessary domains and always document your reasons thoroughly. Update certificates and protocols often, and review your ATS settings before every App Store submission for compliance. Secure connections aren’t just a requirement, they’re a promise to your users.
Key Takeaway
- ATS defaults keep user data safe by enforcing modern HTTPS and strong encryption.
- Exceptions must be strictly justified, domain-specific, and well-documented to pass App Store review.
- Regularly update and audit your ATS settings, certificates, and protocols to avoid security gaps.
ATS Configuration in Info.plist
Mention ATS at our bootcamp, and someone always remembers that first nervous moment editing an Info.plist. It feels technical, but really, it’s about trust, Apple’s and your users’.
ATS settings live under the NSAppTransportSecurity dictionary in your app’s Info.plist file. By default, ATS is enabled for all mobile apps targeting iOS 9.0 or later, meaning Apple expects every outgoing connection to use HTTPS with TLS 1.2 or newer.
We’ve seen people try to skirt this, perhaps to speed up development or accommodate old web services, but the consequences are real. Failing to configure ATS correctly can lead to unexpected app rejections, or worse, expose sensitive data over insecure channels.
It’s good practice to start your Info.plist with ATS locked down, then loosen restrictions only when absolutely necessary. [1]
Default ATS Behavior and Enabling ATS
Apple’s default ATS stance is strict. If you don’t add the NSAllowsArbitraryLoads key (or set it to NO), your iOS app will block all non-HTTPS connections. This means:
- Your app must use HTTPS everywhere.
- All servers must support TLS 1.2 or above.
- Outdated ciphers or expired certificates will break your app’s network requests.
We’ve noticed this sometimes breaks legacy integrations. Our advice: upgrade those old endpoints or find alternatives rather than weakening your security settings. Apple’s review team checks for compliance, so enabling ATS globally means fewer headaches later.
NSAllowsArbitraryLoads Key Usage
Sometimes, developers are tempted to use the nuclear option: setting NSAllowsArbitraryLoads to YES. This key, when true, disables ATS protection for your entire app. It’s a blunt instrument. We’ve seen apps rejected outright for this, especially when the justification is weak or missing. Apple expects you to use this only as a last resort, and even then, reviewers expect a clear, technical explanation.
If you’re tempted, ask yourself: can I scope the exception to a single domain? Can the backend team enable HTTPS? Global disabling should be rare. [2]
Domain-Specific Exception Handling
The right way to allow exceptions is through domain-specific configuration. Use the NSExceptionDomains dictionary in Info.plist to list domains that still require HTTP. Here’s a sample, one we often use in our training:
<key>NSAppTransportSecurity</key>
<dict>
<key>NSExceptionDomains</key>
<dict>
<key>example.com</key>
<dict>
<key>NSExceptionAllowsInsecureHTTPLoads</key>
<true/>
</dict>
</dict>
</dict>
This lets your app connect to example.com over HTTP, but keeps ATS strict for everywhere else. For each exception, document the reason, Apple will ask. In our experience, this approach is safer, more transparent, and more likely to pass App Store review.
NSExceptionDomains and HTTP Load Permissions
Domain-specific exceptions can also be fine-tuned. For instance, you can allow insecure HTTP loads while still requiring minimum TLS versions or blocking invalid certificates. These keys help you balance functionality and security:
- NSExceptionAllowsInsecureHTTPLoads: Allows plain HTTP.
- NSExceptionMinimumTLSVersion: Enforces a minimum TLS version (e.g., TLS 1.2).
- NSExceptionRequiresForwardSecrecy: Forces perfect forward secrecy, if possible.
We stress to our students: don’t allow more than you must. Every exception increases your risk surface.
NSThirdPartyExceptionAllowsInsecureHTTPLoads
What if your app loads content from third-party domains you don’t control? Apple provides NSThirdPartyExceptionAllowsInsecureHTTPLoads for precisely this case. It works much like NSExceptionAllowsInsecureHTTPLoads, but signals to reviewers that the domain isn’t yours.
We’ve seen this used for ad networks or analytics providers that haven’t enabled HTTPS. Apple still expects a detailed reason, ideally, include a migration plan in your App Store submission.
Global ATS Disabling: Risks and Consequences
Disabling ATS globally (NSAllowsArbitraryLoads to YES) is risky. We’ve watched teams do this for expedience, only to face App Store rejection or, worse, a data breach. The risks include:
- Exposing sensitive user data over unencrypted channels.
- Accepting invalid or self-signed certificates by mistake.
- Allowing weak cipher suites vulnerable to interception.
In our bootcamp, we teach to avoid global disabling, always. If you must, document every reason, and expect a tough App Store review.
Additional ATS Keys Introduced in iOS 10+
Credits: AppleInsider
Starting in iOS 10, Apple added more granular keys to help developers limit exceptions:
- NSAllowsArbitraryLoadsInWebContent: Disables ATS only for web views (like WKWebView).
- NSAllowsLocalNetworking: Allows HTTP for local resources, such as during device-to-device communication.
We’ve used these for hybrid apps, where third-party content or local servers are required. They’re safer than disabling ATS for the whole app.
NSAllowsArbitraryLoadsInWebContent for Web Views
Some iOS apps rely on WKWebView or legacy UIWebView for dynamic content. If you absolutely must load insecure content in a web view, use NSAllowsArbitraryLoadsInWebContent. It only affects web views, not the rest of your app’s network stack.
Our advice: encourage your content partners to move to HTTPS. Exceptions here can still trigger extra scrutiny during review.
NSAllowsLocalNetworking for Local Resources
Developers often want to connect to local devices or services. With NSAllowsLocalNetworking, you can allow HTTP for loopback addresses or local networks (like mDNS services). We’ve used this in training apps for IoT testing or local data transfer. It’s a reasonable exception, provided you don’t expose sensitive data or open ports to the internet.
Managing ATS Exceptions and App Store Compliance
Apple’s review process is strict. Every exception in your Info.plist raises questions. We recommend:
- Keep a detailed spreadsheet of exception domains, with justifications.
- Prepare a summary for your App Store submission (a few sentences per domain).
- Be ready to explain why HTTPS isn’t possible and what steps you’re taking to minimize risk.
We’ve found that clear documentation and proactive communication with Apple reviewers smooths the process.
Justifications Required for Exception Usage
App Store reviewers need specifics. “Legacy system” isn’t enough. We coach teams to explain:
- Why the domain can’t support HTTPS.
- What data is being transmitted.
- How users are protected despite the exception.
- When you expect to remove the exception.
Your Info.plist can include comments, but keep the main documentation in your submission notes.
Apple’s Security Expectations and Review Process
Apple expects you to treat ATS as the default and exceptions as rare. They look for:
- Use of HTTPS and TLS 1.2+ on all endpoints.
- Modern certificates: valid, SHA-2 signed, 2048+ bit RSA or 256+ bit ECC keys.
- Forward secrecy (ECDHE key exchange) on all connections.
- Minimal, well-documented exceptions.
In our experience, Apple will reject apps that weaken ATS for convenience or fail to provide technical justification.
Best Practices for Minimizing Exceptions
Here’s what works, based on our bootcamp’s hands-on coaching:
- Upgrade all backends to support HTTPS and modern TLS.
- Use domain-specific exceptions, not global disabling.
- Regularly audit your Info.plist for lingering exceptions.
- Document every exception, including business and technical reasons.
Enabling ATS Globally
We believe ATS should be enabled globally, with rare exceptions. This protects user data, builds trust, and keeps your app in good standing with Apple. Every time you add a new connection or endpoint, check its compliance with ATS requirements before launch.
Use of Strong Certificates and Modern TLS Settings
We teach our students to insist on:
- Certificates signed by trusted CAs, never self-signed.
- SHA-256 or higher signatures.
- 2048+ bit RSA or 256+ bit ECC keys.
- TLS 1.2 or newer, never SSL or TLS 1.0/1.1.
- Forward secrecy (ECDHE).
Weak certificates or outdated protocols will cause ATS failures and risk App Store rejection.
Documenting Exceptions to Support App Store Approval
Documenting exceptions is as critical as technical configuration. Include:
- The domain requiring exception.
- The reason HTTPS isn’t possible.
- The data transmitted.
- Your plan for future migration to HTTPS.
Attach this as part of your App Store submission. We’ve seen well-documented cases pass where vague ones fail.
Enhancing Security and Performance with ATS
ATS does more than block HTTP. It:
- Forces modern encryption, reducing the risk of interception.
- Improves app performance by enabling HTTP/2 and newer protocols.
- Gives users peace of mind, knowing their data is protected.
We encourage students to make ATS part of their security mindset, not just a hurdle for App Store approval.
Monitoring and Updating ATS Configurations
ATS isn’t set-and-forget. Servers change, certificates expire, and Apple’s requirements can shift. We recommend:
- Quarterly reviews of all ATS settings, exceptions, and certificates.
- Automated monitoring of server-side certificate validity and protocol support.
- Clear internal documentation for every change.
Keeping Certificates and Protocols Up to Date
Expired certificates or weak protocols will break your app’s network layer. We’ve seen this happen in production, causing outages and App Store removals. Stay ahead by:
- Setting calendar reminders for certificate renewals.
- Using tools like SSL Labs to check backend compliance.
- Coordinating with server teams regularly.
Integrating ATS with Third-Party Services
Third-party APIs and servers are a common exception source. Before adding an exception for a partner:
- Ask them to support HTTPS and modern TLS.
- Use NSThirdPartyExceptionAllowsInsecureHTTPLoads only if absolutely required.
- Audit their security policies as closely as your own.
We’ve found that proactive requests often lead to faster upgrades by service providers.
Secure Connections to External APIs and Servers
Whenever connecting to external APIs:
- Validate the certificate chain programmatically, if possible.
- Pin public keys for especially sensitive data transfers.
- Avoid exceptions for payment, authentication, or personal data endpoints.
We’ve caught mistakes in code reviews where developers almost allowed insecure connections to login or payment providers, never allow this.
Leveraging ATS for Secure Local Networking
Local networking is a special case. If your app needs to connect to a device on the same Wi-Fi, ATS allows exceptions for loopback and local addresses. Use this carefully:
- Restrict to specific IP ranges or hostnames.
- Never send sensitive data unencrypted, even locally.
- Monitor for accidental exposure to wider networks.
Balancing Security and Functionality in Local Environments
We’ve helped teams build apps that depend on local networking for hardware integration or testing. Our advice:
- Use NSAllowsLocalNetworking only in development builds where possible.
- For production, prefer secure connections, even locally, or sandbox features behind authentication.
Balancing security and functionality is often a negotiation with product teams, but user trust should always win.
FAQ
What happens if I disable ATS for media content in my iOS app without a clear reason?
If you disable ATS for media content like video or audio streaming, and you don’t include a reasonable justification in your app transport security settings, your app might fail App Store review.
Apple requires secure connections even for media. Unless that content can’t support HTTPS or you use legacy services, disabling ATS may violate ATS requirements and slow down approval.
Can I allow specific domains to use HTTP while keeping default ATS for the rest of my app?
Yes, you can use exception domain settings to allow HTTP for specific domains while still applying the default ATS rules elsewhere. Apple allows this if you provide a reasonable justification, like needing to access web services that don’t support HTTPS.
These ats exceptions must be declared clearly in your Info.plist and explained if questioned during an App Store review.
How strict is Apple about enforcing secure connections for third-party web services?
Apple enforces secure connections under App Transport Security even for web services you don’t own. If your app communicates with third-party APIs or media content sources that don’t support HTTPS, you need to create an exception domain with proper reasoning.
Failing to do so may cause your app to get rejected during App Store submission due to missing ats requirements.
What’s the best way to document ATS exceptions in a team setting or large project?
When working with large teams, you should expand documentation around ats exceptions to include who approved the change, the purpose, and the specific domains affected.
Document why the ATS restrictions were modified and whether secure connections can be restored later. Keep this with your internal release notes so it’s clear to everyone involved, especially if an Apple developer review follows.
Why is it risky to leave ATS disabled after a one-time exception is added?
Disabling App Transport Security settings, even for good short-term reasons, can expose sensitive data if left unchecked. Many developers forget to re-enable default ATS after debugging or working with legacy web services.
Leaving ATS off across your entire iOS app creates unnecessary risk and increases the chance of a failed App Store review. Always audit ATS changes before submitting.
Conclusion
You don’t need perfect memory for Apple’s security, just a repeatable process to configure, document, and defend your ATS settings. Each update, check your Info.plist, audit certificates, and ask if every exception still makes sense. Secure connections go beyond checklists, they protect users’ trust. Review often and document thoroughly to avoid surprises in App Store reviews.
Ready to build iOS apps users trust? Join the Secure Coding Practices Bootcamp for hands-on training. Join the Bootcamp
References
- https://developer.apple.com/news/?id=jxky8h89
- https://developer.apple.com/documentation/bundleresources/information-property-list/nsapptransportsecurity/nsallowsarbitraryloads
Related Articles
