Apps distributed via the App Store require Apple’s approval. That’s the way it’s been since the App Store launched. In the US, the App Store’s the only way developers can really distribute apps.
You may not agree with Apple’s approach (the EU doesn’t and required allowing alternate app stores there), but you can at least explain it. Apple wants to verify that apps aren’t malware, that they do what they say, and that they adhere to Apple’s overall standards for what’s allowed. (Apple even sometimes catches nefarious apps, but of course, the review process is imperfect and rogue actors slip through.)
What makes almost no sense whatsoever, however, is Apple’s insistence on approving TestFlight builds. (TestFlight is Apple’s officially sanctioned way for developers to get unreleased versions of apps in front of beta testers, who can send feedback and crash reports.)
No reasonable developer would want to release apps to the App Store untested. Beta tester feedback is a core part of the development process to help flush out bugs, compatibility issues, confusing interfaces, etc. You rely on real-world feedback from real-world users who opt in to test your apps.
TestFlight apps are capped, reasonably enough, in a few distinct ways. You can have a maximum of 10,000 external TestFlight beta testers. Apps you build and release via TestFlight expire after 90 days.
And yet, even with those limitations in place, Apple insists on reviewing TestFlight apps before external testers can start using and testing them. This sucks.
It slows the process down considerably. When you increment the version number of your app — which you must do following every official release — the next beta iteration of your app must go back into the TestFlight approval queue. And said queue is painfully slow and getting slower, per endless developer reports on Mastodon, and my own lived experience.
If you release a version of your app that goes live in the App Store, and neither you nor your beta testers noted a bug that’s affecting real-world users, now you have a real-world problem. You scurry to code a fix, but ideally you wouldn’t just unleash it upon the App Store; you don’t want to release a second consecutive flawed update. That means instead waiting, and waiting, and waiting for the Apple TestFlight approval review queue to get to you.
I don’t know what Apple screens TestFlight builds for; as far as I know, they’ve never said publicly. I’ve also never heard of a developer having a TestFlight build rejected.
UPDATE: I’ve heard from a developer who dealt with several TestFlight rejections. “We don’t think your app should use that entitlement, so you can’t use it. Remove it and resubmit.” For what it’s worth, my entitlement rejections have all come at the App Store review phase, not the TestFlight phase.
It’s unclear to me what the hell Apple’s actually doing on this front. It seems bonkers that developers with a certain number of approved apps (or prior approved betas, or regular updates) can’t simply be whitelisted for future TestFlight releases.
Apple’s insistence on explicitly slowing down development cycles doesn’t help developers or their customers. It’s time for a better process. I’d even settle for one of Apple’s garish warnings that EU users get, that you’re installing something untrusted or unvetted. Beta testers could handle that.
But I’ve had a couple significant new LexShell features ready to go for a couple days, and I’m still waiting on TestFlight. Developers and customers alike deserve better.
[Updated at 2:37pm on September 3 to note a developer dealing with TestFlight rejections.]