Ship · App Store & Google Play launch
App launch service for Google Play and the App Store: listings, privacy forms, test tracks, reviewer access and rejections handled until the app is live. We take an app that works on your test phones and carry it through everything that still stands between it and your users: developer accounts, signing, the data-safety and privacy answers, store screenshots, closed testing, TestFlight, reviewer notes and a staged release. When a reviewer says no, we read the reason, fix the cause rather than the symptom, and resubmit.
Updated
Google Play
App Store
At a glance
Where are you stuck?
Most teams come to us holding one of these lines from Play Console or App Store Connect. Each one has a usual cause and a usual fix. These are the eight we meet most, written the way the consoles show them.
What you get
A store launch is a pile of small, separate jobs owned by nobody in particular. We own all of them, and at the end you hold a launch record: what was submitted, which answer went into which form and why, so the next update goes through without anyone guessing.
The privacy answers depend on where your users live as much as on what the app does. We write them with the law in view: see our guides to India's DPDP Act for app builders, UK GDPR for app startups and the UAE's data protection law for apps.
How we run a launch
Store work has waits you cannot shorten: Google's 14-day closed test for new personal accounts, review queues and identity checks. So we count back from your date and start the slow parts first. A first Android launch on a new personal account needs at least three weeks for the closed test and Google's production review alone. This is a typical runway; yours is written for your app.
Tminus 21 days from launch
Developer accounts in your company's name. A company needs an organisation account, which needs a D-U-N-S number, and both stores verify identity before the first submission. We are invited as users with the right role. On Apple, the Developer role cannot create distribution certificates, so we ask for Admin while the launch runs.
From you: Open or confirm both developer accounts, request the D-U-N-S number if you do not have one, and invite us. Identity checks need a director's documents, so this is the step only you can do.
Tminus 18 days from launch
Target API level, SDK version, minimum iOS version, every permission and its reason, how the app takes payment, account deletion and the privacy manifest. Each gap gets fixed in the code now, not found by a reviewer later.
From you: Tell us what the app sells and how, which data it collects for which purpose, and whether anyone under 18 will use it. Those answers decide billing, the privacy forms and the age rating.
Tminus 14 days from launch
A release build goes to real phones: Play's closed track with named testers, and TestFlight for iPhone. Crash reports come back readable. For a new personal Play account, this is where the 14 days start.
From you: Give us the testers: at least 12 real people with Google accounts who will install the app and keep it for two weeks. Staff, friends and early customers all count.
Tminus 10 days from launch
Screenshots from the real app, descriptions, the data safety form, App Privacy, ratings and declarations. The answers are checked against what the app actually sends, SDKs included.
From you: Approve the listing copy and the screenshots, and confirm the privacy policy URL is live on your website. We draft; you sign off, because the listing speaks for your company.
Tminus 7 days from launch
The exact build we will submit is pushed hard on a current Android and iOS version: back gestures, killing the app mid-flow, double taps, airplane mode and a stopped server. We record its version, commit and checksum.
From you: Walk the main journey yourself on your own phone. You know the business better than any test plan, and this is the cheapest moment to change your mind.
Tminus 3 days from launch
Both stores get the build, the review notes and a demo account that works. Apple says it answers at least half of submissions within 24 hours and 90% within 48. Google says some apps take up to seven days.
From you: Keep the demo account and the support email working, and tell your support team the app is in review, in case a reviewer writes in.
Tminus 0 days from launch
Approval and release are separate. We hold the release until your date, then roll out to a share of users on Play and use Apple's phased release, watching crashes and reviews before widening.
From you: Press the button with us, or let us press it at an agreed time. Have whoever answers customers ready for the first reviews and questions.
T+7 days from launch
Full rollout, the first update planned, and the launch record handed to you or carried into maintenance, so the next release reuses every answer.
From you: Decide who keeps the app current from here: your own developer, us, or nobody yet. If it is nobody, the next store deadline will decide for you.
Rejections we plan for
Apple reviewed 9.1 million submissions in 2025 and rejected 2.09 million. Most rejections come from a short list of rules. We check every one of these before submitting, rather than waiting for a reviewer to find it. For the full rule text and sources, see our guide to the most common App Store rejections. The store-by-store requirements are in our App Store rejections guide and the Google Play data safety guide.
| Store and rule | What it catches | How we prevent it | Status |
|---|---|---|---|
| Apple 2.1 · App Completeness | Crashes, placeholder content, broken links, and no demo account for the reviewer. | Break-test the submitted build, remove unfinished screens, put a working account in the notes. | Checked |
| Apple 5.1.1(v) · Account deletion | Apps that let people sign up but only let them deactivate, or hide deletion on a website. | Deletion starts inside the app; Sign in with Apple tokens are revoked on deletion. | Checked |
| Apple 3.1.1 · In-app purchase | Digital subscriptions or unlocks sold through a card form or a link out. | Digital goods go through in-app purchase; physical goods and services use your own gateway. | Checked |
| Apple 4.2 · Minimum functionality | An app that is a website in a frame. | Native screens for the core journey, with phone features where they help. | Checked |
| Apple 4.8 · Login services | Social login offered without an equivalent private option. | Add a login that collects only name and email and lets people hide their email. | Checked |
| Apple 1.2 · User-generated content | Chat, posts or comments without filtering, reporting, blocking and contact details. | All four built and visible before the first submission. | Checked |
| Play · Broken functionality | Reviewers locked out by one-time codes, rate limits or expired test accounts. | Reviewer accounts exempt from code limits, tested from outside your network before submitting. | Checked |
| Play · User data and account deletion | A data safety form that misses SDKs, or no web link for deleting an account. | SDK-by-SDK data map; a deletion page that names the app and works without it. | Checked |
| Play · Photo and video permissions | Broad photo library access where the system picker would do. | System photo picker; broad access only with a filed declaration and a reason. | Checked |
| Play · Payments | Digital content sold through your own gateway, or store billing used for physical services. | Play Billing for digital subscriptions; your gateway for fares, deliveries and goods. | Checked |
Launch log
Four Android apps we built are live on Google Play: Pakka's customer and driver apps, Trainr and LetSlic. On iPhone, Pakka's two apps are in Apple's App Store review, and Trainr's team released its iPhone app after our handover. Here is the record, rejection included, because that is where a launch partner earns its keep.
Pakka · both Android apps
A pre-submission QA pass on 14–15 October found and fixed 28 defects, two of which would have blocked release.
Pakka · both Android apps
Broad photo library permissions removed in favour of the system photo picker, checked on Android 16.
Pakka · customer app
Approved and published on Google Play on its first submission.
Pakka · driver app
Rejected under Broken Functionality: the shared reviewer number hit the server's limit on one-time codes. Reviewer phones were exempted on the server, the sign-in instructions rewritten, and the same bundle resubmitted the next day.
Pakka · both iPhone apps
Template iOS projects made release-ready, a launch crash under the iOS 27 SDK found on a real iPhone and fixed, then Beta App Review approved both apps and they went into App Store review.
Trainr · Android
Versions 1.0 to 1.0.2 ran on closed testing; 1.0.3 was the first production build, with live payments. Native libraries limited to two architectures and checked on the built bundle.
Trainr · iPhone
Uploads had failed since 25 May with a signing error. The app record had never changed; a rename had. We reverted the identifier and added six purpose strings, and build 22 reached TestFlight. Trainr's own team released the iPhone app after our handover.
LetSlic · Android
Premium is a digital subscription, so on Google Play it is sold through Play's own billing rather than a payment gateway.
Read the full stories in the Pakka case study, the Trainr case study and the LetSlic case study.
Decisions you make with us
None of these is a technical detail you can leave to us. Each changes who owns what, when you can launch or how your app earns. We lay out both sides and say which we would pick for your situation.
Personal
Quicker to open, but the listing shows a person's name, and new personal Play accounts must run the 14-day closed test before production.
Organisation
Needs a D-U-N-S number and identity checks for the company, and the listing shows your company. Google advises it for financial and health apps.
We usually recommend: Organisation. If a company publishes the app, we recommend an organisation account from day one. Moving an app between accounts later is slower than waiting a few days for a D-U-N-S number.
Together
One launch moment, one marketing push, and nobody on either platform left waiting.
Android first
Fewer moving parts on day one, and in markets like India most of your users may be on Android anyway.
It depends on your users. It depends on where your users are. We show you the extra review time and testing the second store adds, and you decide.
Everyone at once
Simple, and fine for a tiny audience or an internal app.
Staged
A share of users gets the release first; you widen it once crash reports and reviews look right.
We usually recommend: Staged. Staged, almost always. A problem that reaches 10% of users is a bad afternoon; one that reaches everyone is a bad week of reviews.
Store billing
Required for digital content: subscriptions, premium features, in-app currency.
Your gateway
Required for physical goods and services used outside the app: deliveries, rides, bookings, products.
The store rules decide. The stores' rules decide this, not taste. We read both rule books against what you sell before a line of payment code is written.
On approval
The app appears as soon as the reviewer passes it, which may be a Sunday night.
On your date
Approval and release are separated, so launch day matches your marketing, press and support plans.
We usually recommend: On your date. We hold the release and publish on your date. Approval is not a launch plan.
Before and after launch
A launch is one leg of a longer run. It only goes smoothly if the build arriving at it was tested properly, and it only stays smooth if someone keeps the app current afterwards.
Launch starts from a build that has been walked screen by screen on real phones. If we built the app, that build comes from our own mobile app work. If someone else did, we read the code first.
Everything on this page: the stores' paperwork, reviewer access, rejections handled and a staged release on the date you choose.
Google raises the target API level every year and Apple the SDK version. Servers need watching. Maintenance keeps the app accepted by the stores long after launch day.
Earlier than launch? Start with a Discovery Sprint, read how a project runs with us or browse the apps we have built. We build apps in React Native and take on Flutter apps too, and every launch includes the pre-launch security checks.
Plan for about three weeks for a first Android app on a new personal developer account, because Google requires a 14-day closed test and then reviews the production application, usually within seven days. On an organisation account the closed-test rule is not stated, and a well-prepared submission can be live within days. Apple says it reviews at least half of submissions within 24 hours and 90% within 48. Account set-up and identity checks come before all of this, so we start them first.
Yes. The store work is the same whoever wrote the app, but we read the code before we promise a date, because store rules often need code changes: permissions, account deletion, how payments are taken, the target API level. If the code needs more than launch fixes, we say so and point you to an audit first.
Yours, in your company's name. We are invited to the account as users with a role, do the work and hand everything back. An app published under an agency's account is hard to move later, and the listing shows the wrong name to your users.
We read the rejection (most are one of a few common causes) and the evidence the reviewer attached, reproduce it as the reviewer would, and fix the cause rather than arguing. Then we resubmit with a note that explains what changed. When Pakka's driver app was rejected because the reviewer was locked out by a one-time-code limit, the fix was on the server, the same bundle was resubmitted the next day, and the app is live.
No. Both stores let you invite people with a role, and that is how we work. On Apple we ask for the Admin role while the launch runs, because the Developer role cannot create distribution certificates. You can remove us the day the launch is done.
If the app is on a personal Play developer account created after 13 November 2023, Google will not open production until a closed test has run with at least 12 testers opted in for 14 days in a row. We set up the tester list, keep a stable build on the closed track and file the production application when the 14 days are done.
It depends on what you sell. Physical goods and services used outside the app, such as deliveries, rides or bookings, must use your own gateway. Digital content and subscriptions must go through the store's billing on both Google Play and the App Store. LetSlic's Premium subscription uses Play's billing for exactly this reason.
The store work is not tied to a framework. When the fix is in the code, we need to work in the app's stack: every app we have shipped is React Native, and we also take on Flutter. For anything else we tell you before we start rather than learn on your app.
Send the store links or test builds you have, which accounts already exist and the date you are aiming for. An engineer who has done these launches reads it and replies with what has to happen first.
Not ready to launch yet? Start with the Google Play checklist or see all our services.
