A release that ships itself
from a merged commit to both stores
Shipping a mobile app update manually means someone remembers the version bump, builds locally, generates screenshots, and clicks through two different console UIs hoping neither rejects it for a reason unrelated to the actual code change. A release pipeline automates the parts that do not need a human: build, version, sign, and submit, so a human's attention goes to the one decision that actually matters, is this build ready to ship.
What it is
An app store release pipeline automates the mechanical steps between a code change being ready and it being live on the App Store and Google Play: building the app, bumping its version and build numbers, signing it with the correct certificates, generating or attaching the right metadata, and submitting it for review, triggered by a merge to a release branch rather than a person manually running through both platforms’ consoles.
When you need it (and when you do not)
It earns its cost the moment releases happen often enough, or involve enough people, that manual steps become a real source of delay or mistakes: a wrong version number, an expired signing certificate nobody renewed in time, screenshots that do not match the current build. TaskWall and a fitness app we built both ship regular updates across both platforms, where a reliable, repeatable pipeline matters more than it would for an app updated twice a year.
It is the wrong tool, or at least premature investment, for a brand-new app that has not shipped its first version yet; the manual process for a first submission is worth doing by hand once to actually understand the platforms’ requirements before automating around them. We usually recommend building the pipeline right after the first manual release, once the team has felt where the friction actually is.
How we build it
We set up a CI/CD pipeline, Fastlane orchestrating the app-specific steps inside GitHub Actions, Bitrise, or whatever CI system your team already uses, triggered on a merge to the release branch. Version and build numbers bump automatically based on a convention (semantic versioning tied to the branch or tag) rather than a person editing a plist or gradle file and occasionally forgetting, which is a surprisingly common source of rejected or stuck submissions.
Code signing is the part most manual processes get dangerously informal about: a certificate sitting on one developer’s laptop is a single point of failure and a real security exposure if that machine is ever compromised. We set up centralized, encrypted certificate management, Fastlane Match or an equivalent, so signing works from CI without any certificate living on a personal machine.
Where feasible, screenshot generation is automated across the device sizes each store requires, pulled from the actual current build rather than screenshots someone took months ago that no longer match the UI. Release notes get pulled from commits or a maintained changelog rather than written from memory during submission, and staged rollout, releasing to a percentage of users first, or through an internal testing track, is configured so a bad release reaches a small group before it reaches everyone, with a documented rollback plan for when that is exactly what happens.
What to watch
A pipeline is not a replacement for human judgment about whether a build is actually ready; we build in an explicit manual approval step before submission, automating everything up to that decision rather than past it, since nobody wants a broken build auto-submitted to both stores at 2 a.m. Platform review itself cannot be automated away, both stores can still reject a build for reasons unrelated to the pipeline, policy violations, missing disclosures, and the pipeline’s job is to make sure the build that reaches review is correct, not to guarantee the review passes. Signing certificates and provisioning profiles do expire on a schedule; we set calendar reminders or automated expiry checks so a renewal does not become a surprise the week of an important release.
Price and timeline
| Option | Price | What it covers | Timeline |
|---|---|---|---|
| Core pipeline | from $1,800 | Automated build, versioning, signing, submission to one or both stores | 1 to 2 weeks |
| Full pipeline with staged rollout | from $3,200 | Everything above plus automated screenshots and staged rollout configuration | 2 to 3 weeks |
Running cost is the CI system’s usage-based pricing, typically $0 to $50 a month for a normal release cadence.
Related
This pairs with in-app subscriptions (App Store, Google Play) and deep links and app indexing as the other platform-specific infrastructure most mobile apps need. See the development service page for our full build process. For real examples, see TaskWall’s release process and the fitness app’s regular update cadence.
Still releasing updates by clicking through two app store consoles by hand? Get in touch and we will set up a pipeline around your actual release process.
FAQ
How much does a release pipeline cost?
From $1,800 for automated builds, versioning and submission to one or both stores on an existing app, 1 to 3 weeks. Adding automated screenshot generation and staged rollout configuration runs $2,500 to $4,000.
What is Fastlane and do we need it specifically?
Fastlane is the most widely used tool for automating iOS and Android build, signing and submission steps, and it is usually our default since it has the most mature support for both app stores' quirks. We use GitHub Actions, Bitrise or another CI system depending on what your team already runs, with Fastlane handling the app-specific steps inside whichever pipeline we build.
What about code signing certificates, aren't those sensitive?
Yes, which is exactly why we set up certificate management through a secure, shared system (Fastlane Match or an equivalent) rather than a certificate file living on one developer's laptop, a setup that breaks the moment that developer is unavailable and is a real security risk if the laptop is ever compromised.
Does automating this mean releases skip review?
No, the pipeline automates everything up to and including submission; both platforms still run their own review process on the build, which we cannot and should not bypass. What the pipeline removes is the manual, error-prone work of getting a correct, properly signed, properly versioned build to the point of submission.
Who owns the pipeline?
You. The pipeline configuration lives in your repository, the signing credentials in your own secure storage, and your App Store Connect and Google Play Console accounts remain yours, with documentation so your team can run or modify the pipeline without us.