The App Store & Google Play Checklist I Run Before Submission

There is a particularly frustrating class of mobile development bug.

The app works.

Production APIs work.

Payments work.

QA has tested the important flows.

Nobody has found a crash for days.

Then the store review comes back with a problem that has almost nothing to do with the application’s core functionality.

The reviewer cannot log in.

A permission description does not correspond to what the application actually does.

A deep link opens the browser instead of the app.

A screenshot promises something the submitted build does not actually provide.

Or the review team reaches a screen that requires an account, but nobody gave them one.

These are not necessarily difficult engineering problems.

They are submission-boundary problems: the app, its store listing, its privacy declarations, external infrastructure, and the review instructions do not describe exactly the same product.

That is why I now think of store submission as its own QA surface.

APP
  +
STORE METADATA
  +
PERMISSIONS
  +
PRIVACY DECLARATIONS
  +
LINK INFRASTRUCTURE
  +
REVIEWER ACCESS
  =
SUBMISSION

Testing only the first item is not enough.

What Are the Most Common App Store Rejection Reasons? #

Before submitting to the App Store or Google Play, I would check these four areas first:

1. Metadata and screenshots: every claim, image, description, URL, and feature shown in the listing should correspond to the submitted product.
2. Privacy and permissions: requested access should have a clear product purpose, and the explanation, app behavior, and store declarations should agree.
3. Deep links and universal/app links: test them from the external contexts a reviewer may use, not only from your development environment.
4. Reviewer access: if functionality requires authentication or special setup, provide working credentials and precise review instructions.

Here is the condensed version I would keep beside the release pipeline.

Potential rejection/problem	How I try to avoid it
Store screenshots show unavailable or misleading functionality	Capture final screenshots against the release candidate and verify every visible claim
Description promises functionality absent from the reviewed build	Review metadata alongside the actual production build
Permission appears without an understandable reason	Request access in context and make the purpose clear
Privacy declaration and actual app behavior disagree	Audit SDKs, data flows, permissions, and store disclosures together
Deep link opens the wrong destination	Test installed/not-installed states and real HTTPS links
Universal/App Link silently falls back to browser	Verify domain association files and production configuration
Reviewer hits authentication and cannot continue	Supply a working review account and instructions
Reviewer account requires OTP or unavailable external approval	Provide a review path that can actually be completed
Backend is inaccessible during review	Test the reviewer account against production before submission
Review notes assume reviewers will “figure it out”	Document non-obvious flows and prerequisites explicitly

That table is not a replacement for either store’s policies. It is the practical layer I would run before opening those policies for the final submission check.

1. Metadata Is Part of the Build, Even Though It Isn’t in the Binary #

Developers naturally concentrate on the artifact:

.ipa
.aab

The reviewer sees a larger system.

They also see the name, description, screenshots, preview media, privacy information, support information, URLs, account flows, and whatever claims the listing makes.

That means metadata needs QA too.

Screenshots are not merely marketing assets #

Suppose a screenshot says:

AI-powered automatic analysis

but the submitted version only exposes that feature to an internal beta group.

Or a screenshot shows an interface from the next release.

Or the marketing team changed a screen in Figma after the release candidate was frozen.

Individually, these may look like small coordination mistakes.

From the outside, however, the listing and the product no longer describe the same thing.

My preference is to capture or approve store screenshots against the release candidate, not against whatever happens to be the latest design file.

I want this relationship:

STORE PROMISE
      ≈
REVIEW BUILD
      ≈
ACTUAL USER EXPERIENCE

The further those three drift apart, the more unnecessary uncertainty we introduce into review.

Run a literal metadata pass #

Before submission, I would read every public field as if I had never seen the product before.

Check whether:

• feature claims are true for this exact version;
• screenshots represent the current interface;
• URLs work without internal access;
• support and privacy destinations are reachable;
• text does not describe a feature that was removed or postponed;
• platform-specific screenshots actually represent the appropriate platform experience.

There is another useful trick here: give this review to somebody who did not write the metadata.

