Apple’s App Store Review Problem Is Becoming a TestFlight Product Problem

Platform update

Apple’s App review pipeline is under a new kind of load. According to the WWDC figure cited by 9to5Mac, more than 1,000 apps are now being submitted every hour, a pace that makes sense in a world where a developer, designer, product manager, or non-developer with an AI coding tool can assemble a working iPhone app in days or hours. The issue is not that AI-assisted apps exist. The issue is that the App Store is still being asked to handle too many different jobs at once: production software distribution, consumer trust, payment policy, discovery, fraud filtering, beta testing, and small-project sharing.

That matters more on iOS than it does on most platforms because, outside the EU and a few other special cases, the App Store remains the main route to normal iPhone distribution. Apple does have TestFlight, and TestFlight already supports public links, crash reports, screenshot feedback, tester criteria, internal groups, and external beta review. Apple’s current documentation says developers can invite up to 100 internal testers and up to 10,000 external testers, with external builds going through a lighter review path before distribution. That makes TestFlight the obvious place to absorb small tools, experiments, prototypes, and community apps that are useful but not ready for the main store.

The problem is that TestFlight is still structured like a testing utility, not a distribution layer. A developer can share a public link, but there is no native discovery surface in the TestFlight app that works like a credible shelf for experimental software. There is no official Apple-run replacement for the old Airport model, where users could browse TestFlight apps and indie developers could reach interested testers without pushing every idea through the App Store’s consumer storefront. In 2026, that gap is more visible because AI has lowered the cost of creating the first version of an app, while Apple’s review and distribution architecture still assumes that most submissions are intentional production releases.

Apple has also tightened the technical baseline for submissions. Its upcoming requirements page says that since April 28, 2026, apps uploaded to App Store Connect must be built with Xcode 26 or later using an SDK for iOS 26, iPadOS 26, tvOS 26, visionOS 26, or watchOS 26. That is the right kind of platform hygiene. It keeps new submissions aligned with current SDK behavior, privacy declarations, entitlement rules, and App Store Connect validation. It does not, by itself, answer the product question raised by the submission flood: where should a weekend utility, internal companion app, local community tool, or AI-generated experiment live before it proves it belongs in the production store?

Developer impact

For iOS developers, a higher App Review bar changes the economics of experimentation. If a tiny app needs production-quality metadata, privacy nutrition labels, support URLs, polished onboarding, complete review notes, age ratings, and careful handling of every third-party SDK before anyone can discover it, the fastest path becomes either over-investment or abandonment. That is especially awkward for indie developers and small teams that use SwiftUI, App Intents, widgets, CloudKit, or StoreKit experiments to test whether an idea has an audience before turning it into a durable product.

The better distinction is not AI-made versus human-made. The better distinction is testing intent versus production intent. A small app that stores a local checklist, helps a club coordinate events, wraps a personal workflow, or experiments with an App Intents shortcut may be perfectly legitimate software. It may also be a poor fit for App Store discovery if it has no long-term support plan, no broad audience, and no reason to compete beside mature consumer apps. Apple’s App Review Guidelines already tell developers that the App Store is not always the best place for apps meant only for family and friends. The missing piece is a modern Apple-operated channel between private sharing and full public listing.

Android developers already think about this split differently because Google Play has more visible release tracks. Google’s Play Console testing documentation separates internal, closed, and open testing, with shareable links, email lists, Google Groups, country availability, pre-launch reports, and staged rollout mechanics. Google Play still has policy review and production quality requirements, and it is not a frictionless free-for-all. But the release model gives Android teams a more explicit path from internal build to closed test to open test to production.

That difference affects cross-platform teams using Flutter, React Native, Kotlin Multiplatform, .NET MAUI, Unity, Capacitor, or a shared backend with native clients. On Android, a team can target a testing track, validate device coverage, and then move toward production when retention and crash data justify the work. On iOS, TestFlight can cover the testing mechanics, but discovery and audience building are mostly external. You post a link on social media, put it in a newsletter, send email invites, or build your own directory. That is manageable for a funded team. It is weaker for the kind of small experimental app that Apple historically benefits from having in its ecosystem.

There is also a technical compliance gap between the platforms. Google Play currently requires new apps and updates to target Android 15, API level 35, or higher, with exceptions for Wear OS, Android Automotive OS, and Android TV apps, according to the target API level requirement. Android teams moving through 2026 also need to watch Android 16 behavior changes, runtime permissions, background execution limits, foreground service policy, Play Integrity usage, and large-screen quality expectations. iOS teams, meanwhile, need to stay on Xcode 26, current Apple SDKs, privacy manifests, required reason APIs, notarization rules for alternative distribution where applicable, and App Review’s content and commerce policies.

