How to Get Your App Approved on Google Play and the App Store in 2026

Why Fora Soft wrote this playbook

App review failures almost never come from bad code — they come from avoidable paperwork: a missing privacy manifest, a mismatched description, a demo account that doesn’t log in, an outdated target API. The teams that ship fastest aren’t the best engineers, they’re the best-prepared submitters. This guide is the preparation checklist we use on every mobile release at Fora Soft — tuned to the 2026 reality of EU DMA, privacy manifests, Android 15 target API and Apple’s new AI-consent rules.

Since 2005 we’ve shipped 99+ mobile and video products across iOS and Android, with a 98% five-star review rate on Upwork. Classrooms like BrainCert, telemedicine apps like CirrusMED, and consumer video apps have all been through the store-review wringer — and the recommendations below come from actual submissions, not from the marketing page of a review-checker SaaS.

Market context: why store approval is strategic, not clerical

There are roughly 1.8 million apps on the App Store and 2.5–3 million on Google Play in 2026. Apple processes more than 200,000 submissions per week globally and rejected about 1.93 million of 7.77 million submissions last year. Google blocked 255,000+ apps for excessive data access and terminated 80,000+ developer accounts in 2025 alone. The takeaway: the stores are not rubber-stamping anymore. A careless submission today is likely to stall, which is why the few weeks spent getting the compliance layer right usually pay for themselves in launch velocity — and in the cost of one last-minute scramble.

The 2026 approval bar: what has actually changed

Store policies are a moving target. Four 2025–2026 shifts determine what you must ship today that you could get away with a year ago.

1. Privacy manifests are mandatory on iOS. Since May 2024, every iOS app must include a PrivacyInfo.xcprivacy file declaring data types collected, third-party SDKs and their purposes, and approved reasons for each “required-reason” API. Enforcement in 2025–2026 is strict; Xcode will block the upload, and manual reviewers will still reject if the manifest contradicts in-app behavior.

2. AI consent disclosures are live. As of November 2025, if your app sends personal data to third-party AI providers (OpenAI, Anthropic, Gemini, ElevenLabs, etc.), you must show a consent screen naming the provider and the data shared. Missing this = instant rejection under 5.1.1.

3. Google Play target API 35 is the 2025–2026 floor. Since August 31, 2025, new apps and updates must target Android 15 (API 35). Android 16 (API 36) becomes the floor by August 31, 2026. Miss the deadline and you can’t push updates until you catch up.

4. DMA compliance reshaped EU distribution. Since June 26, 2025, EU apps can distribute through Web Distribution or alternative marketplaces, offer external payments, and cannot be blocked from linking to non-App-Store offers. From January 1, 2026 the per-install Core Technology Fee is retired in favor of a unified Core Technology Commission — which affects pricing design, not review, but changes what your legal review should check.

Top rejection reasons — ranked by 2026 frequency

Roughly 25% of App Store submissions are rejected on first pass; Google Play’s overt rejection rate is lower but enforcement via Data Safety and permissions is aggressive. The ranking below aggregates Apple’s transparency data, Google’s 2025 safety report (255K+ apps blocked, 80K+ developer accounts banned) and our own intake of roughly 60 mobile submissions over the last 12 months.

Apple App Review Guidelines — the rules that actually bite

You don’t need to memorize all 300+ paragraphs of the guidelines — you need to know the specific rules Apple cites in real rejection letters. Here’s the short list, with what “compliant” looks like in 2026.

Rule 2.1 — App Completeness

No placeholders, no TODO text, no broken links, no dead paywalls. Every button reachable from the first screen must do something real. Your backend must be up during review — if reviewers submit between 08:00–18:00 Pacific and your staging crashes, you’ll get 2.1.

Rule 2.3 — Accurate Metadata

Screenshots must match the app you submit, not a future version. No competitor names in title, subtitle or description. No ASO keyword stuffing. If your app is in beta, say so on the screenshots — if not, remove any “Beta” banner before submission.

Rule 3.1 — Payments

