Store readiness
A list of what would stop your submission, what review will ask about, and what you can point at as evidence. It reads your app’s real configuration — which features you placed, in which zones, with which settings — rather than a checklist you fill in yourself.
Open it from your app’s page: Prepare App Listing, then Before you submit.
The same findings are counted by the bell in the builder header, next to Settings. Because the list is read from your configuration, it moves as you build — placing a feed adds the rows about reporting and blocking, and placing a login adds the row about account deletion. The bell is there so you see that while you are still on the canvas that caused it.
Three levels
Section titled “Three levels”| Means | Do | |
|---|---|---|
| Block | The submission fails, or the store rejects it | Fix it before submitting |
| Warn | Review will probably ask | Have an answer ready, in the notes |
| Pass | Something you can point at | Nothing. It is evidence, not a chore |
Passes are listed rather than hidden on purpose. “Members can delete their own account” is the exact sentence that answers guideline 5.1.1(v), and it is more useful in front of you when you are writing review notes than tucked away.
The audit runs per store. Some checks apply to the App Store, some to Google Play, and most to both.
What it checks
Section titled “What it checks”The app itself
Section titled “The app itself”| Check | Level | What it means |
|---|---|---|
| The app has no screens | Block | Nothing is placed in any navigation zone, so the app opens to an empty shell |
| A menu drawer cannot be opened | Block | A drawer holds features and nothing opens it, so members cannot reach them either |
| Canvas screens still show sample content | Warn | A placed canvas screen still uses the sample videos, photos or avatars its blocks arrived with |
| Some labels use builder words | Warn | A tab, menu or drawer label says Canvas, Template, Demo, Sample or Test instead of what the screen shows |
The second one is a defect in the app rather than a submission problem. Walking the navigation to write review notes is the only place it becomes visible.
The third names each screen. Video, Video Slider, Image, Gallery and Reviews blocks arrive filled with sample media so they show something the moment you drop them. That media is not yours, so replace it before you submit. See Sample content. The row only appears for an app that places canvas screens.
The fourth quotes each label. Canvas screens are where it comes up most: a menu called “Canvas” or a tab still on its default “Template Screen” makes App Review ask whether the app is a demo (guideline 2.1). Rename them in the Appearance panel to say what the screen holds, such as “Explore”, “Meetups” or “Resources”.
The listing
Section titled “The listing”| Check | Level | What it means |
|---|---|---|
| Required listing fields are empty | Block | The store will not accept a submission without them |
| A field is too long | Block | Over the store’s limit. Nothing else on the page saves until it fits |
| The review notes still have a question in them | Block | The generated notes left [ … ] for you to answer |
| The app name may read as promotional | Warn | A price, a ranking claim, or a word like “free” or “best” |
| No app icon | Block | Neither store accepts a submission without one |
The “still have a question in them” check exists because the notes generator leaves brackets where the app genuinely cannot know the answer — what your shop sells, most often. Submitting one unedited tells review nobody read the notes.
See Preparing your store listing and Notes for App Review.
The reviewer getting in
Section titled “The reviewer getting in”| Check | Level | What it means |
|---|---|---|
| No demo account for the reviewer | Block | Some screens need a sign-in and review has no way in |
| Some screens are restricted by role | Warn | A reviewer without that role sees a restriction message |
If every screen is reachable signed out, this passes and asks for nothing.
What Apple enforces
Section titled “What Apple enforces”| Check | Level | Guideline |
|---|---|---|
| Sign in with Apple is missing | Block | 4.8 — required alongside any other third-party sign-in |
| Members cannot report content | Warn | 1.2 — reporting objectionable content |
| Members cannot block abusive users | Block | 1.2 — apps with user-generated content must let users block abusive users |
| Published terms and a moderation commitment | Warn, or Pass | 1.2 — terms the member agrees to, and acting on reports within 24 hours |
| Accounts can be created but not deleted | Block | 5.1.1(v) — in-app deletion |
| Review will ask what you sell | Warn | 3.1.1 — digital content must use in-app purchase |
| The photo prompt explains itself | Pass | 5.1.1 — a reason in the prompt |
| The location prompt explains itself | Pass | 5.1.1 — a reason in the prompt |
| Declare members’ videos in App Privacy | Warn | 5.1.2 — your App Privacy answers must cover what members upload |
The blocking row appears only when your app has member content: a feed, chat, forums, groups, the directory, profiles, photos, reviews, posts or search. In any such app it normally passes, naming where members find Block, because User Blocking is added for you alongside those features. It fails only when User Blocking is missing — an app imported from elsewhere, or a configuration saved before the feature existed — and the row suggests adding it.
The terms row asks your site whether the Terms & Conditions service is on under Memberside → Services. Once it is on, every sign-up screen in the app asks new members to agree to your terms and your site records that they did — see Terms & Conditions. The row passes, naming those screens, when the service is on with a terms page chosen and your app places at least one of them: Register, Default Register, or a member sign-up Entry Form. It stays a warning when:
- the service is off, or your site cannot be reached — it recommends switching the service on
- the service is on but no terms page is chosen
- the app places no register screen. The Create an account link on a login screen does not count, because a reviewer cannot find that screen in your navigation
- the only sign-up form is an Entry Form with Show terms switched off
The service answers the terms half only. The commitment to act on reports within 24 hours is still yours to state, in the review notes, so a passing row still says so.
The video row appears only when members can actually post video: your site has Video connected, and the app places a screen that can carry one, such as a feed, an album, a forum or a chat. The videos members post, and the sound in them, are uploaded and stored, so Apple counts them as data your app collects. In App Store Connect, under App Privacy, declare Photos or Videos and Audio Data as collected User Content: linked to the member, used for App Functionality, not used for tracking. Most apps already declare photos; Audio Data is the one usually missing. The row stays a warning because the answers live in App Store Connect, where the audit cannot read them.
What Google Play enforces
Section titled “What Google Play enforces”| Check | Level | What it means |
|---|---|---|
| The build is signed with a debug certificate | Block | This app cannot yet sign with your own upload key, and Play refuses anything else |
| Play signing has not been checked yet | Warn | Nobody has asked whether this app can sign for Play |
| Members cannot report content | Warn | Play’s User Generated Content policy requires in-app reporting |
| Members cannot block abusive users | Block | The same policy requires in-app blocking of users and what they post |
| Published terms and a moderation commitment | Warn, or Pass | Terms members accept before they post, and moderation of what they post |
| Accounts can be created but not deleted | Block | Play’s account deletion policy requires deletion inside the app |
| Declare members’ videos in Data safety | Warn | The Data safety form must cover what members upload |
The signing row is read from your app’s Play setup, so it turns green the moment your upload key is in place. It is a warning rather than a blocker until something has actually checked — pressing Build checks it, and so does opening Android signing.
The signing row applies to Google Play alone. An iOS build is signed with your own distribution certificate and has no equivalent — see How iOS builds work.
The other four rows are the App Store’s guideline 1.2 and 5.1.1(v) rows in Play’s words. They read the same screens and pass the same way: place User Blocking, a reporting screen, a register screen with Terms & Conditions on, and Settings, and both lists turn green together.
Two things on Play stay with you, because nothing in your app answers them:
- The content-rating questionnaire. Answer it as an app where users interact. Understating it is itself a policy violation. The terms row reminds you, even when it passes.
- The web deletion link. Play also wants a web page where members can ask for their account to be deleted without the app. Add it under App content → Data safety in Play Console. The deletion row names this when it passes.
- Members’ videos. When your site has Video connected and the app can post video, declare Photos and videos → Videos under App content → Data safety, as collected and required for app functionality. The video network stores them on your behalf, which Play counts as a service provider rather than sharing. The video row reminds you.
The screenshots
Section titled “The screenshots”| Check | Level | What it means |
|---|---|---|
| Screenshots will use sample data | Warn | The app is not connected to a WordPress site |
| No preview member chosen | Warn | Members-only screens will photograph as empty states |
See Store screenshots.
Some failures are fixed by placing a feature
Section titled “Some failures are fixed by placing a feature”This is the part of the audit worth reading slowly. Several obligations are not settings — no field turns them on. They are satisfied by a screen being in your app, and by nothing else. Each one is asked by both stores, so one screen clears the App Store row and the Google Play row together.
| Obligation | Satisfied by | And by nothing else |
|---|---|---|
| Reporting objectionable content | News Feed, Create Social Post, or Photos | BuddyPress Activity has no report action at all |
| Blocking an abusive member | User Blocking, added for you with any member content | The chat plugins’ own block lists are folded into it rather than counted separately |
| Deleting your own account | Settings, with its Delete tab enabled on your site | A link to a web form or an email address is explicitly rejected |
Reporting and deletion are fixed by placing a feature, not by filling in a form. Blocking is the one you rarely have to think about: User Blocking arrives with the first feed, chat or directory you place.
The audit also names services and plugins that would close a gap. The Memberside Terms & Conditions service puts an agreement on every sign-up screen in the app.
The permission prompts, in the words review reads
Section titled “The permission prompts, in the words review reads”These are fixed. You cannot edit them, and they are what appears on the phone.
Photos: “This app needs access to your photos so you can upload a profile picture, add photos to an album, and attach images to what you post.”
Location: “This app uses your location when you choose to add it to your profile or a job you post, and to show where you are and the members near you on the map.”
Camera and microphone, in an app with a screen that can post video: “This app uses your camera only when you choose to record a video to post, to add to an album or to send in a message. Photos you add to your profile, your posts and your albums are chosen from your existing photo library.” and “This app uses your microphone only to record the sound of a video you choose to record and post, add to an album or send in a message. It never records audio at any other time.”
They are only written into the build when a feature that asks for that permission is placed. An app with no photo upload never asks and never declares it. An app with no screen that can post video says it never uses the camera or microphone.
What the audit cannot tell you
Section titled “What the audit cannot tell you”It reads your app’s configuration and your site’s plugin list. It does not read your content, so it cannot tell you whether your description is accurate, whether your screenshots show the app as it now stands, or whether the product you classified as physical really is.
The digital-goods check is the clearest case: everything it reports rests on your site classifying each product correctly, and the one product overridden by hand is the one that reaches review. See Selling digital products in your app.
When it does not work
Section titled “When it does not work”| Symptom | Cause | Fix |
|---|---|---|
| A block you have fixed is still listed | The audit reads saved configuration | Save, then reopen the page |
| “Required listing fields are empty” naming a field you filled in | It was filled in for the other store | Each store has its own listing |
| Nothing on the listing page will save | A value is over the store’s limit | Fix the too-long field first; it blocks the whole form |
| The review notes keep failing the bracket check | The brackets are still around your answer | Remove the brackets as well as the prompt |
| Sign in with Apple is demanded on an app you only ship on Google Play | The check runs for the App Store listing | Switch to the Google Play tab |
| The debug certificate blocker will not clear | Your app still has no upload key, or nothing has re-checked since you added one | Add your key under Android signing, then press Build or Check again |