This is where vibe-coded apps can create real maintenance risk. AI-generated code can compile while still mishandling lifecycle states, accessibility, localization, offline behavior, platform privacy rules, dependency licenses, or secure storage. On iOS, that might show up as a SwiftUI view that looks fine on one iPhone but breaks on iPad, a background task that does not survive system scheduling, or a third-party package that triggers required reason API declarations. On Android, it might be a target SDK bump that changes notification permission behavior, media access behavior, foreground service restrictions, or edge-to-edge rendering. Cross-platform frameworks reduce UI duplication, but they do not remove store compliance work.

Apple’s EU alternative distribution changes complicate the picture without solving it globally. Apple’s EU developer support page describes alternative app marketplaces, Web Distribution, and Notarization for iOS and iPadOS apps. Web Distribution is available to EU users on devices running at least iOS 17.5 or iPadOS 18, while broader marketplace support is tied to EU DMA rules and system versions such as iOS 17.4 and later. That creates more options for some developers, but it is not a general answer for a US developer shipping a small TestFlight-style tool to a global audience.

Migration

Apple’s most pragmatic move would be to turn TestFlight into a first-class pre-production channel without making it a second App Store. A Discover tab in TestFlight could list beta apps that have passed external TestFlight review, meet stricter metadata requirements, declare supported device classes and OS versions, and opt into clearer expiration rules. The surface should be intentionally different from the App Store: no paid ranking games, no paid app sales, no subscription merchandising, no charts optimized for consumer conversion. It should be built around testing signals, such as active build date, supported platforms, feedback responsiveness, crash rate bands, accessibility checklist status, and whether the developer intends to graduate the app to the App Store.

The 10,000 external tester cap is also due for a more flexible model. Apple does not need to remove the limit for every app. It could allow developers to request larger TestFlight cohorts after meeting objective thresholds: low crash rates, complete privacy answers, no unresolved review issues, recent SDK usage, clear feedback channels, and a stated testing plan. For teams maintaining both iOS and Android apps, that would map more naturally to Android open testing. The iOS build could remain clearly marked as beta while still supporting a meaningful public validation phase before production review.

Apple could also separate review gates by distribution intent. A TestFlight discovery review should verify safety, basic functionality, privacy declarations, accurate metadata, and obvious fraud concerns. A production App Store review should continue to handle the full consumer contract: long-term quality, commerce rules, content policy, privacy enforcement, subscriptions, family features, kids category rules, and broader platform behavior. That distinction would give reviewers better context, and it would give developers a clearer migration path instead of forcing every app-shaped idea to pretend it is already a finished product.

For developers, the migration plan should start before Apple changes anything. Treat AI-assisted code as a prototype accelerator, not a release process. Keep separate checklists for iOS and Android, because the shared business logic is rarely the risky part. For iOS, verify the app under Xcode 26, test against iOS 26 and iPadOS 26 SDK behavior, review privacy manifests and required reason APIs, test VoiceOver and Dynamic Type, check iPad layouts if the app claims iPad support, and make sure App Review notes include demo credentials or a fully working demo mode. Use App Store Connect metadata as a product quality checklist, even when the first destination is TestFlight.

For Android, set targetSdkVersion to at least API 35 for Google Play submission, then test the behavior changes rather than treating the version bump as a manifest edit. Run pre-launch reports where available, check notification permission flows, validate background work with WorkManager or foreground services only where appropriate, and test on foldables, tablets, and low-memory devices if your listing supports them. If you use Flutter or React Native, verify plugin compatibility with the current Android Gradle Plugin, Kotlin version, iOS deployment target, CocoaPods or Swift Package Manager dependencies, and native permission declarations on both sides.

Cross-platform teams should also resist the temptation to ship identical release states to both stores. Google Play testing tracks and TestFlight do not communicate the same maturity level to users. A Play open test can be closer to public availability, while a TestFlight public link still feels like a beta invite with expiration and tester limits. Align your internal versioning, crash reporting, analytics events, and feature flags across both platforms, but let each store channel keep its own approval and support expectations.

The broader pattern is clear: mobile platforms need a better middle layer for software that is real but not yet production-grade. Apple has most of the pieces already: TestFlight installs, App Store Connect metadata, external beta review, crash reporting, tester criteria, public links, SDK enforcement, and platform trust. What it lacks is the product decision to make discovery and scaled beta distribution official. If app creation keeps getting cheaper, the winning store model will not be the one that rejects more experiments at the front door. It will be the one that routes experiments into the right channel, learns from tester behavior, and promotes the apps that prove they can be maintained.