A release that ships itself
from a merged commit to both stores
Shipping a mobile app update by hand means someone remembers the version bump, builds locally, generates screenshots, and clicks through two different console UIs. Each one might reject 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. A human's attention goes to the one decision that actually matters: is this build ready to ship.
What this pipeline actually automates
An app store release pipeline automates the mechanical steps between a code change being ready and it going 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. Submitting it for review.
All of it triggers from a merge to a release branch, instead of a person manually running through both platforms’ consoles.
When manual releasing starts costing you
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. A reliable, repeatable pipeline matters more there than it would for an app updated twice a year.
It is the wrong tool, or at least a 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 triggered on a merge to the release branch. Fastlane orchestrates the app-specific steps inside GitHub Actions, Bitrise, or whatever CI system your team already uses. Version and build numbers bump automatically based on a convention, semantic versioning tied to the branch or tag. Nobody has to edit a plist or gradle file by hand and occasionally forget, 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. It pulls from the actual current build, not screenshots someone took months ago that no longer match the UI. Release notes get pulled from commits or a maintained changelog, not written from memory during submission.
Staged rollout is configured so a bad release reaches a small group before it reaches everyone: a percentage of users first, or an internal testing track. We document a 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, not past it. 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. 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.
What it costs
| 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.
Where this connects
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. 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. That is exactly why we manage certificates through a secure, shared system instead, Fastlane Match or an equivalent. A certificate file on one developer's laptop breaks the moment that person is unavailable. It is also 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, and the signing credentials live in your own secure storage. Your App Store Connect and Google Play Console accounts remain yours. We hand over documentation so your team can run or modify the pipeline without us.