Services / Mobile / App Store launch

The paperwork between you and launch day, handled

Two developer accounts, two rulebooks, privacy declarations, age ratings, screenshots at half a dozen sizes, and a reviewer who can say no. We do all of it in your accounts, and we handle the appeal when the answer comes back wrong.

Start the conversation →See the technology

Why it matters

The cost is the wait

Teams routinely finish an app and then lose weeks between "it works" and "it is live". Almost none of that time is spent on the app. It goes on account verification, a privacy declaration that does not match what an analytics library actually collects, a reviewer who cannot get past your sign-in because nobody gave them a test account, screenshots at the wrong sizes, and a rule that changed since the last time anyone here submitted anything.

The failure modes are well known and mostly avoidable. Purchases routed around the stores' own billing where the rules require it. Third-party sign-in offered without Sign in with Apple alongside. Permission prompts with no explanation of why the app wants the camera. Data-collection declarations written by a marketer rather than read out of the code. Missing trader details for distribution in the EU. Each one costs a rejection and a fresh trip through the queue, and each one is cheaper to fix before submission than after.

We take the whole submission process: accounts and legal verification, declarations, ratings, listings and assets, beta tracks, submission, the back-and-forth with reviewers, and the phased rollout afterwards. The accounts are enrolled in your company's name with us added as members, so you own the listings, the reviews and the relationship, and you can remove our access whenever you want.

What you actually get

Built to be trusted

The stores are gatekeepers, and the way through them is procedural rather than clever. This is the procedure.

The accounts, in your name

Apple Developer Program and Google Play Console enrolment as your organisation, which for Apple means a verified legal entity and a D-U-N-S number, a step that alone can take longer than people expect. We set up roles properly so agencies and contractors get the access they need and nothing more.

Declarations written from the code, not from memory

Apple's privacy labels and third-party SDK privacy manifests, and Google Play's data safety form, filled in from an audit of what the app and every library inside it actually collects and sends. Mismatches between the declaration and the binary are exactly what automated checks catch.

Listings and assets that are ready, not improvised

Icon, screenshots at every required device size, preview video, title, subtitle, description and keywords, plus localised versions for the markets you sell in. Prepared as a set, so nobody is exporting screenshots at midnight before a launch date already promised to a client.

Beta tracks before the public

TestFlight on iOS, internal and closed testing tracks on Google Play, with testers organised and feedback collected in one place. It also warms up the review relationship: a build that has already passed TestFlight review has cleared part of the obstacle course.

Phased release and a way back

Both stores can release to a small percentage of users first and expand from there. We watch crash rates and startup times per release against a threshold agreed with you, and pause or halt a rollout when it drops below, so a bad build reaches a fraction of your users instead of all of them.

The appeal, when a reviewer is wrong

Rejections are sometimes correct and sometimes a misreading. We answer through the resolution centre with the specific guideline, evidence and a demonstration of the feature in question, and we escalate where escalation is warranted rather than silently changing the product to make a wrong objection go away.

Where it earns its keep

Same pattern, different desks

Three situations bring people here, and only one of them is a first launch.

01 · Startups & first-time publishers

The launch date nobody warned them about

The problem: A first app is finished and the founders discover the submission is its own project: an entity to verify, testing requirements before a new account can publish to production, declarations nobody understands, and a launch date already communicated to investors and customers.
What we build: We start the account and verification work in parallel with the build rather than after it, run the closed testing a new account needs, prepare every declaration and asset in advance, and submit with reviewer notes and a working demo account attached.
What changes: The store paperwork stops being on the critical path, the launch date is set from real constraints rather than optimism, and the first rejection, if it comes, is answered the same day instead of studied for a week.

02 · Financial & regulated services

Where the stores ask for more than a listing

The problem: Banking, insurance, health and similar apps face additional scrutiny: the publisher must be the licensed entity providing the service, evidence of authorisation may be requested, age ratings and content declarations are checked harder, and a rejection here is a compliance conversation rather than a bug.
What we build: Enrolment under the correct legal entity from the start, documentation assembled before submission rather than in response to a request, declarations reviewed against what the app actually does with personal and financial data, and reviewer notes that pre-empt the obvious questions.
What changes: The submission is answered from a prepared file instead of a scramble, and the review becomes a scheduled step with a known shape rather than an open-ended risk hanging over the launch.

03 · Established apps & relaunches

An app stuck, removed, or quietly dying

The problem: An existing app has been rejected repeatedly, pulled for missing a platform deadline, or left unmaintained until it fell below a store's minimum requirements. Meanwhile the listing carries years of reviews and installs that nobody wants to abandon by publishing a new one.
What we build: We work out precisely why it is blocked, bring the build up to current requirements, correct the declarations and listing, and republish into the existing listing so ratings and install base survive, with a phased rollout in case the old app has users on very old devices.
What changes: The app is compliant and shipping again on the same listing, the history is intact, and there is a maintenance cadence in place so the next platform deadline is a calendar entry rather than a removal notice.

The technology

The tools behind it, named

Much of this cluster is paperwork rather than software, which is precisely why automating the parts that can be automated is worth doing.

6 layers · 33 technologies

The consoles

Where the listings, declarations and releases actually live. Enrolled in your name, with our access scoped and revocable.

App Store
Google Play
Xcode
Android Studio
App Store Connect
Google Play Console

