Before you hit submit
Get your app ready for App Store and Google Play review
App-store release readiness checks the app and everything around it before you submit: core functionality, the listing, metadata, permission requests, crash behavior and the submission itself. For health, wellness and mental-health apps the listing needs as much care as the code, because rejections in this category often come from the claims a listing makes.
What you get
What’s included
Functional checks on the release build
Install, sign-up, the core flow and purchase paths tested on the exact build you plan to submit.
Listing and metadata review
Title, description, screenshots and keywords checked against what the app does and the claims it can support.
Permissions review
Every permission request checked for a clear reason, sensible timing and wording a reviewer and a user will accept.
Crash and stability check
Crash behavior on the release build across the agreed devices, plus a look at any crash reports you already have.
Submission review
Reviewer notes, demo account access, subscription setup and the other submission details that commonly cause delays.
Health and wellness checks
Listings that imply treatment, screenshots showing clinical outcomes, missing crisis resources, and subscription flows that put a safety feature behind a paywall.
A good fit if
- Teams submitting a first version to the App Store or Google Play
- Apps that have been rejected once and need the reason fixed properly
- Wellness and mental-health apps whose listing talks about health outcomes
- Apps adding subscriptions, new permissions or health data access in an update
Not included
- Writing new listing copy or designing new screenshots
- Legal or regulatory review of health claims
- A guarantee that Apple or Google will approve the app
- Full regression of the whole product
How it runs
From kickoff to handover
- Step 1
Gather the release
You send the release build, listing drafts, the permissions the app requests and any previous rejection messages.
- Step 2
Check the app
Functional, permission and crash checks on the release build across the agreed devices.
- Step 3
Check the listing and submission
Metadata, screenshots, claims and submission details compared against what the app does.
- Step 4
Fix list
A written list of what to change before you submit, ordered by how likely each item is to cause a rejection or a bad first review.
Questions
Questions about App-store release readiness
Can you guarantee approval?
No. Only Apple and Google decide. We find the problems reviewers commonly flag before they do, so you submit with the known risks already fixed.
Our app was rejected. Can you help?
Yes. Send us the rejection message. We check the specific reason and the rest of the submission, because fixing one issue and resubmitting can surface the next one.
Why would a mental-health app get rejected if the code works?
Rejections in this category usually come from mismatched claims: a listing that implies treatment of a diagnosed condition, a screenshot showing clinical outcomes, missing crisis resources, or a subscription flow that gates a safety feature. That's why we review the listing alongside the product.
How is this different from QA & Release Readiness?
Release readiness is a week of testing the product itself, ending in a go/no-go. This package tests less of the product and goes deeper on the store side: listing, metadata, permissions and the submission. Teams launching a first version often book both.
When should we book it?
Once the release build is close to final and the listing drafts exist, a few days before your target submission date. Booking earlier means checking a build that will still change.
More from QA & Release
Keep exploring
Often paired with this
Work with us
Ready to start App-store release readiness?
Tell us about your business. We'll confirm the scope and send you a start date.