App Store Review Guidelines: Your 2026 Approval Guide
Navigate Apple & Google Play's App Store Review Guidelines 2026. Get approved fast with our guide: common rejections & pre-submission checklist.
You're probably close to submission right now. The build works on your phone, TestFlight looks fine, screenshots are ready, and you're wondering whether app store review guidelines are just a final admin task or the thing that's about to slow your launch down.
In practice, review is where a lot of otherwise solid apps get stuck. Not because the core product is bad, but because the submission doesn't explain the app well enough, the monetization flow isn't obvious, the reviewer can't get past the login wall, or the metadata promises something the binary doesn't reflect. That gap is widest on apps with gated onboarding, AI output, remote config, subscriptions, and cross-platform stacks like React Native or Expo.
The good news is that review is usually predictable if you treat it like another production environment. The rules matter, but the submission details matter just as much. A compliant app can still get rejected if the reviewer can't verify it. A more complex app can still get approved cleanly if you make the review path obvious.
Table of Contents
- The Review Process Demystified
- Apple App Store Key Guideline Pillars
- Navigating Google Play Store Policies
- Top Reasons for Rejection and How to Fix Them
- The Pre-Submission Checklist Every Developer Needs
- Crafting the Perfect Submission Package
- From Compliance Hurdle to Launch Asset
The Review Process Demystified
Teams often treat review like a black box. That's the wrong mental model. Review is a trust gate for the store, the user, and everyone else shipping there.
Apple made its guideline enforcement universal for both new and existing apps after its 2019 guideline update. That same update also notes that Apple organizes review into five sections and reports that 90% of submissions are reviewed in less than 24 hours. Fast doesn't mean shallow. It means the system is mature, scaled, and designed to make a decision quickly when your submission is clear.
What review is actually doing
Review isn't checking whether your app idea is good. It's checking whether the app is safe to distribute, complete enough to evaluate, and honest about what it does.
That changes how you should prepare. If your onboarding depends on a live backend, the backend has to be available. If features become available only after a specific role or account state, the reviewer needs access to that state. If your app behaves differently based on AI output, remote flags, or account history, you need to explain those conditions up front.
Practical rule: Reviewers can only approve what they can reach, reproduce, and understand.
The workflow you should design for
A clean submission usually follows a simple sequence:
- Upload the binary and complete metadata. Titles, screenshots, descriptions, URLs, privacy details, and pricing context must align with the actual build.
- Pass automated checks. Platforms look for obvious problems like crashes, missing information, and certain policy violations.
- Survive human review. Unclear flows fail at this stage. Login walls, hidden features, unfinished purchases, and unexplained permissions create friction fast.
- Respond clearly if needed. If you get a message, answer the exact question asked, then remove any remaining ambiguity.
Apple's process is more human-centered in practice. Google often feels more policy-system-driven at the start, then escalates to human review when something is flagged. That's why the same app can clear one store and stall on the other for different reasons.
A useful way to think about submission is this:
| Stage | What reviewers need | What developers often miss |
|---|---|---|
| Submission | Complete package | Missing notes, bad demo credentials |
| Access | Full feature visibility | Dead backend, expired OTP flow |
| Verification | Honest representation | Screenshots that oversell features |
| Decision | Low ambiguity | Conditional logic not explained |
If you build for the reviewer's path, not just the user's path, store review becomes much less random.
Apple App Store Key Guideline Pillars
A common Apple rejection goes like this. The app works on a developer device, the core feature is finished, and QA signed off. Then review stalls because the tester hits a login wall, cannot trigger the AI output without paid access, or lands in a React Native screen that depends on production data your notes never explained.
Apple's five pillars. Safety, Performance, Business, Design, and Legal. In practice, they are less about theory and more about reviewer access. Can the reviewer reach the feature, understand the risk, verify the purchase path, and confirm that the app matches the listing?
How reviewers apply the five pillars
Safety covers user harm, privacy, and sensitive functionality. If the app touches camera, microphone, location, health-related data, user-generated content, or AI output, give the reviewer a direct explanation of why that access exists and how abuse is handled. For AI features, state what the model does, what inputs it accepts, and what guardrails exist if responses could drift into risky territory.
Performance means the app feels finished under review conditions. Apple will treat broken states as product quality problems even when the root cause is environment setup. Under such conditions, complex stacks frequently fail. Expo builds pointed at the wrong API base URL, feature flags that disable the reviewer path, stale demo tokens, and login flows that require a real SMS code all create an app that looks incomplete.
Business is usually where monetized apps create avoidable doubt. Review needs to see what is free, what is paid, and what becomes available after purchase. If subscriptions gate the main value, show the paywall early, label pricing clearly, and explain any unusual purchase logic in the notes. If the app supports account-based entitlements outside the app, describe exactly what the reviewer will and will not be able to buy on iOS.
The other two pillars are easier to miss because teams treat them as legal or visual cleanup. They affect approval more often than that.
- Design checks whether the app behaves like a real iOS product with coherent flows, readable copy, stable navigation, and enough native feel that it does not look like a thin wrapper around a website. React Native is fine. Webview-heavy shells with weak state handling and broken back behavior are not.
- Legal checks rights, regulated content, and market-specific obligations. If you stream licensed media, surface financial information, collect health-adjacent data, or let users upload content, be ready to state what rights you hold and what controls are in place.
- Cross-pillar issues are common in gated products. A hidden premium feature can turn into a Business problem, a Performance problem, and a metadata problem at the same time if review cannot access it and the listing does not explain the restriction.
The practical rule is simple. Remove every point where the reviewer has to infer intent.
For apps with complex flows, submission details matter almost as much as the binary. Provide demo credentials that persist for the full review window. If onboarding changes by region, role, or feature flag, say which path Apple should use. If the app needs hardware, a companion web account, approval from your ops team, or seeded content before anything useful appears, write that out in plain language. For AI apps, include a test prompt that produces a representative result. For gated B2B apps, provide a reviewer account with realistic permissions, not an empty shell that hides the product.
Teams that get approved consistently do one thing well. They map each guideline pillar to a concrete reviewer action. Safety becomes permission copy plus moderation notes. Performance becomes a stable demo environment. Business becomes visible pricing and a testable purchase path. Design becomes predictable navigation. Legal becomes documented rights and disclosures. That is how the guidelines turn from abstract policy into an approval plan.
Navigating Google Play Store Policies
Google Play aims at many of the same outcomes as Apple, but the operating style feels different. Apple often acts like a product reviewer. Google often acts like a policy and risk system first, then a reviewer when needed.
That matters because Android teams sometimes over-prepare for Apple and under-prepare for Google. They assume a functioning APK or AAB plus a decent listing is enough. It often isn't. Google cares a lot about what your app claims, what data it handles, how it monetizes, and whether risky content or user behavior is moderated.
Where Google feels different
Google Play usually feels more tolerant of varied UI patterns and broader app categories, but it can be stricter in enforcement around policy families like restricted content, deceptive behavior, permissions, and user-generated content. The burden is on you to make the app's purpose, data behavior, and promotional claims consistent.
If your app includes community posting, chat, or uploads, moderation can't be an afterthought. You need reporting paths, abuse handling, and clear controls. If your store listing promises a capability the app only partially delivers, that mismatch becomes a policy problem, not just a marketing mistake.
Policy areas that deserve extra attention
A practical Google Play review pass should focus on these areas:
- Restricted content means exactly that. If the category is sensitive, regulated, adult, risky, or easily abused, assume closer scrutiny.
- Intellectual property is operational, not theoretical. App names, icons, screenshots, and in-app content all need clean ownership or permission.
- Monetization and ads need to feel fair. Misleading prompts, disguised ads, and bait-style upgrade flows create problems quickly.
- Data safety declarations must match the actual app behavior, including SDK behavior. If the form says one thing and the binary does another, expect trouble.
A lot of Android launches also fail for a simpler reason. The testing and release plumbing isn't fully ready. Wrong track selected, incomplete tester setup, stale screenshots, or account-specific compliance steps left unfinished. Those aren't product failures. They're release management failures.
Google Play rewards operational discipline. If Apple review feels like a walkthrough with a human judge, Google often feels like clearing a policy-driven pipeline where inconsistencies get flagged from multiple angles.
Top Reasons for Rejection and How to Fix Them
Friday afternoon. The build is live in App Store Connect or Play Console, the team is ready, and review comes back with a rejection that has nothing to do with the feature itself. The app works on your devices, but the reviewer hits a dead end. No valid login. No content after sign-in. No way to trigger the AI flow without a paid account. No explanation for why a permission appears.
That is the pattern behind a large share of preventable rejections. The binary is often fine. The review path is not.
When the app works but the submission fails
Reviewers test under constraints. They do not know your onboarding shortcuts, seeded account states, feature flags, or support workarounds. If a key flow depends on any of those, you need to expose that path in the submission.
This shows up constantly in apps with login, subscriptions, AI features, or role-based access. A reviewer signs in and lands on an empty dashboard because the account has no data. An AI screen is present in the screenshots but hidden until the user verifies email, joins a workspace, and spends credits. A subscription paywall exists, but the products are not available on the review account. In React Native or Expo apps, I also see release-only failures caused by environment variables, production API keys, or native permission config that worked in development and broke in the signed build.
Fixes that usually get the app through review are operational, not theoretical:
- Access fails during review. Provide working credentials, the correct user role, and any OTP bypass or test code the reviewer needs.
- The feature is real but hard to reach. Seed sample content, enable a review mode, or explain the exact taps needed to reach the flow.
- Store listing and build do not match. Remove screenshots that show hidden, unfinished, or paid features that the current build does not clearly expose.
- Permissions look suspicious. Make the permission request appear at the moment of use, with purpose text that matches the feature the reviewer is testing.
Later in the review cycle, this walkthrough is worth watching if you want a practical developer-side view of common rejection patterns and fixes.
When the product flow is the problem
Some rejections do require code or product changes.
A common example is forced login. If users can reasonably browse some content before creating an account, the app should allow that path. Another is gated functionality that looks public in the listing but is effectively unreachable in the app. Reviewers read that as misleading, even if the feature technically exists. AI apps get hit here often. If the app summary says "generate images from text," but the first run leads to a blank state, waitlist, or purchase wall with no sample output, expect pushback.
React Native and Expo teams should pay extra attention to release behavior on physical devices. I have seen approvals delayed by issues that never appeared in local development: Sign in with Apple returning to a blank screen, camera permissions missing from the production config, deep links failing only in the signed build, or a web fallback opening where a native screen was expected. Review does not care that the dev client worked. The submitted binary is the product.
| Rejection pattern | Root cause | Fix that usually works |
|---|---|---|
| Crashes or obvious bugs | Release build differs from local testing | Test the signed production build on physical devices and fix release-only errors |
| Hidden or gated functionality | Reviewer can't discover the feature naturally | Add review notes, demo mode, or sample data that exposes the path |
| Misleading claims | Listing and app diverge | Rewrite screenshots and description to match current behavior |
| Privacy issues | Permissions feel broader than the feature requires | Reduce scope, improve purpose strings, and provide fallback paths |
Don't answer a rejection with a defense of your architecture. Answer it with a build, a note, or a reproducible path that removes doubt.
How to answer a rejection well
Short replies work best.
State what changed. State where to find it. State how to test it. If the issue depends on account state, send new credentials and name the exact state. If the reviewer missed a gated feature, describe the path in plain steps: sign in with this account, tap Workspace, open Sample Project, then start the AI tool from the top-right action.
Avoid two mistakes. Do not argue about intent, and do not reply with "fixed all issues." Review teams need a clean retest path. Give them that, and many borderline rejections turn into approvals on the next pass.
The Pre-Submission Checklist Every Developer Needs
Before you submit, run a release check as if someone unfamiliar with the app is about to audit it. Because that's exactly what happens.
The fastest way to avoid review churn is to separate your checks into two groups: universal release checks and stack-specific checks. Teams often do the first half and skip the second.
Universal checks before you submit
Every app should clear this list:
- Feature completeness. Tap every important path in the production build, not just a dev build or simulator.
- No placeholder content. Remove test copy, empty states that shouldn't be public, sample banners, and dormant tabs.
- Working links and contact info. Privacy policy, support URL, restore purchases, account deletion entry points, and legal pages should all open cleanly.
- Accurate store assets. Screenshots, subtitle, description, and previews must represent the current app, including paid versus free functionality.
- Review access. Provide demo credentials, backend availability, and any special instructions needed to reach restricted areas.
A simple internal habit helps a lot. Have one teammate who didn't build the feature perform a “reviewer pass” using only the production build and the draft store listing. If they get lost, the reviewer probably will too.
React Native and Expo checks that are easy to miss
Cross-platform stacks introduce a different class of review failures. The app may be logically correct but operationally wrong.
For React Native and Expo projects, check these before release:
- Production config. Confirm
app.json,app.config.js, environment variables, bundle identifiers, package names, and API endpoints point to production. - Build profile sanity. In EAS Build, verify the release profile, signing setup, versioning, and submission target before generating the final binary.
- Permission strings. Make sure iOS usage descriptions match what the app really does. If a native module requests access indirectly, the wording still needs to make sense to a reviewer.
- Release-only bugs. Test push notifications, deep links, Sign in with Apple, Google sign-in, subscriptions, and camera flows in the signed build.
- JavaScript leftovers. Remove debug UI, dev menus, mock data toggles, and logs that expose unfinished states.
Ship the build you tested. Test the build you ship. With React Native and Expo, that sounds obvious, but a lot of review failures come from config drift between the two.
This checklist won't guarantee approval. Nothing does. But it removes the cheap mistakes that cause the most annoying delays.
Crafting the Perfect Submission Package
A submission package is not paperwork. It is your reviewer briefing.
Teams spend weeks polishing code and then write two vague lines in the review notes. That's backwards. For complex apps, the notes, metadata, test account, and media assets are part of the approval path.
Reviewer notes are part of the product
When an app has a simple open-and-browse flow, the reviewer can infer a lot. Once the app adds account states, conditional onboarding, subscriptions, remote content, or AI features, inference breaks down.
Recent guidance around App Store review has made this more important. Review readiness for non-obvious, gated, or AI-driven flows is critical because Apple now expects detailed explanations in review notes for apps with login walls, conditional states, or dynamic AI outputs, as summarized in this 2026 App Store review guidance.
Good reviewer notes should answer five questions:
- What is the app's core purpose?
- How does the reviewer log in or bypass onboarding?
- Which features are gated, conditional, or role-based?
- Where do purchases, subscriptions, or credits appear?
- What behavior might look unusual but is expected?
What to include for login AI and gated experiences
If your app has a login wall, provide credentials that land in a fully populated account. Don't send a blank account unless the empty state itself is central to review. If MFA, OTP, or magic links are required, either provide a stable way to complete them or enable a dedicated review flow.
If your app uses AI, explain where outputs appear, what triggers generation, whether results vary, and what user data is involved in the flow. If AI changes what the reviewer sees on each run, say that directly so variability doesn't look like inconsistency or a bug.
For subscriptions or gated content, keep the explanation concrete:
- State the trigger. Example: premium analysis appears after tapping “Generate Report” on the dashboard.
- State the visibility. Example: all subscription options are shown on the paywall before checkout.
- State the reviewer path. Example: use the provided premium test account to access subscribed content without purchase friction.
A strong package also uses screenshots and preview media to reduce confusion, not increase aspiration. Show real screens. Show the actual post-login experience. If the first three screenshots are just a splash screen, brand panel, and auth form, you've wasted your best chance to orient the reviewer.
The practical goal is simple. Remove every reason for the reviewer to guess what your app does or how to verify it.
From Compliance Hurdle to Launch Asset
The teams that struggle most with app store review guidelines usually treat review as a final obstacle. The teams that move faster treat it as part of product delivery.
That shift changes a lot. Privacy copy gets written while the feature is built. Subscription disclosure gets designed into the paywall instead of patched in later. Reviewer notes become a release artifact, not an afterthought. Demo accounts, support URLs, and metadata stay production-ready because they're part of launch quality.
For complex apps, that mindset matters even more. Login states, AI behavior, dynamic content, and cross-platform builds all create room for misunderstanding. The fix isn't clever wording or hoping for a lenient reviewer. The fix is completeness, transparency, and a submission package that makes verification easy.
If you want a simple standard, use this one: can a stranger open the production build, follow the instructions you provided, and confirm the app's main value without confusion? If the answer is yes, you're usually in good shape. If the answer is no, review is doing you a favor by catching the ambiguity before users do.
Done well, compliance improves the launch. It sharpens the product story, exposes broken assumptions, and forces clarity in the flows that matter most.
If you want help getting a React Native or Expo app through both stores without babysitting every submission detail, LetsDeployIt handles the full launch package, including store copy, screenshots, reviewer notes, compliance prep, submission management, and reviewer replies. It's built for teams that want approval handled cleanly and quickly instead of learning every store edge case the hard way.