Apple publishes its App Store Review Guidelines. Google publishes its Developer Policy Center. Both are publicly available. Both are long.
Reading them in full before your first submission is a reasonable idea. Most founders don't. And even the ones who do often miss the rules that cause actual rejections — not because the rules are hidden, but because they're applied in ways that aren't obvious from reading the documentation.
Here's what the published guidelines don't fully capture — the practical, applied version that determines whether your app actually goes live.
Rule 1: The Reviewer Is a First-Time User
This one sounds obvious but its implications aren't.
App Store reviewers approach every app as if they've never heard of it, never seen a demo, and have no context about what it does or why it exists. They install it, open it, and try to figure out what to do.
If your first screen is confusing, your onboarding is incomplete, or your main action isn't discoverable, the reviewer doesn't ask for help. They don't email you to understand the use case. They reject the app for poor user experience or minimum functionality.
The invisible rule: your app has to be instantly legible to someone with zero context. Every screen needs a clear next action. The core value has to be reachable within the first two to three minutes.
Rule 2: The Listing Is Reviewed Before the Build
The review process doesn't start when the reviewer opens your app. It starts when they see your listing.
If your screenshots show a different UI than what's in the build, the reviewer opens the build already suspicious. If your description promises a feature they can't find, they're looking for other problems. If your privacy policy URL produces an error, the submission doesn't even get to the app.
The invisible rule: your listing is your first impression, and a bad first impression shapes everything that follows. Reviewers are humans with limited time. Doubt introduced at the listing level rarely resolves favorably once the app is open.
Rule 3: Policy Violations Are Cumulative
A single minor issue might not cause a rejection. A combination of minor issues almost always does.
An app with a slightly vague privacy policy, a permission that's technically justifiable but not clearly explained, and screenshots that are six weeks old might clear review individually. Together, they add up to a rejection — usually framed as one of the three issues, but actually caused by the combined impression of an app that wasn't carefully prepared.
The invisible rule: reviewers are making a judgment call about whether this app is ready for the public. Small gaps in preparation compound into a "not yet" even when no single issue is disqualifying on its own.
Rule 4: What You Don't Declare Can Be Used Against You
Both platforms actively check whether your app does things you haven't declared.
If your app requests location access but your privacy policy says you don't collect location data, that's a contradiction. If your analytics SDK collects device identifiers but your Data Safety form says no device IDs are collected, that's a contradiction. Reviewers and automated systems are trained to find these gaps.
The invisible rule: your declarations create a standard you're held to. Omitting data collection that's actually happening isn't safer than declaring it — it's worse, because it looks deliberate.
| What You Declare | What Actually Happens | Review Result |
|---|---|---|
| No data collected | Analytics SDK collects usage events | Policy violation — contradiction |
| No location access | App requests location permission | Metadata mismatch — rejection |
| Supports all devices | App crashes on older iOS versions | Build stability rejection |
| Simple, free utility | App has hidden subscription paywall | Guideline 3.1 violation — IAP rules |
| No user-generated content | Users can post comments or reviews | Content moderation policy flag |
Rule 5: Updates Are Reviewed the Same Way as New Submissions
Many founders assume that once an app is approved, updates get lighter scrutiny. They don't.
Every update that changes app functionality, permissions, privacy declarations, or business model goes through the same review process as the original submission. An update that adds a new SDK without updating the Data Safety form gets the same kind of rejection the original submission would have gotten.
The practical implication: your publishing process doesn't end at the first approval. It applies to every release. Teams that treat updates as lower-stakes than initial submissions tend to accumulate policy gaps that surface as rejections at inconvenient times.
Rule 6: The Review Is Contextual, Not Just Mechanical
Apple's review includes a human judgment element that no checklist fully captures. A reviewer who finds your app confusing, incomplete, or lacking clear value can reject it under guidelines that are deliberately broad — "apps that don't offer enough value" or "apps that duplicate functionality available in the operating system."
This is rare but real. The apps that trigger it are usually thin wrappers around a website, apps that do one very simple thing without clear differentiation, or apps that seem like prototypes rather than finished products.
The invisible rule: the review is ultimately a human judgment about whether this app deserves to be in the store. Technical compliance is necessary but not sufficient — the app also needs to feel like a complete, intentional product.
How to Navigate Rules You Can't Read
The practical answer is to get your app in front of someone who knows how reviewers think before it goes in front of a reviewer.
Froxi AI's publishing guide is built around these applied rules, not just the documented ones. The intake process surfaces the areas most likely to trigger rejection for your specific app type. The compliance walkthrough ensures your declarations match your actual behavior. The pre-submission checklist covers the things that look fine on paper but cause rejections in practice.
The goal is to arrive at the review queue with the same confidence a developer who has published a hundred apps would have — not the uncertainty of someone discovering the rules one rejection at a time.