Developers and product owners know what a sentence is supposed to mean. A reviewer only knows what it says.

2. Privacy and Permissions Must Tell the Same Story #

Permissions are another place where implementation and product language easily diverge.

Imagine the application requests photo access.

The developer knows exactly why.

The product manager knows why.

The reviewer encounters:

Allow access to your photos?

Their context may be completely different.

I prefer permission flows where the intention exists before the operating-system prompt:

User taps:
"Upload profile photo"

        ↓

App explains why photo access is useful

        ↓

Platform permission request

rather than:

First launch

    ↓

Photos?
Camera?
Location?
Notifications?

The UX is better, but there is also a review benefit: the relationship between the feature and requested capability becomes easier to understand.

Audit what the app actually requests #

Do not perform this check from memory.

Look at the release build.

Third-party SDKs, analytics packages, authentication tools, advertising libraries, mapping tools, and other dependencies can affect the privacy surface of an application.

The question is not:

What data do we intend to use?

It is:

What does this submitted version actually access, collect, transmit, or request, and do our declarations accurately describe it?

Apple maintains its privacy guidance and requirements in its developer documentation, including App Store privacy information:

https://developer.apple.com/app-store/app-privacy-details/

Google’s current policy documentation should likewise be checked through the Play Console and Policy Center:

https://play.google.com/about/developer-content-policy/

Because these requirements evolve, I would make privacy verification a release task rather than a document somebody completed once when the app launched.

3. Deep Links Fail in More States Than Developers Usually Test #

Deep links are a wonderful example of functionality that can appear completely healthy during development and still fail in review.

You test:

myapp://product/123

The app opens.

Done?

Not necessarily.

The real journey may be:

email
 ↓
https://example.com/product/123
 ↓
app installed?
 ├── yes → open correct app screen
 └── no  → sensible web/store fallback

That involves more than routing inside the application.

For Apple’s Universal Links, the relationship between the website and app needs to be configured correctly. Apple’s documentation is the starting point:

https://developer.apple.com/documentation/xcode/supporting-associated-domains

For Android App Links, use the current Android developer documentation:

https://developer.android.com/training/app-links

Test the link from outside your happy path #

I would include at least these states in pre-review QA:

App installed + user authenticated
App installed + user logged out
App installed + cold start
App already running
App not installed
Expired/invalid content ID
Valid domain, unknown route

And I would test links from realistic external entry points where possible.

The classic mistake is proving that the application’s router understands /product/123 while forgetting that the operating system never hands /product/123 to the application.

Those are different tests.

Watch production domains #

Another easy trap:

staging.example.com

works perfectly.

Then production uses:

example.com

with different association configuration.

Your internal test proves the application logic.

It does not necessarily prove the production relationship between domain and app.

For store review, production configuration is the interesting configuration.

4. Give the Reviewer a Real Test Account #

This is probably the least glamorous item on the entire checklist.

It is also one I would never leave until the end.

If meaningful functionality is behind authentication, the reviewer needs a viable way to reach it.

That sounds obvious until the actual login flow looks like:

email
 ↓
password
 ↓
SMS OTP
 ↓
company approval
 ↓
subscription required
 ↓
data appears only after admin setup

And the review notes say:

Test account:

review@example.com
Password123

The credentials technically exist.

The journey does not.

Test the reviewer, not merely the account #

Before submitting, I would take the credentials intended for review and run them from a clean device/session.

Ask:

• Does the password still work?
• Is the account locked?
• Does it require an OTP the reviewer cannot receive?
• Does it have the correct subscription/role?
• Does it contain enough test data to expose the important functionality?
• Is any feature restricted by geography, organization, hardware, or server-side flag?
• Are the instructions still accurate?
• Will the backend remain available during review?

For a role-based application, one account may not be sufficient.

If review needs to understand:

Customer
Provider
Admin

explain how those roles can be tested instead of expecting the reviewer to reverse-engineer the product.

Review notes should describe non-obvious behavior #

Bad:

