Mobile Development
App Store & Play Release
Getting your build through Apple and Google review and onto the stores, with the listing, privacy answers and rollout handled properly.
What this actually is
Getting through review and onto the store, with the listing set up properly.
Release is its own job, and it is where first-time teams lose the most time. Apple reviews every submission before it goes live. Google asks you to declare exactly what data the app collects and what you do with it. Both want signing certificates, screenshots at the right sizes, an age rating and a privacy policy that actually matches the app’s behaviour.
We take that off your desk. Accounts and certificates get set up in your name, the listing gets written and filed, and when a rejection comes back we answer it rather than guessing. Releases go out staged, not all at once — a bad build should reach a small slice of your users and be pulled, not land on everyone at midnight.
How we work
Four steps, in this order.
Prepare
Accounts, certificates, privacy answers and data-safety declarations.
Submit
Build, screenshots and listing copy assembled and filed for review.
Resolve
Handle rejections and reviewer questions until it is approved.
Release
Staged rollout so a bad build reaches ten people, not ten thousand.
What you get
Every engagement hands over these.
- A live listing on the App Store and Google Play
- Developer accounts, signing certificates and keys held in your name
- Store screenshots, listing copy, age rating and privacy declarations
- A written release runbook your team can follow next time
Who it’s for
This is usually the right fit when…
- Your app is finished and sitting on a laptop because nobody knows how to submit it.
- You have been rejected more than once and the reviewer’s reasons do not make sense.
- An internal team built the app but has never set up certificates or a data-safety form.
Questions
The things people ask before starting.
How long does review take?
Nobody can promise you a number, and anyone who does is guessing. Both stores publish guidance, both vary with load and with what your app does, and a rejection restarts the clock. What we can control is how often you get rejected — most rejections come from avoidable things like missing test credentials, an unclear privacy answer or a broken sign-up flow.
What if the app gets rejected?
We handle it. Rejections usually cite a specific guideline, and the fix is either a code change, a clearer explanation in the review notes, or a correction to the listing. We reply, resubmit and keep going until it is through. Rejection is a normal part of releasing — it is not a sign something has gone badly wrong.
Do we need our own developer accounts?
Yes, and you should want them. The accounts are registered to your company, the paid subscriptions are billed to you, and the apps live under your name. Publishing under an agency account is convenient right up to the day you change agency — then the listing, the reviews and the install base all belong to someone else.
Can you release an app you did not build?
Yes. We need the source code, the ability to build it, and whatever accounts already exist. Expect a short audit first — we check that the app builds cleanly, that it does what the listing will claim, and that the permissions it requests can be justified. If something will clearly be rejected, you hear it before we submit.
Have a project in mind?
Tell us about your project, study or idea — and let's see what's possible.
Get in touch