Rejection is not a quality signal. It is a process signal. An app can be well built, well designed and genuinely useful and still bounce three times, because review is not testing whether your app is good — it is testing whether your app complies. Those are different questions with different answers.
The useful thing about that is how predictable it makes the outcome. In practice a small set of issues accounts for the overwhelming majority of rejections, and nearly all of them are decided long before anyone presses submit. Below are the ones worth designing against, with the phase of a project where each is cheapest to fix.
1. Crashes and incomplete builds (Guideline 2.1)
The single most common rejection is also the most avoidable: the reviewer opened the app and it crashed, or hit a screen that was obviously unfinished.
Three things cause this more than anything else. The reviewer is on hardware or an OS version you did not test. The reviewer has no working demo account. Or the backend the build points at is a staging environment that was down that morning.
Fix it in hardening. Test on a real device matrix, not just the simulator. Supply a demo account in App Review notes with credentials that do not expire, and check them the day you submit. Point the submitted build at production.
2. No way to delete an account (Guideline 5.1.1(v))
If your app lets people create an account, it must let them delete it — from inside the app, not by emailing support and waiting. The deletion must remove the account, not merely deactivate it, and if you keep any data afterwards for legal reasons you have to say so.
Google Play requires the same thing, and goes further: you also need a web-accessible deletion URL that works without installing the app, declared in your Play Console data safety section.
Fix it in design. This is a screen, a confirmation, an API endpoint and a decision about data retention. It is trivial in week three and genuinely annoying in week fourteen.
3. Selling digital things outside In-App Purchase (Guideline 3.1.1)
Digital content, subscriptions, features, currency — if it is consumed inside the app, Apple expects it to be sold through In-App Purchase, at Apple’s commission. Physical goods and services consumed in the real world go through your own payment processor and must not use IAP.
The grey area that catches people is the “service” that is really software. A one-off consulting session is a real-world service. A template pack you download in the app is digital content.
Fix it in discovery. This is a business-model decision with a 15–30% margin attached, not an implementation detail. Decide it before you price anything.
4. Paywalls that do not disclose enough (Guideline 3.1.2)
A subscription purchase screen has to show the subscription title, its length, the price, and what that price buys per period, and it must link to your terms of service and privacy policy. Auto-renewal has to be stated plainly. “Start free trial” as the only visible text with the terms hidden behind a scroll is a reliable rejection.
Fix it in design. Treat the paywall as a compliance surface, not just a conversion surface. The two goals conflict less than designers fear.
5. Vague permission purpose strings (Guideline 5.1.1)
Every permission prompt on iOS is backed by a purpose string in your Info.plist. “This app needs camera access” explains nothing and gets flagged. “Cognify uses your camera to scan the barcode on a delivery label” explains the specific use and passes.
The related trap: requesting a permission you do not use yet because you might later. Reviewers check whether the feature behind the permission actually exists.
Fix it in build. Write the purpose string when you write the permission request, in the same commit. It takes a minute and prevents a week.
6. Third-party login without an equivalent private option (Guideline 4.8)
If your app offers social login from a service that gathers personal data — Google, Facebook and similar — you must also offer a login option that limits data collection to name and email, lets the user keep their email private, and does not track them for advertising without consent. Sign in with Apple satisfies this. So do some others, but Sign in with Apple is the path of least resistance.
Fix it in design. Adding an auth provider after the user model is settled means migrating accounts. Decide the full set of providers up front.
7. User-generated content without moderation tooling (Guideline 1.2)
Any app where users can post things visible to other users needs four capabilities: a filter for objectionable material, a way to report content, a way to block abusive users, and a stated commitment to act on reports — Apple’s expectation is within 24 hours.
Teams routinely scope the posting feature and forget that moderation is part of it. It is not a phase-two feature; it is a condition of shipping phase one.
Fix it in discovery. If v1 has UGC, moderation is in v1. If that is too expensive, the honest move is to cut UGC from v1.
8. Metadata that does not match the app (Guideline 2.3)
Screenshots showing features that are not in the build. A description promising an integration that is coming next quarter. A category that flatters rather than describes. Keywords stuffed with competitor names. All of these are rejections, and the last one can escalate beyond a rejection.
Fix it at launch. Produce screenshots from the actual submitted build. It is slower than reusing the design mockups and it is the only version that passes.
9. Tracking without the ATT prompt (Guideline 5.1.2)
If your app or any SDK inside it accesses the advertising identifier or links user data across apps and websites owned by other companies, you must request permission through App Tracking Transparency, and your privacy nutrition label must say so.
The recurring cause is a third-party SDK doing this without the team realising. Attribution, ads and some analytics SDKs all can.
Fix it in hardening. Audit what every SDK in your dependency list actually collects before you fill in the privacy label. Getting the label wrong is worse than a rejection — it is a misrepresentation you have signed.
The pattern
Look at where the fixes land. One belongs to discovery, four to design, two to build, two to hardening and one to launch. Exactly zero of them are fixed at submission, which is the point where most teams first read the guidelines.
Reading both guideline sets during design, and running a deliberate audit against them before submitting, converts almost all of this from a multi-week rejection loop into a checklist. It is the cheapest insurance in a mobile project.
We run that audit as a defined phase on every build, and we write the reviewer response ourselves if something is still queried. If you want the checklist we use, ask us for it — we are happy to hand it over.