Please review the dashboard.

Better:

1. Sign in with the supplied reviewer account.
2. Open "Projects" from the bottom navigation.
3. Select the preloaded "Demo Project".
4. Tap "Generate Report".
5. The generated PDF can be viewed without payment.

The goal is not to persuade a reviewer.

It is to remove ambiguity.

My Pre-Submission Review Checklist #

This is the version I would actually paste into a release ticket.

Store listing #

[ ] App name/subtitle/short description checked
[ ] Full description matches current release
[ ] Screenshots match current UI
[ ] Screenshot claims are available in reviewed build
[ ] Support URL works publicly
[ ] Privacy URL works publicly
[ ] Other submitted URLs checked
[ ] No stale references to removed features

Privacy and permissions #

[ ] Release build permissions audited
[ ] Each permission has a real product purpose
[ ] Permission explanations match actual use
[ ] Permissions are requested at a sensible moment
[ ] Third-party SDK behavior reviewed
[ ] Store privacy declarations checked against current build
[ ] Account/data deletion requirements checked where applicable

Links #

[ ] Deep-link routing tested
[ ] Universal Links / Android App Links tested
[ ] Production association configuration verified
[ ] Cold-start links tested
[ ] Logged-out state tested
[ ] Invalid destination tested
[ ] App-not-installed behavior tested

Reviewer access #

[ ] Reviewer account created
[ ] Credentials tested immediately before submission
[ ] Account has correct role/subscription
[ ] Useful sample data exists
[ ] OTP/2FA does not block review path
[ ] Non-obvious steps documented
[ ] Required hardware/geography explained
[ ] Production backend confirmed available

Final sanity pass #

And then I would do something intentionally boring:

install the actual release candidate on a clean device and follow the review instructions exactly as written.

Do not fill gaps with developer knowledge.

If the instruction says:

Tap Reports.

and there are two different things called Reports, that is a problem worth fixing before somebody outside the team encounters it.

App Store vs Google Play: I Would Not Use One Frozen Checklist Forever #

It is tempting to create one internal document called:

APP STORE CHECKLIST FINAL FINAL v7

and use it for the next three years.

I would avoid that.

Apple and Google maintain separate policy systems, tooling, privacy requirements, declarations, and review processes. They also change them.

The durable internal checklist should therefore contain two types of tasks:

Stable engineering checks
+
Current platform-policy checks

“Does our test account work?” is fairly stable.

“Have we satisfied every current Play Console declaration relevant to this app?” needs to be verified against the current Play requirements.

The same applies to Apple.

Use the checklist to prevent predictable engineering mistakes.

Use the official documentation to determine the current policy.

A Useful Release Workflow #

Instead of treating store submission as the final button after QA, I prefer to think about it as a separate mini-release:

Feature QA
    ↓
Release candidate
    ↓
Store-boundary QA
    ├── metadata
    ├── privacy
    ├── permissions
    ├── links
    └── reviewer access
    ↓
Current policy check
    ↓
Submission

This also makes ownership clearer.

The developer can verify links and permissions.

Product can verify feature claims.

Marketing can verify listing assets.

Whoever owns privacy/compliance can verify declarations.

QA can run the reviewer journey without relying on internal knowledge.

The important thing is that somebody owns the whole boundary, not just their individual field in the submission form.

Frequently Asked Questions #

Conclusion #

A failed first submission is especially irritating when the fix is something like:

wrong screenshot

or:

review account doesn't work

or:

production universal link misconfigured

because none of those necessarily reflects the quality of the application’s core engineering.

But they are part of the product being reviewed.

That is the useful mental shift.

I don’t treat App Store or Google Play submission as:

build finished
     ↓
upload

I treat it as:

build finished
     ↓
test the submission boundary
     ↓
verify current store requirements
     ↓
upload

The goal is not to create a checklist that magically guarantees approval. No checklist can do that.

It is to stop spending another review cycle on something the team could have discovered with a clean device, a reviewer account, a few production links, and twenty minutes of deliberately boring verification.