Digital goods consumed inside the app must use In-App Purchase — unless you qualify as a reader app, or you’re in the EU and have opted into the External Purchase Link entitlement under DMA. Linking to external payment flows without the entitlement is an instant 3.1.1.

Rule 4.8 — Sign in with Apple

If you offer any third-party login (Google, Facebook, X, LinkedIn, etc.), you must also offer Sign in with Apple — visually equivalent, not buried in a submenu. Proprietary enterprise SSO or government e-ID flows are exempt.

Rule 5.1 — Privacy

A working privacy policy URL. A populated App Privacy card in App Store Connect that matches what the app actually collects. A privacy manifest declaring every third-party SDK. An App Tracking Transparency prompt using the approved wording if you use IDFA. An AI consent screen if you share personal data with external models. Miss any one of these and you’re out.

Google Play compliance: the three gates you must pass

1. Target API level 35 (Android 15) minimum. Set targetSdkVersion = 35 in your Gradle configuration, audit every deprecated API you call, and test on a physical Android 15 device. Extensions exist but are limited — plan as if they don’t.

2. Data Safety form matches real behavior. Declare every data type you or any SDK collects, how it’s used, and who you share it with. Google’s April 2025 clarification is strict: if your SDK (ad network, analytics) uses data for its own purposes, that counts as sharing. Audit your build.gradle dependencies line by line.

3. Permissions are justified or removed. SMS and Call Log permissions are effectively restricted to default SMS/Phone apps. Accessibility Service is blocked for any “autonomous action” use case — automation frameworks, clickbots, etc. Foreground services need a declared foregroundServiceType. Strip anything you don’t absolutely need.

The Google Play closed-testing trap for new personal accounts

If your developer account was created after November 13, 2023 as a personal account, you must run a closed test with a minimum of 12 verified testers for at least 14 days before you’re eligible to push to production. This is still in force in 2026 and catches most solo founders off guard.

Workarounds: set up an organization account (exempt), or start the closed-testing clock the same day you open the developer account, not when the app is finished. Recruit testers from communities (Reddit, Slack groups, Discord) rather than friends-and-family — Google does look at the tester list quality in ambiguous cases.

A 25-line pre-submission checklist we run before every release

This is literally the checklist we paste into our release ticket on each mobile project. Work through it in order — the sequence matters, because later items assume earlier ones are done.

Build & quality

1. Crash-free sessions above 99.5% on Firebase Crashlytics or Sentry across the last 500 sessions. 2. Cold-start under 2 seconds on the slowest supported device. 3. No placeholder text in any screen reachable from a cold install. 4. Every CTA in onboarding leads somewhere real, including the terminal “success” screen.

Privacy & compliance

5. Privacy policy URL live on HTTPS, matches in-app data collection. 6. App Privacy card in App Store Connect populated and matches the policy. 7. PrivacyInfo.xcprivacy checked in and validated by Xcode. 8. Every third-party SDK (Firebase, Adjust, Mixpanel, Crashlytics, etc.) listed with its purposes. 9. ATT prompt wording uses Apple’s recommended phrasing, not your own. 10. AI consent screen displayed before the first LLM call, naming the provider.

Metadata

11. Screenshots match the build you’re uploading. 12. No competitor names in title, subtitle, keywords or description. 13. Age rating questionnaire completed and re-rated against 2025’s new 13+/16+/18+ categories. 14. Support URL & email working and monitored. 15. Localization done for every region you’ve selected in pricing & availability.

Testing & reviewer support

16. Demo account credentials in the App Review Information field, verified working 5 minutes before submission. 17. Review notes explain any non-obvious flow (e.g., “To see the AI tutor, tap Library → Tutor → Start Session”). 18. TestFlight build (iOS) or Closed Testing build (Android) covered at least 7 days with real users. 19. Backend staging matches production, running on the same infrastructure during review.

Platform-specifics

20. Sign in with Apple implemented if third-party login exists. 21. Target API 35+ on Android, with deprecation audit done. 22. Data Safety form populated for every SDK, matches reality. 23. Foreground service types declared in the Android manifest. 24. Kids category rules (parental gate, no behavioral ads, no third-party analytics) enforced if applicable. 25. Export compliance answered honestly in App Store Connect.

