Downsides to using NSAllowsArbitraryLoads to disable App Transport Security?

Updating our desktop app to use Xojo 2019 r1 has had an unexpected side effect: images that use an http:// URL no longer load in an HTML viewer on macOS.

Replicating the problem has been a bit tricky, because there seems to be some cacheing going on. As far as I can tell, if a Mac has ever successfully loaded that URL into an HTML viewer then the image will display correctly (e.g. by using a version of Xojo prior to the switch to using the macOS 10.14 SDK, or by using the Info.plist workaround that I’m about to describe). Otherwise, we see the missing image icon.

I’m guessing that this is happening because changing the macOS SDK means that App Transport Security is now being applied to my app.

We can disable App Transport Security by including the following key in our Info.plist file, and that fixes the problem:

<key>NSAppTransportSecurity</key> <dict> <!-- Include to allow all connections; avoid if possible --> <key>NSAllowsArbitraryLoads</key> <true/> </dict>

Are there any downsides to doing this? Does it trigger any security warnings, require further entitlements, etc?

If you are releasing the app on the Mac App Store :
-Your app might be rejected
-Your app will be for 17+ audience only
-Your app will be reviewed for much longer
-Your might never be featured because of this

If your app only loads http:// images from a handful of urls, you can allow arbitrary loads from those urls only.
If your app only loads a few images per day from http:// (but you don’t know from where) you can use an online server that would work as a proxy and download the image then serves it as https://

If you aren’t releasing on the Mac App Store, allowing arbitrary loads isn’t an issue.

Thanks, Jeremie: we’re not on the Mac App store so I’m glad to hear that allowing arbitrary loads shouldn’t be an issue.