This week, I ran into some unexpected problems with TestFlight while releasing an app to my testers for — you guessed it — testing! We had setup TestFlight for internal testing to do a first round of QA testing, and had started pushing builds. That part is not complicated, and there is lots of documentation on the topic. However, there isn’t much documentation when it comes to troubleshooting App Store build upload issues, of which I have experienced many.
This learning experience focused on ensuring that testers were notified of new builds through the expected channels — push notifications and emails — without the developer interceding.
Typically, when you upload a build to TestFlight where testing is already underway (i.e. you’ve uploaded builds for this version and started internal testing), your testers will receive a push notification (assuming they’ve allowed it) and an email with a notice that a new build is available and the new build number. This eliminates the need for the developer to do anything explicitly to let her testers know fixes are ready. (Side note: it’s still a best practice to send out a “release notes” style notice, whether through email or some other channel.) However, these typically automatic notifications were not going out after the first build or 2 went out to our testers.
After the 3rd failure, I got suspicious.
I started researching a bit, and StackOverflow and blog posts didn’t net the results I was hoping. I even landed on the Apple forums for answers, of which I got none. However, I did find some clues that pointed me in the right direction. After every build, we were having to go into TestFlight, look at the builds, and then resolve an Export Compliance issue.
Wait a minute! Maybe that’s a clue.
I then look up the export compliance issue we were having to resolve. A quick google got me an answer almost immediately. According to this SO post, the ITSAppUsesNonExemptEncryption key is the culprit. By adding this key to the app’s Info.plist and setting it to “No”, perhaps I can eliminate the extra step after an upload AND get my notifications back in order.
Sure enough, adding that key to the plist did the trick. Both push notifications and emails started going out after as soon as a build finished processing and was ready for testing.
That led me down another rabbit hole. What does that key do and am I being honest when I answer that with a “No”?
That turned out to be a bit of a loaded question.
However, there was plenty to muddle through on the internet. One StackOverflow question had some particularly interesting tidbits that led me to believe that perhaps, because I use HTTPS endpoints, I am using encryption, and thus I need to respond “Yes.” But after further reading, things clarified a bit (as I had hoped). Namely, the Department of Commerce has this stuff documented, but it’s not very easily consumed.
Turns out, the US government wants to know when you’re using a non-standard encryption, and there are regulations around how you, as a developer, report on your encryption practices. HTTPS traffic did originally fall under this somehow, but there are now exceptions for standard handling such as HTTPS traffic. Thus, we can honestly answer “No” to that question.
Apple engineers also cover this topic, including the bits about handling export compliance, in the “What’s New in iTunes Connect” from WWDC 2015 (Session 302).
Hopefully this helps someone get to a resolution a little quicker, as well as aggregating a bit of the knowledge. If nothing else, perhaps I can assist my future self.