Launch

The Complete Mobile App Launch Compliance Checklist (Apple + Google, 2026)

A 16-item compliance checklist every mobile app developer needs before submitting to the App Store or Google Play in 2026, with a detailed guide linked for every item.

13 min read

The Complete Mobile App Launch Compliance Checklist (Apple + Google, 2026)

Shipping a mobile app to the App Store or Google Play in 2026 is not a single question — it is roughly sixteen. Between Apple's Privacy Nutrition Label, Google's Data Safety form, account deletion URLs, privacy manifests, and the support pages both stores expect, a first-time submitter can spend a week discovering requirements they have never heard of and still miss one. Most of the resulting rejections are not bugs in the binary — they are missing URLs, mismatched disclosures, or a checklist field left blank in a console. This guide walks the full set so you can ship a first build that passes review on the first try and keeps passing as the stores tighten their rules.

TL;DR

  • Both stores require a publicly accessible privacy policy URL plus a structured disclosure form completed inside App Store Connect or Play Console. The two must match each other and match your binary.
  • Apple adds two trap items first-timers miss: the App Privacy Nutrition Label and the PrivacyInfo.xcprivacy manifest for Required Reason APIs (mandatory since Spring 2024).
  • Google adds two of its own: the Data Safety form and a public account-deletion URL for any app that lets users create accounts.
  • The rest is metadata — screenshots, content rating, test account credentials, export compliance — plus four optional-but-valuable items most apps eventually need anyway.
  • You can assemble this from five separate tools or from a single dashboard like AppLander, which covers nine of the sixteen items from one login.

Table of Contents

What the Stores Actually Require

Apple's submission documentation is unambiguous: "Enter all necessary information about your app's privacy practices, including the practices of third-party partners whose code you integrate into your app, in App Store Connect. These details inform the Privacy Nutrition Label that appears on your product page and are required in order to submit new apps and app updates to the App Store." Section 1.5 of the App Review Guidelines separately requires a working support URL, and since 2024 Apple requires a PrivacyInfo.xcprivacy manifest for any app touching a Required Reason API.

Google's Developer Program Policies are equally explicit: every app needs a privacy policy, a completed Data Safety section, a content rating, and — for apps that allow account creation — both an in-app deletion flow and a public web URL for deletion. As of 2026 the extensions on the deletion requirement are long expired.

Both stores reserve the right to reject a submission if any of these items is missing, inaccurate, or inconsistent with how the binary behaves.

Why Launch Compliance Is Harder Than It Looks

Three things make the checklist trickier than the bullet list suggests.

First, nothing is self-contained. The privacy policy has to match the Nutrition Label, which has to match the Data Safety form, which has to match the SDKs actually linked in the binary. One inconsistency and a reviewer bounces the whole submission.

Second, items live in places you don't own. Privacy manifests live inside Xcode, screenshots in App Store Connect, content ratings in both consoles, account deletion URLs on the public web, changelogs in both stores and on your marketing site. There is no single dashboard that ships the 2026 version of this list end-to-end, so most teams juggle five or six tools.

Third, the rules keep moving. Apple added Privacy Manifests in 2024, then started enforcing in-app account deletion to match Google. A checklist that was complete in 2023 is missing items in 2026, and the 2026 version will be missing items by 2027.

The rest of this guide treats every item as its own small puzzle, with a link to a dedicated guide where one exists.

The 16-Item Launch Checklist

1. Privacy policy URL (mandatory, both stores)

A publicly reachable HTTPS URL to a policy describing everything your app collects, why, with whom it is shared, and how users delete it. Both stores cross-check the wording against your binary and your disclosure forms. See the privacy policy generators for mobile apps guide.

2. Terms of service URL (recommended, sometimes required)

Apple does not strictly require terms for every app, but subscriptions, user-generated content, or marketplace features do — and missing terms is a common soft rejection on paid apps. Pick one from the terms of service generators for mobile apps guide.

3. App Store Connect Support URL (mandatory, Apple)

Section 1.5 of the App Review Guidelines requires a support URL specific to the app, publicly reachable, with a real way to contact you. Marketing homepages and social profiles are the fastest rejections. Full walkthrough: the App Store support URL guide.

4. App Store Connect Marketing URL (optional, Apple)

Optional, but leaving it blank removes the "Developer Website" link from your product page. Pointing it at a dead page is a guaranteed rejection under Guideline 2.1. See the App Store marketing URL guide.

5. App Privacy details in App Store Connect (mandatory, Apple)

Apple's Privacy Nutrition Label is built from a structured questionnaire inside App Store Connect that asks what data each SDK collects, whether it is linked to the user, and which data-use purposes apply. Answers must match your privacy policy word-for-word — reviewers cross-check. See the privacy policy generators guide.

