Two million rejections a year is a design constraint, not a statisticTwo million rejections a year is a design constraint, not a statistic

Apple's App Store figures for 2025 put submissions above 9.1 million and rejections above two million, including over 1.2 million new apps and close to 800,000 updates.

Read as a proportion rather than a headline, that is roughly one submission in four sent back. Most teams plan as though the number is zero.

What a rejection actually costs

Not the fix. The fix is usually small - a metadata field, a missing privacy disclosure, a demo account that expired.

The cost is the calendar. A rejection on a Thursday before a launch week means a resubmission that lands in a queue, and the marketing, the client's internal announcement and occasionally a contractual date are all downstream of something now outside your control.

There is a second cost that is harder to see. A team that has been rejected close to a date starts making decisions under pressure: cutting the feature that might have caused it, resubmitting without properly understanding the reason, or arguing the case when accepting it would be faster. None of those are good decisions, and all of them are produced by the schedule rather than the rejection.

The rejections we have actually had

In our experience the common causes are unglamorous and almost entirely preventable:

• A demo account that stopped working between submission and review.
• A feature reachable only with data the reviewer has no way to create.
• Privacy disclosures that did not match what the app actually collected, usually because an SDK changed.
• Screenshots showing a version of the interface that no longer existed.
• Sign in with Apple missing where a third-party login was offered.

Every one of those is a checklist item, which is why we have a checklist. It is read aloud before submission rather than ticked from memory.

Notice what they have in common: not one is a defect in the app. They are mismatches between the submission and reality, and they accumulate silently between releases while nobody is looking at them.

Review the app the way a reviewer will

The single most effective preparation is to stop testing as yourself. A reviewer arrives with no account, no data, no context, and no knowledge of what the app is meant to do.

• Install on a device that has never had the app, from the build you are actually submitting.
• Sign in with the demo credentials exactly as written in the notes, by typing them.
• Reach every feature you listed, without creating data by hand in a database.
• Do it with no network for a moment, because reviewers sit on imperfect connections too.

Most of our near misses have been caught in that half hour. The usual discovery is a feature that only works because the developer's account has records in it that a new account does not, which reads to a reviewer as a broken or missing feature rather than an empty one.

Write the review notes as though explaining to a stranger

The notes field is the cheapest risk reduction available and is usually left empty or filled with a single line.

What helps is the specific: which credentials to use, where a feature lives if it is not obvious, why a permission is requested, and what to do if something requires hardware the reviewer does not have. If an app needs a physical device to demonstrate properly, a short screen recording attached to the submission has resolved more of our queries than any amount of argument afterwards.

Build the buffer into the plan, not your weekend

The planning change that helps most is treating review as a stage with a duration rather than a formality with none. We submit with working days to spare, and we tell clients the launch date is the date we can announce, not the date we submit.

Submit early enough that a rejection is an inconvenience rather than an incident.

The teams that get burned are not the ones who wrote bad apps. They are the ones who assumed a step involving human judgement would take zero time and always say yes.

If it happens anyway

Rejections are routine and are not a judgement on the work. The response that resolves them fastest is also the least satisfying.

• Read the cited guideline itself, not only the message. The message is a summary; the guideline is the standard being applied.
• Fix what was named and resubmit. Fixing three additional things you were not asked about introduces new variables into a decision you want made quickly.
• Use the resolution centre for genuine ambiguity, and answer the question asked. It is a conversation with a person, and it works about as well as conversations with people usually do.
• Appeal only when you believe the guideline was misapplied, and say why in a paragraph. It is a real process, it is occasionally the right move, and it is slower than complying.

Tell the client the same day, before they hear about a missed date. A rejection explained on Thursday is a process working normally. The same rejection discovered on Monday is a crisis, and the difference is entirely in who said what and when.