Store compliance audit for apps and games
We will read your build and your store page against the published review rules before you submit, and hand you the fixes that block a release separately from the ones that only invite a question.
Review rulebook
Свод правил
5 areas
5 областей
In-app currency
Внутренняя валюта
may not expire
не может истекать
When you need a store compliance audit
Review has rejected the build twice
Each answer names a rule and leaves you to guess the screen. The second rejection is the signal that the problem is not the one you fixed.
The submission window is closing
A date is announced, a campaign is booked and the build has not been through review. Every round costs days you cannot get back from the calendar.
A policy change has a deadline
A rule you already comply with is being replaced, with a date attached. After that date the same build stops being acceptable.
Your app takes payments outside
Someone added a payment link, a promotion or a sign-up flow that leads out of the app. Where digital goods are involved, the rule reaches all three.
Players can post to each other
Chat, profiles, nicknames, shared levels. Once users can publish, the store asks who moderates it, how it is reported and how fast it goes.
Nobody owns the store account
The account is in a founder’s name, the certificates are on one laptop, and the person who submitted last time has left.
What you get
- One verdict per rule area
- The rejection in plain words
- A fix list ordered by risk
- A submission checklist you keep
What a store compliance audit covers
A store review is not a taste test: it reads your build against a published rulebook, and the rulebook is longer than the answer you get back. An audit walks it end to end before you submit, so the round trip is spent on the build and not on working out what a two-line rejection meant.
The five areas a review reads
One store publishes its review guidelines in exactly five parts — safety, performance, business, design and legal — and each rejection traces to one of them, because the five cover the whole guideline. Safety covers what users can be exposed to and what they can do to each other; performance is completeness and stability; business is money; design is whether the app is a product in its own right; legal is what the law and the platform require in writing.
Reading them as five areas is what makes an audit repeatable: each area has an owner on your side, and each rejection goes back to the area it came from.
Where money is the problem
- Digital goods and subscriptions have to be sold through the store’s own billing, and the rule reaches promotions, buttons, links and sign-up flows that lead a user out.
- An in-app currency belongs to the product it was bought for: one store says such currencies may not expire, the other that they may be used only in the app or game they were bought for.
- What is charged, when it renews and what the price is have to match what the store’s own purchase screen shows.
- Restoring a purchase has to work, including after a reinstall and on a second device.
What people can post
- Who moderates, on what rules, and how quickly — with a person answerable for it.
- How a user reports something, and how they block another user.
- A published way to reach you that a reviewer can actually use.
- What happens to a user’s content and account when either side stops.
Rules move on published dates
Store policy is not static, and the changes are announced with the date they take effect. One store keeps a page of policy deadlines and moves anything older than three months into an archive, which means a compliant build can stop being compliant without you touching it.
So an audit ends with a date list as well as a fix list: which rule changes reach your product, and when each of them makes your current build unacceptable.
The two lists you keep
- Each area, its verdict, and the screens that verdict rests on.
- The fixes, split into what blocks the submission and what would only be asked about.
- Wording you can send back to review, where the answer is an explanation.
- The checklist your team runs before the next submission.
Paid random mechanics are read separately and have their own disclosure rules — that is a loot box review; the licence, the terms and the privacy policy belong to a product document package.
Sources: the review guidelines of one store are published in five parts and state that in-app currencies may not expire; another store requires digital purchases through its own billing and that in-app currencies be used only in the app they were bought for, and publishes its policy deadlines with effect dates.
Stages of work
Going through the listing and the build — 2–3 working days.
A reviewer sees the store page, the screenshots, the description, the age declaration and the first two minutes of the app. We start where they start.
The five areas, one at a time.
Each area gets its own pass and its own verdict, with the screen or the setting the verdict rests on. That is what makes the result something your team can act on without us in the room.
The payment path.
We will follow every route by which money can leave the app: buttons, links, promotions, sign-up flows and anything a support agent might send a user.
What users can publish.
We will check the moderation rules, the reporting route, blocking and the published contact, and name who on your side answers when a reviewer writes to it.
The permissions and the declarations.
We will match what the build asks for against what the feature needs, and line up what you declared about data with what the product actually collects.
The fix list and the date list.
You get two lists: what to change before this submission, and which published policy deadlines will reach the product later. The second one is the part nobody keeps.
FAQ
Discuss
the Task
Speak to our team
Speak to our team. Tell us about your task –
we’ll help you with it in any jurisdiction.