6. Apple Privacy Manifests — PrivacyInfo.xcprivacy (mandatory since 2024)

Since Spring 2024, apps using any Required Reason API (UserDefaults, file timestamps, disk queries, active keyboards, system boot time) must include a PrivacyInfo.xcprivacy file in Xcode declaring the reason codes. SDKs on Apple's "commonly used" list must ship their own manifests. See the Apple privacy manifests guide.

7. Google Play Data Safety form (mandatory, Google)

Play Console's equivalent of Apple's Nutrition Label — a structured questionnaire about collection, sharing, retention, security, and deletion. Required for every app, answers must match your privacy policy, and Google sometimes scans binaries to cross-check. See the Google Play Data Safety form guide.

8. Google Play account deletion URL (mandatory for apps with accounts, Google)

Google requires both an in-app deletion flow and a public web URL where users can initiate deletion without signing in or installing the app. A missing or broken URL blocks all updates. See the Google Play account deletion URL guide.

9. app-ads.txt (required if monetized via ad networks)

If your app shows ads through AdMob, AppLovin, Unity Ads, ironSource, or any IAB Tech Lab–compliant mediator, you need an app-ads.txt file at the root of the developer website in your store listing. Unverified inventory is down-ranked or blocked. See the app-ads.txt for mobile apps guide.

10. Public status page (optional but valuable)

A page at status.yourapp.com turns "this app is broken" reviews into "backend incident, fix in progress" reviews. 30-minute setup, quarterly touch. See the mobile app status page guide.

11. Changelog / release notes page (required for every release)

Both stores require release notes on every version. A public changelog on your app's domain gives you one source of truth to paste from. See how to write an app changelog.

12. Multi-language listings (optional but often worth it)

Apple and Google both let you localize name, subtitle, description, keywords, and screenshots. A few well-chosen locales can double discovery in markets you did not originally target. See the multi-language app store listings guide.

13. Screenshots and preview videos (mandatory, both stores)

Both stores require screenshots in specific sizes and aspect ratios, and Apple enforces Guideline 2.3 — screenshots that do not show the actual app in use are a top metadata rejection. Preview videos are optional but materially improve conversion. No web tool builds these for you.

14. Content rating / age rating (mandatory, both stores)

Apple uses its own age-rating questionnaire; Google Play uses the International Age Rating Coalition (IARC) questionnaire. Both are short but must be answered truthfully. "Incorrect rating" is a frequent rejection under Guideline 2.3 and a common Google policy strike.

15. Test account credentials (required if the app has login)

If any part of your app sits behind a login wall, Apple will reject the submission unless you provide a working username and password in the App Review Information section. Use a real test account with full feature access — not a demo that short-circuits the flow.

16. Export compliance (required for apps using encryption)

Any app using non-exempt encryption must answer the export compliance questions in App Store Connect, and potentially file an Annual Self Classification Report with the US Bureau of Industry and Security. Most apps qualify for the exemption (HTTPS plus standard OS crypto), but you still have to answer the questions to claim it.

Three Approaches to Shipping Compliance

Most teams pick one of three paths for the nine public web items on the list above.

Do-It-Yourself

Write your own privacy policy, build a support page in Notion or Carrd, host an account deletion form on your marketing site, ship a status page on your own infrastructure.

Pros.

  • Full control over design, copy, and integration.
  • Zero ongoing subscription cost beyond existing hosting.
  • Deep integration with your stack — verification and deletion hooks call your real backend directly.

Cons.

  • Weeks of engineering work across privacy law research, UX, email verification, and multi-language support.
  • Ongoing upkeep every time a law changes or a new SDK is added.

Best for. Teams with a legal reviewer on call and engineering cycles to spare.

Multi-Vendor Stack

Pick a privacy policy generator, a support page builder, a status page tool, a form host, and a landing page builder — five separate subscriptions, each doing one thing well.

Pros.

  • Each tool is genuinely best-in-class for its specific job.
  • Easy to swap one tool out if a vendor raises prices.
  • Most individual tools have generous free tiers.

Cons.

  • Five logins, five billing relationships, five different URL patterns your users have to learn.
  • Visual identity drifts across tools — a Notion support page next to a Carrd landing page rarely feels like one product.

Best for. Teams already using one or two of these tools who just need to fill in the gaps.

Unified Platform

Use one dashboard that ships the public web items as a coherent per-app bundle.

Pros.

  • Single login for the nine items that live on the public web.
  • SDK disclosures update in one place and propagate everywhere they are referenced.
  • Visual identity stays consistent across policy, terms, support, deletion, landing, status, and changelog pages.

