I recently shipped my first iOS app. The App Store review process took three weeks, six rejections, and a support case. Along the way, I got a front-row seat to what I believe is a system under serious strain, and I have some theories about why.
Also, the whole story is kind of hilarious, in a sad, dysfunctional sort of way.
Here is what happened.
The App
For a bit of context, DrawTales is a children's app. You point the camera at a kid's drawing, and it generates a narrated, illustrated story. I built it for my daughter as a side project, but got enough positive feedback that I figured it might be worth releasing on the App Store. It has a free tier and an auto-renewable subscription.
I'll also be upfront: while I've had a long career in tech as both a developer and a manager, I would not have built this app without AI assistance. I understand that the review team is likely dealing with a massive influx of AI-enabled submissions, and that I am, in fact, part of "the problem." I don't envy their job. But understanding why something is broken doesn't make the experience any less frustrating.
The Review Process: What Happened
The first review (Day 1-6)
I submitted my release candidate and got Apple's friendly email: 90% of apps are reviewed within 48 hours. Six days later, it came back rejected with two issues: questions about tracking and third-party services that were already answered in the App Information section and linked privacy policy, and a claim that the app hung on the splash screen. This was accompanied by a screenshot of the onboarding flow, which they couldn't have reached if the app had actually hung.
The EULA issue (Day 7-8)
I replied with detailed answers and resubmitted. A day later: rejected again, this time for not linking to the EULA in the subscription purchase view. This one was a genuine oversight. I'd assumed selecting Apple's Standard EULA in App Store Connect was sufficient. Fair enough. I fixed it, prepared a screen recording showing the functional links, and got ready to resubmit.
The subscription trap (Day 8-9)
While preparing the resubmission, I noticed my subscription group and subscription localizations had been separately rejected with zero explanation (no notes, no comments). I made educated guesses, updated them, and clicked "Submit for Review" on the subscription pages.
I then resubmitted the app version, not realizing the subscription had been silently detached from the submission. When the subscription came back rejected ("must be attached to a build"), I revoked my app submission to re-attach it, only to discover the UI for doing so simply doesn't appear. The "In-App Purchases and Subscriptions" section on the version page was gone.
Groundhog Day (Day 9-10)
I resubmitted, hoping the subscription was still connected somehow behind the scenes. Revoking and resubmitting the version however seemed to have severed the conversation history with the reviewer. The app was rejected again for the exact same EULA issue — the one I'd already fixed. My explanation and screen recording were still right there in the review notes.
I replied again. Patiently explaining everything.
The surprise approval (Day 10)
A few hours later, in the fastest turnaround in the entire saga, Apple approved the app. There was no reply to any of my messages or questions about the subscription. In fact, the subscription was still in "Waiting for Review" limbo.
The Catch-22 (Day 10-11)
I couldn't release an app where the subscription purchase flow might not work, so I cancelled the release. I planned to bump the version and submit with the subscription properly attached. But the subscription was stuck in "Waiting for Review" and needed to be attached to a build for its first submission. I couldn't attach it because it was in review. It would never come out of review because it wasn't attached to a build...
So I filed a support case. Hours later, the subscription was actually approved independently. But I still couldn't attach it to a version, because approved subscriptions don't appear in the attachment UI. They're just... part of the app. They carry forward automatically. The Connect UI gives you zero indication of this.
EULA Groundhog Day, part two (Day 12)
I submitted a new version which was functionally identical. Screen recording attached. Detailed review notes.
Rejected. Same reason. Same boilerplate. Different reviewer, different test device, clearly nobody looking at the screen recording or the notes or the fact that the identical app was approved two days earlier.
I resisted the urge to punch my poor laptop (it's made by Apple after all) and instead replied calmly, pointing this out.
The anticlimax (Day 16)
Four days of silence. Then: into review. A few minutes later: approved. No reply to any of my messages. No acknowledgment. I'm fairly confident they didn't even open the app.
The app is now live and subscriptions work. It took three weeks to get a working, policy-compliant app through review.
How Did We Get Here?
Being both a developer and someone who's led orgs at tech companies, I can't help but reflect on the organizational dynamics that produce this kind of experience. I find it fascinating, not least because I'm certain nobody at Apple wants it to be this way. Also, Apple as a whole certainly doesn't lack resources.
Here's my take. It's speculation, obviously, but I think it's well-grounded.
Factor 1: The AI submission tsunami
Apple doesn't release official numbers, but both industry rumors and common sense suggest that App Store submissions have increased dramatically in recent months after remaining relatively stable for years. AI-assisted development has lowered the barrier to shipping an app from months of specialized work to weeks of guided effort. It's probably fair to say that the floodgates are open.
Factor 2: Scaling a human review org is hard
Meeting this increase requires scaling the review organization: hiring, training, updating processes, and improving tooling. App Review still requires (for good reasons) trained human reviewers. And with a long history of gradual, predictable growth that never demanded step-changes to established systems, a sudden multiplier is a serious organizational challenge.
Could Apple manage it? Of course. They have the resources, the expertise, and the institutional capability. But only if they treat it as a real company priority. Which brings us to the key question.
Factor 3: The incentive problem
Why would they?
For the sake of argument, let's say submissions have tripled since late 2025. Does that triple App Store revenue? Almost certainly not. Users' combined willingness to pay for apps is unlikely to be meaningfully affected by an even larger catalog. It might be argued that more niche apps serving more needs might increase sales over time, but the opposite is equally plausible: it gets harder for consumers to find quality apps amid the flood of low-effort submissions.
What we can be reasonably sure of is that Apple's costs have increased. Not just for review, but for hosting, managing, and supporting a much larger catalog. The first-order financial effect of the submission surge is more than likely negative for Apple.
What about developer sentiment? Well, Apple has demonstrated repeatedly that they can afford not to worry too much about this. It seems to me that the calculus is simple: on one side, the frustration of dealing with App Store review. On the other, the only realistic gateway to over a billion iOS users worldwide. Developers will tolerate a great deal of friction for that access. Apple knows this.
The dynamic playing out
I'm confident there are plenty of middle managers at Apple responsible for App Review who are painfully aware of these issues. They've likely been advocating loudly for more resources to scale the org. They've probably even received historically large budget increases. Just not nearly enough. My guess is that, higher up the chain, executives are strongly disincentivized to increase spend on what is ultimately seen as a cost center.
So what might the review org do to stay afloat in this situation? Well, they could for instance increase throughput targets such as reviews per hour. They might also speed-run the onboarding of the (too-few) new hires they're actually allowed to make.
And if that's what's happening, then the behavior I saw starts to make more sense. When my little app lands on the screen of an overworked, recently onboarded reviewer who is being evaluated primarily on how many reviews they complete per hour, they're not going to carefully read my review notes, watch my screen recording, and cross-reference my previous submission history. They're going to check for one of the most common first-time developer omissions (missing EULA links), see a subscription in the app, and mark it rejected. The risk of a quality spot-check catching this is far outweighed by the risk of not making the throughput quota.
Closing Thoughts
The most frustrating part of this wasn't strict enforcement. It was inconsistency, lack of continuity, and a process that repeatedly behaved as if prior context did not exist. For a platform as important as iOS, that should concern more people than just annoyed indie developers. App Review is not some minor back-office function. It is core infrastructure for the iOS ecosystem. If it becomes inconsistent, opaque, and too overloaded to absorb context from one review cycle to the next, it degrades trust in the platform itself.
To be clear, I don't think the problem is individual reviewers. The people doing this work are almost certainly trying to do a difficult job under significant pressure. The problem is the system they're operating in and the nebulous organizational incentives that shape it.
If you're an iOS developer going through something similar, you're not alone. It does eventually end, but it probably shouldn't require this much endurance to ship a small, working, policy-compliant app.
And if you happen to work at Apple and read this, I'd genuinely be curious to hear your perspective. From the outside, this looks a lot less like a company enforcing high standards, and a lot more like one struggling to keep an essential process from buckling under its own load.