Every team that ships iOS apps has a rejection story. Usually it goes like this: the build is finished, the launch date is set, the app goes to review, and two days later a message arrives in App Store Connect citing a guideline number nobody on the team had read.
The fix is rarely a few lines of code. More often it is a change to scope, payments or data handling, which is exactly the kind of change that is expensive at the end of a project and cheap at the beginning.
We have put more than 70 apps through App Review. The lesson that stuck is simple: treat the App Review Guidelines as a requirements document, and read them before the design is final. Here are the questions we now answer at the start of every iOS project.
Guideline numbers below are the ones in use as we write this. Apple renumbers and rewords sections now and then, so read the current text before relying on any of it.
1. What does this app do that a website can't?
Guideline 4.2, minimum functionality, is where many first apps stumble. An app that mostly wraps a website in a web view, or offers very little beyond it, is likely to be rejected.
So the first scoping question is about native value. Notifications, offline use, the camera, location, widgets, or simply a much faster native interface for a task people repeat every day. If the honest answer is "nothing", the right product may be a good mobile website rather than an app.
2. Is this one app, or ten apps that look the same?
Guideline 4.3 is the spam rule. It catches publishers whose apps differ only in name, colour or a few strings. This matters for businesses with branches, franchises or several brands, and for studios that reuse code across apps.
Reusing code is fine. Shipping apps that a reviewer can't tell apart is not. Two questions help:
- Would one app with a location or brand selector serve users better than one app per branch?
- If the apps share a template, does each one have its own purpose, content and experience?
3. How will this app make money?
Guideline 3.1.1 covers in-app purchase. Roughly: if what the user pays for is unlocked and used inside the app, Apple expects it to go through its own payment system; if it is a physical product or something delivered in the real world, such as a taxi ride or a cleaning visit, it doesn't. Some regions now allow external payment links under specific programs, and these rules vary by country, so they need checking at the time of the project.
This question changes the product, not just the checkout screen. It affects pricing (store fees), the account model, how restore purchases work, and the paywall itself, which has to state what the user pays, how often, and that it renews. Deciding it at the start avoids a redesign of the paywall a week before launch.
4. What data do we collect, and why?
Guideline 5.1 covers privacy and data collection. The questions to settle early:
- Which permissions does the app really need? Every permission prompt needs a specific, honest purpose string.
- What happens when a user refuses a permission? The rest of the app should keep working.
- If sign-up happens in the app, can account deletion happen there too?
- Is there a privacy policy, and do the App Store privacy details match what the app actually does, including third-party SDKs for analytics and ads?
For apps with AI features, add one more: what is sent to which provider, and is the user told? Keeping provider keys and prompts on your own server, rather than in the app, also makes it easier to answer this honestly and to change providers later.
5. Can a reviewer actually reach every feature?
Guideline 2.1, app completeness, is one of the most common rejection reasons. A reviewer who hits a crash, an endless spinner or a login wall will reject the build.
Plan for the reviewer as a user from the start:
- Test login credentials for a demo account that already has data in it, so the reviewer doesn't land on empty screens.
- A backend that stays up during review, not a staging server that sleeps at night.
- A short note, or a demo video, for features that need special hardware, a location or a second device.
- A TestFlight round on an older iPhone and the newest one, not only the simulator.
6. Do the screenshots and description match the build?
Metadata is reviewed too. Screenshots that show features the build doesn't have, or a description that promises more than the app delivers, can lead to rejection under the accurate-metadata rules.
The cheapest fix is to produce the listing from the build the reviewer will see, after feature freeze, and to drop any screenshot that shows something still on the roadmap.
7. Who answers when review comes back?
Even well-prepared apps sometimes get questions. Decide who reads the Resolution Center messages and replies, and how quickly. A short, specific reply, sometimes with a screen recording, settles more cases than a resubmission does. Problems that are only in the store listing don't need a new binary. And if the team believes the decision is wrong, Apple has a formal appeal route.
Closing thought
App Review is not a final exam you cram for. Most of its rules describe product decisions: why the app exists, how it earns money, what data it touches and whether a stranger can use it on the first try. Answer those at the start and submission day becomes routine.
We use these questions at the beginning of every iOS and Android project at BernSoftware, alongside the store metadata and screenshots that we write with the first build.
Planning a project like this?
Plan it in 10 steps