Cons.

  • One vendor means one roadmap — if the platform stalls, you move everything.
  • Unified platforms are usually newer and less battle-tested than category leaders in each slot.

Best for. Solo developers and small teams who want to ship a clean first submission without juggling five vendor relationships.

How AppLander Covers Nine of the Sixteen

AppLander was built for the unified-platform path. From a single dashboard it ships nine of the sixteen items above:

  • Item 1 — Privacy policy URL. Per-app editor with a 100+ SDK picker, GDPR, UK GDPR, CCPA/CPRA, CalOPPA, COPPA, and PIPEDA coverage, plus version history.
  • Item 2 — Terms of service URL. Per-app terms editor with version history and matching visual identity.
  • Item 3 — Support URL. Full support center with searchable FAQ, ticket system, and per-app branding.
  • Item 4 — Marketing URL. Landing page builder that fills the Marketing URL field and doubles as a real product page.
  • Item 8 — Account deletion URL. Dedicated page at yourapp.applander.io/delete-account with verification flow and audit log.
  • Item 9 — app-ads.txt hosting. Served at the root of your AppLander domain for ad-network verification.
  • Item 10 — Status page. Public status page you update from the same dashboard.
  • Item 11 — Changelog. Public release notes page next to everything else.
  • Item 12 — Multi-language publishing. English, German, Italian, French, Arabic, Persian, Swedish, Turkish, and Chinese across all of the above.

Honest limitations. AppLander does not cover the seven items that live inside Xcode, App Store Connect, or the binary itself: the Privacy Manifest file (item 6 — Xcode), the App Privacy Nutrition Label inside App Store Connect (item 5), screenshots and previews (item 13), the content rating questionnaire (item 14), test account credentials (item 15), and export compliance (item 16). The SDK library structures the disclosure data so the Nutrition Label and Data Safety forms are easy to fill in, but it cannot fill them in for you — those consoles sit behind Apple and Google logins. AppLander is also newer than iubenda or TermsFeed; if you need a policy battle-tested in EU courts for a decade, iubenda still wins on legal depth.

If you miss any of these, you will likely hit one of the common App Store rejection reasons — that guide explains how to diagnose and fix each.

Common Launch-Day Mistakes

  • Pasting a homepage URL into every store field. Both stores expect specific pages for specific purposes.
  • Letting the Nutrition Label and Data Safety form drift. Build both from your privacy policy.
  • Forgetting PrivacyInfo.xcprivacy. Since 2024 this is the most common new iOS rejection.
  • Shipping a deletion URL behind a login wall. Reviewers check from incognito with no app installed.
  • Skipping test credentials on paid apps. Apple will not create an account to test your app.
  • Using a splash-screen image as your first screenshot. Apple rejects this under Guideline 2.3.

Frequently Asked Questions

Do I really need all sixteen items on my first submission?

You need the mandatory ones: 1, 3, 5, 6, 7, 8 (if you have accounts), 13, 14, 15 (if you have login), and 16 (if you use encryption). The recommended items (2, 4, 9, 10, 11, 12) do not block your first build, but most become effectively mandatory by your fifth or sixth release.

Which item is the most common first-submission blocker?

In 2026 it is a three-way tie between a broken support URL (item 3), a missing PrivacyInfo.xcprivacy file (item 6), and a Data Safety form that does not match the privacy policy (items 1 and 7).

If I fail review, do I have to re-upload the binary?

Not usually. Most rejections are metadata, URL, or disclosure problems — fix the field and resubmit the same build. Binary issues (crashes, missing features, manifest violations) require a new upload.

Does this list change if I ship on only one store?

Slightly. iOS-only apps can skip items 7 and 8. Android-only apps can skip items 5 and 6. Everything else applies to both stores.

What happens to my compliance assets after launch?

They become a maintenance workload. Every SDK change, new jurisdiction, or policy update can invalidate one of the nine public web items. This is why shipping them from one dashboard matters more than it looks on day one — the savings compound every release.

Conclusion

Shipping a mobile app in 2026 is a sixteen-item compliance exercise dressed up as a build-and-upload. Every missing item is a rejection risk, and every mismatch across items is its own rejection risk. The good news: nine of the sixteen live on the public web and can be shipped from one dashboard; the other seven live inside Xcode and the stores themselves and are just a question of filling in the right fields honestly.

If you want one place to handle the nine public items — with SDK disclosures that stay in sync, multi-language publishing, and a stable per-app URL — try AppLander. For everything else, follow the linked detailed guides and you will have a submission that passes review on the first try.

Sources

Ship your app faster with AppLander

The all-in-one compliance and landing-page platform for mobile app developers.

Start Free