Introduction

If you have ever tried to make an HTTP request from an iOS app and seen the error "App Transport Security has blocked a cleartext HTTP resource load since it is insecure," you have run into Apple's App Transport Security (ATS) policy. ATS exists to protect users by forcing apps to communicate over encrypted HTTPS connections. Understanding how it works, how to configure exceptions when necessary, and what the tradeoffs are will keep your app functional during development without compromising security in production.

What Is App Transport Security

App Transport Security is a feature Apple introduced in iOS 9 (and macOS 10.11) that blocks all unencrypted HTTP connections by default. Every network request your app makes through URLSession, WKWebView, or any Apple networking API must use HTTPS with modern TLS (1.2 or later). If the server does not support HTTPS or uses an outdated TLS configuration, ATS rejects the connection before any data is exchanged.

The exact error message you will see in the Xcode console looks like this:

App Transport Security has blocked a cleartext HTTP (http://)
resource load since it is insecure. Temporary exceptions can be
configured via your app's Info.plist file.

This error means ATS intercepted the request and refused to send it because the URL scheme was http:// instead of https://.

Allowing All HTTP Connections (Development Only)

The fastest way to unblock HTTP during development is to add the NSAllowsArbitraryLoads key to your Info.plist. This disables ATS entirely for all domains.

1<key>NSAppTransportSecurity</key>
2<dict>
3    <key>NSAllowsArbitraryLoads</key>
4    <true/>
5</dict>

In Xcode, you can also add this through the visual plist editor:

1. Open your project's Info.plist.
2. Add a new row with key App Transport Security Settings (type Dictionary).
3. Inside it, add Allow Arbitrary Loads and set its value to YES.

This approach is acceptable for local development and testing, but you should never ship an app with NSAllowsArbitraryLoads set to true. Apple's App Store review team flags this and may reject your submission unless you provide a valid justification.

Per-Domain Exceptions

The recommended approach for production apps that must communicate with specific HTTP-only servers is to define per-domain exceptions using NSExceptionDomains. This allows cleartext traffic only to the domains you specify while keeping ATS enforced everywhere else.

1<key>NSAppTransportSecurity</key>
2<dict>
3    <key>NSExceptionDomains</key>
4    <dict>
5        <key>api.legacy-server.com</key>
6        <dict>
7            <key>NSExceptionAllowsInsecureHTTPLoads</key>
8            <true/>
9            <key>NSIncludesSubdomains</key>
10            <true/>
11        </dict>
12        <key>internal.company.com</key>
13        <dict>
14            <key>NSExceptionAllowsInsecureHTTPLoads</key>
15            <true/>
16        </dict>
17    </dict>
18</dict>

Key settings within each domain dictionary:

• NSExceptionAllowsInsecureHTTPLoads allows HTTP (cleartext) connections to this domain.
• NSIncludesSubdomains applies the exception to all subdomains as well.
• NSExceptionMinimumTLSVersion lets you lower the minimum TLS version if the server uses older protocols.

This is far more secure than blanket NSAllowsArbitraryLoads because it limits the exception to only the servers that genuinely need it.

Why Apple Requires HTTPS

Apple enforces ATS because unencrypted HTTP traffic is trivially interceptable on shared networks. Anyone on the same Wi-Fi network can read, modify, or inject data into plaintext HTTP connections using basic network tools. HTTPS prevents this by encrypting the connection and verifying the server's identity through certificates. For apps that handle personal data, financial transactions, or authentication tokens, cleartext HTTP is a serious security vulnerability.

App Store Review Implications

Since January 2017, Apple has required that apps provide a justification for any ATS exceptions. If you submit an app with NSAllowsArbitraryLoads set to true, the review team will ask why. Acceptable justifications include connecting to legacy third-party APIs you do not control, loading user-provided URLs (web browsers, RSS readers), or streaming media from servers that do not yet support HTTPS.

If your own backend servers do not support HTTPS, the expected solution is to add HTTPS support rather than request an ATS exception. Free certificate authorities like Let's Encrypt make this straightforward.

Equivalent Configuration on Android

Android introduced a similar mechanism called Network Security Configuration in Android 7.0 (API 24). Starting with Android 9 (API 28), cleartext HTTP traffic is blocked by default, mirroring Apple's ATS behavior.

To allow cleartext HTTP on Android, create a network security configuration file:

1<!-- res/xml/network_security_config.xml -->
2<network-security-config>
3    <!-- Allow cleartext for a specific domain -->
4    <domain-config cleartextTrafficPermitted="true">
5        <domain includeSubdomains="true">api.legacy-server.com</domain>
6    </domain-config>
7</network-security-config>

Then reference it in your AndroidManifest.xml:

1<application
2    android:networkSecurityConfig="@xml/network_security_config"
3    ... >
4</application>

The per-domain approach works the same way conceptually: allow exceptions where needed, keep the default secure.

Common Pitfalls

• Shipping with NSAllowsArbitraryLoads set to true: This disables ATS entirely and will likely cause App Store rejection. Always switch to per-domain exceptions before submitting.
• Forgetting to include subdomains: If your API lives at api.example.com but you only add an exception for example.com without NSIncludesSubdomains, requests to the subdomain will still be blocked.
• Assuming the simulator behaves differently: ATS is enforced on both the iOS simulator and physical devices. The error appears in both environments.
• Not checking for mixed content in WKWebView: Even if your initial page loads over HTTPS, embedded resources loaded over HTTP will be blocked. Ensure all assets (images, scripts, stylesheets) also use HTTPS.
• Ignoring the equivalent Android restriction: If you are building a cross-platform app, remember that Android 9 and later also block cleartext HTTP by default. You need to configure both platforms.

Summary

• App Transport Security blocks all cleartext HTTP connections in iOS 9+ by default to protect user data in transit.
• Set NSAllowsArbitraryLoads to true in Info.plist for quick development unblocking, but never ship it to production.
• Use NSExceptionDomains to allow HTTP only for specific domains that genuinely cannot support HTTPS.
• Apple's App Store review requires justification for ATS exceptions; the preferred solution is to add HTTPS to your servers.
• Android has an equivalent mechanism via Network Security Configuration, with cleartext blocked by default starting in API 28.