It's probably justified, because with the speed of which computing power increases, older encryption quickly become weak, what once was considered "too hard to break" becomes feasible.
Apple do have the habit of educating their users / developers, which also tend to be lazy and neglect such issues, so this is probably a good thing, especially when solutions are easy to implement.
There are some cases in which ATS has to be disabled, but most times it can be fixed without disabling ATS -
A) Backend doesn't support HTTPS connections
Configure your backend to support HTTPS connections, there's no reason to use non secure connections.
B) Backend is using a self signed certificate
Either sign it with a know Certificate Authority, or pin your self signed root certificate. You can use
AFNetworking to pin your CER file.
C) Backend doesn't support TLS v1.2 with Forward Secrecy
Update your server to support those ciphers. Search the web on how to do this on your web server.
D) App communicates with a 3rd party that doesn't full comply to ATS
Add an exception for that specific website. Check if the endpoint supports HTTPS scheme,
TLS v1.2 protocols and
Forward Secrecy cipher suites, if any of those are missing - and a specific exempt.
If they don't specify which API endpoint they use, you can use a sniffer like Wireshark, or other
winpcap based program to find out who the 3rd party library is communicating with.
Here's a great guide on setting exemptions -
E) App opens an unknown external URL
SFSafariViewController to open unknown external websites. It encapsulates all protection measurements required to protect your user.
F) App has an inline web browser
This is a bummer, since
SFSafariViewController uses a modal view and you probably need to use
UIWebView, which follow the ATS rules of your app. There's no way to allow HTTP connections on a specific
If you want to support opening HTTP website from an inline UIWebView browser, you'll have to enable