Store Audit

Getting rejected by an app store costs you days. You submit, wait, get a short message quoting a guideline number, guess at what it meant, fix something, and resubmit — and the clock starts again.

Store Audit skips that loop. It checks your app against the rules Google and Apple actually reject for, and tells you what’s wrong while you can still fix it in a minute.

Note

Store Audit requires a paid plan.

Running an audit

1. Open Workspace → Store Audit.

2. Pick Google Play or App Store. The two stores have different rules, so each gets its own audit and its own result — run one, or both.

3. Click Run audit, and give it a minute.

4. You get a verdict and a list of everything that was checked.

Run it again whenever you like — each run replaces the last result for that store.

What you get back

The verdict

🟢 No blocking issues found	Nothing we check for is wrong.
🟡 Needs review before submitting	Something needs your attention, but it isn’t a certain rejection.
🔴 Likely to be rejected	There’s a problem the store rejects apps for. Fix it first.

The findings

Every rule in that store’s list comes back with a result, so you always see the full picture — not just the problems. Anything you need to act on is listed first and opened up; the rest folds into groups you can expand.

Blocking	This gets your app rejected. Fix before submitting.
Warning	This may get you rejected or sent a query by a reviewer.
Needs review	We couldn’t tell from your app alone — have a look yourself.
Passed	We checked this, and it’s fine.
Upcoming	A rule that only starts applying on a future date — the badge shows when.
Not applicable	Doesn’t apply to your app, so there was nothing to check. The row says why.

Open any finding and it tells you what’s wrong, how to fix it, what in your app triggered it, and a link to the exact Google or Apple rule behind it.

The header reconciles to the total — “11 checks · 1 warning · 2 passed · 8 not applicable” — so you can always see what the verdict was based on. Each report also shows when it ran and which revision of your code it read, so you can tell when a result has gone stale after further changes.

Tip

Needs review isn’t a failure. Some things can’t be judged from an app’s code — whether a permission is genuinely essential to what your app does, for example. When we’re not sure, we say so instead of guessing.

Fixing what it finds

Where the fix is a code change, the finding has a Try to fix button — the same one a failed build offers. It hands the fix instructions to Primio and starts the work; re-run the audit afterwards to confirm. There’s a copy button too, if you’d rather paste them somewhere else.

Some findings have no button, and say why. Those are the ones no agent can decide for you: a privacy policy URL that doesn’t exist yet, or a call on what your app should do or be called. The fix instructions are still there, written for you to act on.

And some steps happen outside your code entirely — a declaration in the Play Console, a setting in App Store Connect. Those are listed separately under Do this in the store console, so they never get mixed into what the agent is asked to do.

What we check

21 checks — 10 for Google Play, 11 for the App Store. They’re the rules apps most commonly get rejected for.

Google Play

Check	If it fails	What it means
Android version support	Rejected	Your app must be built for a recent enough Android version. Play requires Android 16 for anything submitted from 31 Aug 2026.
Accessibility features	Rejected	If your app uses Android’s accessibility system, it has to genuinely help users with disabilities. Play watches this one closely, because it’s a common route for misuse.
Seeing other installed apps	Rejected	Asking to see every app on someone’s phone is only allowed for a handful of app types.
Contacts access	Rejected	If you read someone’s contacts, it has to be essential to what your app does — otherwise use the picker that lets them choose one. Applies from 28 Oct 2026.
Location access	Rejected	Background or precise location has to be core to your app and explained to the user, not just requested by default. Applies from 15 Apr 2026.
Explaining permissions	Rejected	Before Android asks for something sensitive, your app has to tell the user what it’s for and why.
More than a website	Rejected	An app that just loads your website in a frame gets rejected. It needs to do something genuinely app-like.
Real functionality	Risky	Demo-level or placeholder apps get rejected. Your app needs real features and real content.
Privacy policy	Risky	If your app collects any data, it needs a privacy policy users can reach from inside the app.
Ads consent	Risky	If you show ads, European and UK users must be asked for consent through an approved consent screen.

App Store

Check	If it fails	What it means
Deleting an account	Rejected	If people can create an account in your app, they must be able to delete it in your app too — not just by emailing you.
Sign-in options	Rejected	If you offer Google or Facebook login, you also need a privacy-respecting option. Sign in with Apple is the usual answer.
More than a website	Rejected	An app that just loads your website in a frame gets rejected. It needs to do something genuinely app-like.
Enough substance	Rejected	Apple rejects apps that are too simple or indistinguishable from hundreds of others — a single-screen utility is a hard sell.
Appropriate content	Rejected	Prank apps and content Apple considers objectionable don’t get through.
Explaining contacts access	Rejected	If your app reads contacts, Info.plist must carry a usage description explaining why — iOS rejects permission-gated APIs without a purpose string.
Original branding	Risky	Your app’s name, icon and description can’t look like an imitation of a well-known app.
Ad tracking consent	Risky	If your ads are personalized, iOS requires you to ask permission to track first. Non-personalized ads don’t need it.
Privacy declarations	Risky	Apple requires a privacy file declaring what data your app uses and why. Missing it triggers an automated rejection email.
Privacy policy	Risky	Every app needs a privacy policy users can reach from inside the app.
Tracking disclosure	Risky	If you say your app tracks users, you also have to list where that data goes.

Deadlines matter: a rule that hasn’t taken effect yet won’t count against you, so an upcoming store requirement won’t turn your report red before it applies.

What it can’t tell you

Store Audit catches the problems that are visible in your app. It’s a strong safety net, not a guarantee.

• It can’t judge things that only happen at runtime, or on a server you control.
• It doesn’t check your store listing — your screenshots, description, age rating or data-safety answers.
• Reviewers are human, and they apply judgment no automated check reproduces.

A green verdict means nothing we check for is wrong. It isn’t a promise from Apple or Google.

Related

• Submission Checklist — the wider pre-submission pass
• Handling Rejections — what to do if you’re rejected anyway
• Google Play Guide and App Store Guide
• Store Assets — generate your store listing