App Store & Google Play Submission Checklist (2026)

To publish an app on both stores in 2026 you need a paid Apple Developer Program membership, a Google Play developer account, a build that meets the current SDK and target API requirements, a public privacy policy, accurate privacy disclosures, store listing assets and, for new personal Google Play accounts, a 14-day closed test. This checklist covers each item and the rejections that catch most first-time teams.

It is written from direct experience. Navelo Software has shipped four of its own apps, StreakMate, ZorbiLock, CyclePrivate and BodyLog, to both the App Store and Google Play. Store rules change several times a year, so treat the numbers here as correct at the time of writing and confirm them in App Store Connect and Play Console before you submit.

App Store vs Google Play at a glance

1. Developer accounts

Set up both accounts early, in the name of the business that will own the app. Organization verification can take one to three weeks, which is the most common cause of a launch slipping for reasons that have nothing to do with code.

• Enroll in the Apple Developer Program (annual membership). Organizations need a D-U-N-S number, a legal entity name and a website on a matching domain.
• Create a Google Play developer account (one-time registration). Choose personal or organization carefully; organization accounts need a D-U-N-S number and are exempt from the closed testing requirement.
• Register accounts to the client or company, not to a developer. Invite your agency or freelancer as team members with the minimum role they need.
• Complete tax and banking in App Store Connect (Agreements, Tax, and Banking) and Play Console payments profile before you set a price or add in-app purchases.
• Enable two-factor authentication and keep at least two admins, so a departed employee cannot lock you out.

2. Google Play closed testing for new personal accounts

If your Google Play account is a personal account created after November 13, 2023, you must run a closed test with at least 12 testers who stay opted in for 14 consecutive days before you can apply for production access. Google reduced the requirement from 20 to 12 testers in December 2024; the 14-day window has not changed.

1. 01Upload a release to a closed testing track (internal testing does not count).
2. 02Add testers by email list or Google Group and share the opt-in link.
3. 03Make sure at least 12 testers opt in, install the app and keep it installed; testers who leave early do not count.
4. 04Encourage real use and collect feedback. Google asks about your testing when you apply, and signs of genuine engagement help.
5. 05After 14 days, apply for production access in Play Console and answer the questions about your test. Approval typically takes a few days.

3. Build and technical requirements

Both stores raise their minimum SDK requirements every year, and a build that misses them is rejected at upload. Check these before your final build.

• iOS: since April 28, 2026, uploads must be built with Xcode 26 or later using the iOS 26 SDK. For cross-platform apps, that usually means upgrading the framework to a version that supports it.
• Android: from August 31, 2026, new apps and updates must target Android 16 (API level 36); existing apps must target at least Android 15 (API 35) to remain available to new users on newer devices. Google allows extension requests until November 1, 2026.
• Android App Bundle (.aab) is required for new Play apps, with Play App Signing enabled.
• Privacy manifests (iOS): include a privacy manifest and declare reasons for any "required reason" APIs; commonly used third-party SDKs must ship their own signed manifests.
• Permissions: request only what you use, and write clear purpose strings (for example, why you need the camera). Unused or unexplained permissions are a frequent rejection cause.
• Export compliance (iOS): answer the encryption question. Apps that use only standard encryption provided by the operating system typically qualify for an exemption, but read Apple's guidance if you implement your own cryptography.
• Crash-free on current devices: test on the latest iOS and Android versions and at least one older, low-memory Android phone.

4. Privacy: nutrition labels, Data safety and your privacy policy

Both stores require you to disclose what data your app and every SDK inside it collect, and the disclosure must match the app's actual behavior. Mismatches are one of the most common reasons for rejection or later removal.

• Publish a privacy policy at a public URL (not a PDF behind a login) and link it in both store listings and inside the app.
• Inventory every SDK: analytics, crash reporting, ads, attribution, payments, push. Each one may collect data you must declare.
• Complete Apple's App Privacy details in App Store Connect: data types, whether each is linked to the user, and whether it is used for tracking.
• Complete Google Play's Data safety form: data collected and shared, purposes, encryption in transit, and whether users can request deletion.
• Ask for tracking permission through App Tracking Transparency on iOS if you track users across other companies' apps or websites.
• Check local law: GDPR applies to users in the EU and UK, CCPA/CPRA to many users in California, and other regions have their own data protection laws — check every market you launch in.

