App Store release: from a finished app to a live listing
We get your finished app into the App Store and Google Play — store listings, privacy declarations, a TestFlight round, submission, and seeing it through review.
Building an app and releasing an app are two different jobs. Plenty of teams have a working app and then get stuck in a process that has nothing to do with writing code: certificates, privacy declarations, screenshots in device sizes nobody owns, and a review whose rejection points at a guideline rather than a line of code.
We take that part over. Store listing and signing, privacy declarations that match what the app genuinely does, a testing round on real devices, and the submission itself including seeing it through review — until the app is approved and you know how the next release works.
We start by looking at how far your app actually is — and what is genuinely still missing before submission.
What you get
Through review, not just submitted
A submission is not a release. We handle rejections, answer reviewer questions and resubmit until the app is actually approved.
Privacy declarations that match the app
What you declare in the store has to match what the app really does — including the privacy manifest and a reachable privacy policy.
Tested before customers see it
A TestFlight round on real devices with real testers, rather than publishing straight to the public.
Who this is for
Teams with a finished app and no release experience
When development is done but nobody has been through the store process before.
Apps that have been rejected
When the submission came back and it is unclear what specifically has to change.
Agencies without their own mobile team
When you keep the client relationship and want the submission handled in the background.
Existing apps under new ownership
When accounts, certificates and access have to be taken over and made release-ready again.
The app is finished — and has been sitting still for weeks
Building and releasing are two different disciplines. Plenty of teams have a working app and then get stuck in a process that has nothing to do with writing code.
Rejected without knowing why
The review response is short and points at a guideline. What specifically needs to change is rarely in it.
Guessing at privacy declarations
The store's questions about data collection and tracking can only be answered if someone knows what the app and its SDKs actually send.
Certificates and profiles
Signing, bundle identifiers, provisioning profiles and expiry dates are a world of their own — and reliably block the upload.
Metadata and screenshots
Every device size needs its own screenshots, every language its own text. Anything missing blocks the submission.
Nobody has seen it on a real device
Everything runs in the simulator. On an actual phone, with an actual connection and actual permissions, it often looks different.
The date is getting closer
Review takes time, and a rejection costs another round. Plan without a buffer and the announcement moves.
We will tell you honestly what is still missing before submission.
What we handle
Scope depends on how far your app and your accounts already are. These are the building blocks.
App Store Connect and Play Console
Setting up the listing, bundle identifier, categories, age rating and country availability.
Signing and certificates
Certificates, provisioning profiles and upload keys set up and documented, so the next release does not stall on them again.
Privacy declarations
Data-collection and tracking answers based on what the app and its SDKs genuinely do — including the privacy manifest on Apple's side.
Getting the privacy policy live
Both stores require a publicly reachable privacy policy at the time of review. We make sure the URL is up and matches the app.
Screenshots and store copy
Screenshots in the required device sizes, title, subtitle, description and keywords — in several languages if you want them.
TestFlight and closed testing
A testing round on real devices before the app goes public, with feedback coming back collected rather than as scattered messages.
Submission and review support
We submit, answer reviewer questions and work through rejections until approval comes.
Staged rollout
The release goes out gradually, so a problem does not reach every user at once.
After taking stock it is clear which of these are actually open in your case.
What we do not handle
So the scope is clear — these are separate things:
Building the app itself
This service assumes a working app. If development is still needed, that is a development project.
App marketing
We get the app into the store. Campaigns, ads and reach afterwards are something else.
Legal advice
We implement what your privacy policy says and answer the store questions accordingly. Whether your policy is adequate is for your legal advisers to judge.
Promising approval
The store decides approval. What we can do is clear the known rejection reasons beforehand.
How it works
Take stock
We review the app, the accounts and the certificates, and establish what is missing before submission.
Build the listing
Listing, categories, age rating and availability get created; screenshots and copy get prepared.
Settle the privacy declarations
We work through what the app and its SDKs actually process, and answer the store questions from that.
Testing round
A build goes to real testers on real devices. Feedback is collected and worked in.
Submit and see it through
We submit and stay on it until the app is approved, including fixing whatever a rejection names.
Rollout and handover
The release goes out in stages. Afterwards you get documentation of where the access sits and how the next release works.
You will know in advance which access we need and where your team is involved.
Why support around the release is worth it
The effort is not in the upload but in the rounds before and after it:
Fewer review rounds
The common rejection reasons are known. Cleared beforehand, they do not cost an extra week each.
A date you can plan around
Knowing what review needs means an announcement can be scheduled rather than postponed.
Declarations that hold up later
Privacy answers that match the app do not have to be reinvented at the next update.
The next release is faster
Access, certificates and process end up documented rather than living in one person's head.
Frequently asked
We do not have a developer account yet. Is that a problem?
No, that is a normal part of the project. Both stores require an account in your own name or your company's — it belongs to you and it should. We guide the setup and then work with the access you give us.
How long does a release take?
It depends on the state of the app and on a review process we do not control. More honest than a promise: after taking stock we tell you what is missing, and we plan a rejection round in as a buffer rather than pretending it never happens.
Can you guarantee our app gets approved?
No, and nobody should promise that. The store decides. What we can do is clear the known rejection reasons in advance and fix things quickly if a rejection does come.
What is a privacy manifest?
A file in the app bundle stating which data the app and its bundled libraries use, and why certain system APIs are called. Apple requires it for new submissions. We write it to match what your app genuinely does.
Do we really need a privacy policy online?
Yes. Both stores require a publicly reachable address, and already at the time of review. A page that only goes live at launch is a common and entirely avoidable rejection reason.
Do you do Android as well, or only iOS?
Both. The processes differ — Play Console rather than App Store Connect, the data safety form rather than Apple's questions — but the effort is comparable and we handle both sides.
Who owns the app at the end?
You do. The developer account is in your name, the listing is yours, and the access sits with you. We work inside it, not beside it.
Our app was already rejected. Can you pick it up from there?
Yes, that is a common starting point. We read the response, translate it into concrete changes and work through them. Often it comes down to privacy declarations, missing test credentials for the reviewers, or features the reviewer could not reach.
What is a staged rollout?
The release reaches only a portion of users first and is then widened. If a problem shows up it does not hit everyone at once — particularly worth doing on a first release and on larger updates.
Can you produce the screenshots?
Yes. Screenshots in the required device sizes are part of it, with frames and captions if you want them, and in several languages.
Your app is finished but still not out?
Send us a short note on what is built and where it is stuck. We will tell you what is missing before submission and what the path to approval looks like.