Builds and signing, automated

Certificates, provisioning and upload done by a pipeline rather than by one person's laptop, which is also what stops a launch depending on who is on holiday.

fastlane
GitHub Actions
Bitrise
Codemagic
CircleCI
Expo EAS

Beta and test tracks

Real users on real devices before the public listing goes live, and, on a new Google Play account, a requirement rather than a nicety.

TestFlight
Firebase App Distribution
Play testing tracks
Expo EAS Submit
Phased & staged rollout

The listing itself

Assets produced as a set and regenerated automatically when a screen changes, rather than screenshotted by hand every release.

Figma
fastlane screenshots
Localised listings
App preview video
Store listing experiments

The compliance paperwork

The declarations both stores require. Written from an audit of the code and every third-party library in it, because that is what gets checked.

Privacy nutrition labels
Data safety form
SDK privacy manifests
Age ratings
Export compliance
EU trader verification

After the button is pressed

A release is not finished when it is approved. Crash rates and adoption per version decide whether a rollout continues or stops.

Sentry
Firebase Crashlytics
PostHog
Google Analytics
Mixpanel

Product names and logos are the property of their respective owners and are shown to describe the technologies we work with. Their use does not imply any partnership, sponsorship or endorsement.

How we deliver it

Live behind a human first

For a first launch, start this six to eight weeks before the date you want to announce. Most of that is account verification and testing requirements, not review.

A pre-flight review against both rulebooks

We go through the app against the guidelines that actually cause rejections: purchases and billing, sign-in options, permission prompts and their explanations, data collection, content and age rating, and account deletion. You get a list of what must change before anyone submits anything.

Accounts, entities and verification

Enrolment as your organisation, which means legal entity checks and, for Apple, a D-U-N-S number. This is the step that most often surprises people, so it starts first. A verification that stalls can hold a launch regardless of how finished the app is.

Declarations written from an audit

We inventory every SDK in the build, what it collects and where it sends it, then complete Apple's privacy labels and manifests and Google's data safety form from that inventory. Where a library collects more than you are comfortable declaring, that is a decision to make before submitting, not after.

Assets, listing and store presence

Screenshots at every required size, a preview video, icon, and copy written for store search as well as for humans, localised for the markets you sell in. Where it earns its keep, we set up listing experiments so the copy improves on evidence rather than opinion.

Beta tracks, then submission

TestFlight and Google Play closed testing with real testers, which also satisfies the testing requirement a brand-new Play account has to meet. Then the submission goes in with reviewer notes, a working demo account, and any documentation the category tends to attract.

Phased release, then the watch

Release to a small share of users and expand as the crash numbers hold. Afterwards it becomes a calendar: annual account renewal, platform target requirements, operating system releases, and the policy changes both stores publish ahead of time.

Before you commit

The questions worth asking

How long does review actually take?

Most submissions come back within a day or two on both stores, and sometimes faster. But there is no commitment you can hold them to, the first submission from a new account is consistently the slowest, and busy periods around major operating system releases stretch everything. The honest planning assumption is days rather than hours, plus a round for a rejection, which is why we never let a launch date depend on a single clean pass.

Can you guarantee the app will be approved?

No, and nobody honest will. Approval is a reviewer applying a rulebook that both companies revise on their own schedule, and reasonable people sometimes read the same guideline differently. What we can do is remove the avoidable reasons (declarations that match the code, a working demo account, billing routed correctly, permission prompts explained) and answer a rejection quickly and specifically. That turns approval from a gamble into a process with a normal outcome and a known appeal route.

What happens if we are rejected?

We read the exact guideline cited, decide whether it is a fair reading, and respond the same working day. If they are right, we fix it and resubmit. If we think they have misread the app, we reply through the resolution centre with the specific evidence and a demonstration, and escalate to a formal appeal where it is warranted. Rejections are ordinary, most apps meet one eventually and handled promptly they cost days rather than weeks.

Whose accounts and listings are these?

Yours. We enrol under your company's legal entity, you hold the ownership role, and we are members with the access the work requires. Reviews, ratings, install history, revenue and the customer relationship belong to you and stay with you if we part ways, which is the practical reason never to let a supplier enrol an app under their own account.

What does it cost to be on the stores?

Both stores charge for a developer account: Apple's renews annually and Google's is a one-off registration fee. On top of that both take a commission on digital purchases made through the app, which does not apply to physical goods, or to services delivered outside it. If your product sells digital content or subscriptions, that commission is a genuine line in your business model and we will make sure it is modelled before you build, not discovered afterwards.

Once we are live, do the stores leave us alone?

They do not, and this is the part people are least prepared for. Both platforms set deadlines each year by which apps must be built against a recent version of the operating system, or they stop being offered to new users and can eventually be removed. Privacy and policy requirements change with notice you have to be watching for. Certificates and push keys expire, and when a push key expires nothing errors, notifications just quietly stop. Someone has to own that calendar. If it is not you, it should be a support arrangement with someone.

Got an app finished and nowhere to put it?

Tell us what you have built and which stores you need it on. We will come back with what the submission requires, what is likely to be challenged, and how long the paperwork genuinely takes.

Start the conversation →

Explore more

The rest of Mobile Apps

Customer apps Staff & field apps Website-to-app ← All of Mobile