A lean data footprint makes this section much easier. Our own apps were designed local-first: CyclePrivate and BodyLog keep data on the device with no account required, which keeps their privacy disclosures short and simplifies the account deletion question entirely. We explain the broader approach in our privacy-first launch playbook.

5. Account deletion

If users can create an account in your app, both stores require that they can also delete it. This is a hard requirement, not a best practice.

• Apple: users must be able to initiate account deletion from within the app, and it should be easy to find (usually in Settings or Profile). Deactivating is not enough.
• Google Play: provide an in-app deletion path and a web link where users can request deletion without reinstalling; enter that URL in the Data safety form.
• Delete the data too, not just the login, unless you must retain some records by law; if so, say what and why.
• Handle subscriptions: tell users that deleting an account does not cancel a store subscription, and link to subscription management.

6. Store listing assets and metadata

Prepare listing assets before the final build, because they take longer than most teams expect and inaccurate metadata is itself a rejection reason.

• Screenshots must show the real app. Framing and captions are fine; mock features that do not exist are not.
• Support URL and contact email must work.
• Demo account: if the app requires sign-in, give reviewers working credentials and any steps needed in App Review notes (Apple) and App access (Google).
• Avoid other platforms' names and trademarks in metadata, and do not mention prices that differ by region in screenshots.

7. Age rating and content declarations

• Apple: answer the age rating questionnaire in App Store Connect. Apple's updated system uses 4+, 9+, 13+, 16+ and 18+ ratings, and developers had to answer the new questions for each app in early 2026.
• Google Play: complete the IARC content rating questionnaire, the target audience and content section, and the ads declaration.
• Children: if your target audience includes children, extra rules apply on both stores (Apple's Kids category, Google Play's Families policy), including limits on ads and analytics SDKs.
• Sensitive categories: Google Play has additional declarations for health, financial features and some other app types; Apple has specific guidelines for medical, financial and VPN apps.

8. In-app purchases and subscriptions

If you sell digital content, subscriptions or premium features used inside the app, both stores generally require you to use their billing systems. Physical goods and real-world services (food delivery, rides, consultations) can use your own payment provider such as Stripe or Razorpay.

• Set up products in App Store Connect and Play Console with matching IDs, prices and descriptions.
• Include a restore purchases option on iOS.
• Show clear subscription terms before purchase: price, billing period, trial length and how to cancel, plus links to terms and privacy policy.
• Know the commission: both stores charge a reduced 15% rate to small developers and on many subscriptions, and higher rates otherwise; check eligibility for Apple's Small Business Program.
• Check regional rules: alternative billing and external purchase links are permitted in some markets (for example the EU and the US) under specific conditions that have changed repeatedly since 2024.
• Consider a subscription management service to handle receipts, trials and entitlements consistently across both stores.

9. Common rejection reasons and how to avoid them

Most first-time rejections are avoidable. These are the ones we see most often across the industry, with the fix for each.

10. Final pre-submission checklist

1. 01Developer accounts active, verified and owned by the business; tax and banking complete.
2. 02Release build meets the Xcode 26 / iOS 26 SDK and Android API 36 requirements.
3. 03App tested on current and older devices from a clean install; no crashes in the core flow.
4. 04Closed test completed and production access granted (new personal Google Play accounts).
5. 05Privacy policy live at a public URL and linked in the app and listings.
6. 06App Privacy details, privacy manifests and Data safety form completed and accurate.
7. 07In-app account deletion and Google Play web deletion link in place (if accounts exist).
8. 08Age rating and content questionnaires completed.
9. 09In-app purchases configured, tested in sandbox, with restore and clear terms.
10. 10Icon, screenshots, feature graphic, descriptions and keywords uploaded.
11. 11Demo account and review notes provided.
12. 12Crash reporting and basic analytics working, so you can see problems on day one.
13. 13Phased or staged rollout chosen for the first release.

Want a team that has done this before?

Store submission is part of every mobile app development project at Navelo Software. We prepare the privacy disclosures, listing assets and review notes alongside the build, run the TestFlight and Play closed testing rounds, and keep your accounts in your name. You can download our own apps from our projects page to see the results. If you are preparing a launch, get in touch for a fixed quote.