To protect users, Apple decided to encourage developers to avoid using the unencrypted http:/// protocol. This means that when users request (directly or indirectly) resources from an API endpoint Apple believes that their data should be protected through the encryption of https://
But what if your application uses a resource snugly nestled on a http:// server?
This is all about Transport Layer Security (TLS) — unsure about this?
Read on to find out the changes you need to make to get your App to run…
Difficulty: Beginner | Easy | Normal | Challenging
API: Application programming interface. A set of accessible tools for building software applications
plist: file is a settings file, also known as a “properties file,” used by macOS and iOS applications
Project Navigator: Part of the Xcode interface that allows you to perform file operations
Even those with clipboards and glasses at Apple who enforce the rules have given developers a way to overrule the idea that the access to resources must be encrypted.
Apple’s preferred solution
Make changes to the server. Of course, you need to have access to the server to do this or convince the people who run the backend to do so. Good luck.
Make a temporary exception for ALL Arbitrary Loads
You can temporarily let your application access any particular resource through http:// by simply making a temporary exception in the info.plist file.
Simply find the Plist file in the project navigator
Now when running code that downloads from a URL there will no longer be any problems.
However, when you submit to the App Store you would need to justify why you have this setting.
Allow Arbitrary Loads in Web Content
You can perform a similar exception as the one above, but restricting the exception to content delivered through the web.
Specifically exclude domains
You can also prevent specific domains being included in the App Transport Security:
This is obviously better than allowing arbitrary loads for all possible addresses. Therefore this is preferable.
Getting through the review process
If you allow arbitrary loads as described above, you need to justify your reasons for doing so.
Why might you need to access insecure resources? A couple of great reasons are listed here:
- Your server is managed by someone else, and that server does not support secure connections
- The data that is being loaded is simply media content, so doesn't need to be encrypted
Delivering your justification
When you deliver your App for review there is a space in App Store Connect (in the Prepare for Submission tab) where notes can be added:
Write a nice little note, and the App Review Team are sure to be on your side!
Apple are discouraging developers from using insecure methods to download to user’s devices for a reason — this is a much better experience for the user and enables you to protect that same user.
That’s what they call — a win win situation
The Twitter contact:
Any questions? You can get in touch with me here