Apple vs Google — a cheat sheet for your release manager

The two stores feel superficially similar and are actually quite different operationally. Keep this mental model:

Apple is human-reviewed, rule-cited, and metadata-strict. Expect a named reviewer, a specific guideline number in every rejection, and a high bar for screenshots, descriptions, and demo accounts. Most of the friction is pre-publish.

Google is automation-first, policy-systemic, and post-publish enforced. You can often ship in hours, but the Play Integrity API, Data Safety audits and policy bots are watching. Bans come days or weeks after approval, without warning. Keep logs.

Privacy manifests, ATT and the AI-consent screen

Privacy is the #2 rejection cause and the fastest-growing category. Three pieces of the puzzle trip up most teams.

The privacy manifest. PrivacyInfo.xcprivacy is a plist that lives in your app target and, separately, inside every third-party SDK that ships with your app. You need to declare every data type collected, the purposes (analytics, app functionality, product personalization, advertising), every tracking domain, and for every “required-reason” API (UserDefaults, file timestamps, disk space, system boot time, keyboard access) the approved reason code. Xcode will validate on archive and App Store Connect will validate on upload.

App Tracking Transparency. If you touch IDFA or share identifiers with ad networks, you must call ATTrackingManager.requestTrackingAuthorization with the system prompt. The purpose string in Info.plist must follow Apple’s guidance — no incentivized phrasing, no “unlock premium by enabling tracking,” no scary warnings. Average opt-in is around 25–30% globally; plan your attribution stack assuming 70% of users decline.

The AI consent screen (new in late 2025). Before the first call to any third-party LLM or speech API, show a clear consent screen that (a) names the provider, (b) lists what personal data is shared, and (c) offers a meaningful decline path. A single “By continuing you accept our terms” line is no longer enough.

The end-to-end submission workflow: week by week

A realistic timeline for a first submission, assuming the app itself is already feature-complete:

Week 0  Dev accounts opened, DUNS requested, target API upgraded
Week 1  Privacy policy drafted, ATT copy finalized, SDK audit done
Week 2  Privacy manifest completed, AI-consent screen shipped
Week 3  TestFlight + Closed Testing (Play) opened to real testers
Week 4  Screenshots, icons, localized metadata, age rating filled
Week 5  Demo account + review notes prepared, final QA pass
Week 6  Submission: App Store + Play production track
Week 6+ Response within 24-72h; fix & resubmit in 3-5 days if needed

How to handle a rejection letter — and how not to

Every rejection is a specific guideline citation plus a short note from the reviewer. Read it twice, reproduce the issue yourself, and then write a reply that (a) acknowledges the guideline, (b) describes what you changed, (c) gives the reviewer the exact path to verify, and (d) ends with a direct question if anything is still ambiguous. Skip the defensive tone.

Good reply: “Guideline 2.1: We’ve fixed the crash on cold start. It was a race condition on the analytics SDK. Build 1.2.4 now gates analytics behind a dispatch on the main queue. To reproduce: launch, tap ‘Library’ → ‘Lesson 1.’ Demo account test@forasoft.com / password123.”

Bad reply: “We don’t think this applies to our app. Please review again.” — You’ll get the same rejection with less patience.

If you’ve genuinely been rejected under the wrong rule, you have one formal appeal per submission via the App Review Resolution Center. Reserve it for cases where you can demonstrate the reviewer misapplied policy, not for trying to convince them your design is beautiful.

Cost and timeline: what approval actually costs

The raw fees are trivial — Apple Developer Program is $99/year, Google Play is $25 one-time. The real cost is engineering time spent on compliance and iteration.

A realistic budget for a first submission by a small team: about 2–3 weeks of engineering time spread across compliance work (privacy manifest, Data Safety form, AI consent, target-API upgrade) and one or two rejection cycles. Using an agent-engineering workflow we typically compress that to 6–10 days end-to-end, because the checklist above is mostly automatable.

For an organization account, add 5–30 business days to request a DUNS number for free from Dun & Bradstreet; Apple won’t enroll your company without it. For a brand-new Google Play personal account, add the 14-day closed-testing window before you’re eligible for production.

