The figures reach me through a dev.to write-up of Apple's own 2024 App Store Transparency Report, which is Apple's accounting of Apple's gate [1]. Take the one outcome number attached to the rejected pile. 295,109 rejections were fixed and approved on resubmission [3], against 1.93 million rejections total [2]. That is 15.3 percent, roughly one in seven [2]. The remaining 1,634,891 rejections have no recorded return to approval in these numbers [3]. Read that carefully before you plan around it. It does not mean 1.6 million teams gave up. It means the report tells you the rejection rate and tells you almost nothing about cycle time, and a 25 percent rejection rate [1] is a different planning input from a 25 percent one-sprint slip rate.
The denominator is also not the population you belong to. Guideline 4.3(a) bans duplicate submissions under different Bundle IDs, the textbook case being one app re-skinned per city, and 4.3(b) targets near-clones in saturated categories unless yours is meaningfully different [14]. Those submissions are inside the 7.77 million. So for the one-in-four figure to transfer to a team shipping one deliberate app, you would have to assume bulk re-skin traffic is a negligible share of submissions, and nothing in the report lets you check that. Treat 25 percent as a ceiling on your own expected rate, not an estimate of it.
What does transfer is the shape of the gates. Guideline 2.1, App Completeness, covers crashes, obvious bugs, placeholder content, broken demo accounts, and non-functional in-app purchases [7]. It is the category you can test yourself before submitting [9], and a broken demo account is among the most common and entirely self-inflicted 2.1 rejections, because App Review needs a real working account with real data behind it [8]. A stub login is the cheapest available way to spend a week. Further up the pipeline sits a machine check: since May 1, 2024, newly added third-party SDKs on Apple's commonly-used-SDK list require a privacy manifest and, often, a valid signature [11], and a build missing one for a flagged SDK is rejected before a human reviewer ever opens it [12]. That check belongs in CI next to your other build-breakers, not on a pre-submit checklist someone reads at 6pm.
Now the sourcing. Apple has not published a breakdown of rejections by specific guideline number, which is why any listicle asserting that some exact percentage of rejections trace to one guideline is unsourced [5]. What Apple's commentary alongside the report does give is an ordering of the most common drivers: performance and bugs, then legal issues, design problems, business-model payment violations, and safety risks [6]. A rank tells you where to start. It does not tell you whether first place is twice fourth place or fifty times it, so you cannot size a triage budget from it. For a percentage table to be worth acting on, Apple would have to publish guideline-level counts, and your category mix would have to resemble the store-wide mix. Neither condition currently holds, so the honest artefact is a checklist ordered by rank, with the two machine-checkable items automated and the rest read off the actual rejection text. App Review's message usually names the specific trigger; the guideline number is the category, not the diagnosis [10].
