ATS still ships enabled by default for all iOS apps, and developers must disable it when they are coding their apps, in case they need to talk to HTTP domains or some error-prone HTTPS websites that may default back to HTTP -- and trigger an ATS ban.
In its report, Wandera says that only 27% of the 30,000 apps it scanned are currently using ATS to enforce encrypted communications and block plaintext HTTP connections.
Around 5.3% use ATS, but they disabled it granularly, for certain domains.
Ad frameworks recommend disabling ATS
According to Wandera, the reason why three years later the ATS security feature has seen little adoption appears to be that ad frameworks/networks often recommend in their documentation that iOS developers disable ATS inside apps, to prevent iOS from blocking communications to ad servers in case of an error.
"Ad network operators are in a competitive space and want to streamline the process for developers to make their apps compatible," Wandera said. "By removing 'roadblocks' such as encryption requirements, they make it easier for more developers to incorporate their ad networks into their applications."
This seems to be the primary reasons why ATS is often disabled. For example, Wandera said that ATS is more widely used inside paid apps, which do not rely on advertising revenue, and where app developers have no reason to disable ATS to safeguard their profits.
Some paid apps still disable ATS, but this appears to be related to content management, with some app makers wanting to make sure remotely-hosted content on HTTP or error-prone HTTPS gets loaded without glitches.
Furthermore, these percentages should be taken with a grain of salt, as ATS being disabled doesn't necessarily mean that those iOS apps are not using HTTPS.
"It just means that system safeguards are disabled and hence there is much more room for [HTTPS] error," the Wandera team said.