A decision framework — pick your release path in five questions

Q1. Individual or organization account? If the app is tied to a legal entity, contracts, or paid distribution, go organization and budget the DUNS lead time. Individual accounts are faster to open but complicate everything downstream (reviews show your personal name, IAP payouts go to an individual bank, compliance exposure is yours personally).

Q2. What’s your EU exposure? Shipping to EU users post-DMA means deciding whether to offer external payments (lower fees but more engineering), web distribution or alt stores (larger surface area, notarization required), or stick with the App Store and IAP. Each choice changes your submission artifacts.

Q3. Do you integrate any third-party AI? If yes, the AI consent screen is mandatory on iOS. Build it on day one; don’t bolt it on a week before submission.

Q4. Is your app in a sensitive category? Kids, health, finance, gambling, and dating each carry extra review scrutiny, documentation requirements and regional restrictions. Plan review times 2× and involve your legal team before submission, not after.

Q5. Do you need to ship on a specific day? If yes, submit 14 days in advance, have an expedited-review plan documented, and keep a fallback marketing plan if review slips. Don’t pin launch announcements to unreliable approval timelines — it’s the single most common source of launch-day embarrassment.

Five pitfalls we still see every quarter

1. Hardcoded staging URLs in production builds. Reviewer hits a 500 because you forgot to swap the API endpoint. Run a pre-flight script that asserts every URL in the release build points to prod.

2. Privacy policy that doesn’t match the manifest. The App Privacy card, the PrivacyInfo.xcprivacy, and the hosted privacy policy must all agree. Any mismatch is a 5.1.1. Generate them from one source of truth — a single YAML file we keep in the repo and transform into all three.

3. SDKs that silently upgrade and add tracking. A minor version bump of an ad or analytics SDK can quietly add new data collection. Lock SDK versions, and audit the privacy manifest on every release — not just once.

4. Accessibility service abuse on Android. Using Android’s Accessibility Service to automate clicks, reminders or app-control flows will get you banned, not just rejected. If you need this kind of power, use MediaProjection, Notification Listener, or ContentProvider patterns instead.

5. Under-populated review notes. “Video conferencing app” is not review notes. Write a reviewer-facing one-paragraph tour: what the app does, how to log in, which flow demonstrates the core value, and any unusual permission prompts. Saves you one round-trip 80% of the time.

KPIs: how to measure a healthy release pipeline

Quality KPIs. First-pass approval rate (target >70% after the third release), crash-free session rate at submission (>99.5%), and anomaly count in the privacy manifest diff between releases (target: zero unexplained changes).

Business KPIs. Calendar days from code-freeze to live (target <10 days), release cadence per app per quarter (target 6–12), and rejection cost as hours of engineering time per release (target <8 hours).

Reliability KPIs. Rate of post-approval hotfixes (target <1 per release), pop-up rate of “Why does this app need that permission?” user reviews (target <0.5% of all reviews), and expedited-review approval rate when requested (target >50%).

When not to submit yet

It’s tempting to “just try” when you’re close, but a premature rejection costs more than the week it buys you. Wait another cycle if any of these are true: crash-free sessions are still below 99%, you haven’t run 7+ days of TestFlight or Closed Testing with real users, your privacy policy and privacy manifest don’t match line by line, your backend doesn’t yet have a staging “review mode” with deterministic seed data, or your team doesn’t have a clear owner of reviewer communication. Fix these first — a clean submission is cheaper than three dirty ones.

FAQ

What to read next

Ready to ship a clean first submission?

Store approval is a preparation game. The teams that ship fastest aren’t the most experienced — they’re the ones who treated privacy manifests, demo accounts and reviewer notes as first-class release artifacts rather than last-week panic items. The checklist above is the one we follow for every mobile release at Fora Soft; work through it in order and your first-pass approval rate should clear 70% within three cycles.

If you’re preparing a new app, upgrading an existing one to the 2026 rules, or just stuck in a rejection loop, we’re happy to run an audit and hand you a fix plan. Two hours on our side usually saves weeks on yours.