Apps on Apple App Store are technically original in the United States. Therefore, they are affected by US rules for the export of encryption technology. For a long time, I remember that Apple asked developers during app submission if the app was using encryption .
Most people just chose no for this question, if their app uses encryption, even when they only access web services or pages through HTTPS. Then I was and confirmed to me by an Apple employee on a WWDC who told me that iOS encryption is exempt from export restriction. So we continued to say no.
The reason for this concern was that you said it would mean that you had to get special permission from the US government and would have trouble submitting reports on encryption every year. All of these complications we want to avoid, especially when building programs for clients that you could hardly hope to explain why they would be required to jump through such hoops.
Fortunately, it has since become clear that if the app "Make calls only over HTTPS" there will be an exception. There are more detailed explanations for why this exception exists and I'm not a lawyer … but I think the main reason for this exception is that you can not encrypt user files with HTTPS on disk, you can not change how HTTPS works because it's Part of the OS and source code for SSL are publicly available.
So, for this particular usage case, accessing a RESTful API via HTTPS, are the right answers:
Question 1: Is your app designed to use cryptography
– Call over secure channels (i.e. ……………………… Using proprietary or non-standard encryption algorithms.
We answer YES . ] because we use SSL Standard Encryption Algorithm from iOS ] or MacOS to Call Safe Channels . 3 out of 4 when only one is enough for a confirmatory answer.
OMG OMG, we use encryption …
Question 2: Does the app fulfill any of the following: 19659003] – Qualifies for one or more exceptions given in Category 5 Part 2
– Use of encryption is restricted to encryption in the operating system (iOS or macOS)
– Only call (s) over HTTPS
– The app is available only in the United States and / or Canada
We respond to YES YES, YES, Phew! Again, only one match with one of the four examples had been sufficient. But we are except.
There are two questions, but you will only see them if you answered NO to the last question.
So Apple Purchased TestFlight
Since beta testing is also a form of international distribution – especially if you share your app with international users by email – Apple will know about the encryption status of your app in advance.
The initial process was to specify the export demand information, also by answering the above questions. But having to do it for every building or new version gets old very fast. Therefore, Apple has added the functionality for us to add this information already in Xcode.
The developer knows best if the app contains an exception encryption and ITSAppUsesNonExemptEncryption key in Info. plist lets you codify the answer once and for all.
But what's the correct bool value. True or false? The double negative in here can confuse you … I know someone who was.
Read key again: App uses non-exempt encryption … does it use an encryption that is not exempted from the export restriction?
The correct answers are FALSE. HTTPS is Except. Since we do not use anything else, we do NOT use a NOT-exempt encryption.
This is why I add the entire app's Info.plist:
Xcode has a nice role to display this:
With this setting where TestFlight builds becomes available for testing as soon as the treatment is complete. No longer my clients are bothered to think of the right answers to these encryption issues.
Many applets have caused turbulent feelings in the App Store, as people did not know how to properly handle export restrictions. It was very welcome that Apple clarified this common case of HTTPS aside from having to register and report to the US government.
It's great that Apple has this functionality to specify the status information for encryption technology in Xcode. Now we developers can label our app as harmless and no longer need to disturb our customers with such questions.
Also published on Medium.