In many companies, releasing a mobile app looks like this: one specific person opens their laptop, bumps the version number, builds the release version, signs it with a key only they have, uploads it to TestFlight and Google Play, pastes in the release notes and waits. Half a day of a senior developer's time — with two platforms, sometimes a whole day.
As long as that person is in the company and has time, everything works. The problem starts on the day an urgent fix has to go out and they're on holiday, have changed laptops or no longer work for you.
Release automation isn't a whim of the tech team. It's the cheapest thing you can do to make releases stop being an event and become a routine. Below: what exactly can be automated, how much it costs, when it pays off and where to start if the budget is limited.
What a manual release really costs
Let's count what goes into a single manual release on Android and iOS:
- bumping the version name and version code in two projects,
- building the release version and signing it,
- uploading the packages to TestFlight and Google Play,
- filling in the release notes in two stores, sometimes in several languages,
- handing the version over to testers and collecting feedback,
- submitting for review, watching the status, starting the staged rollout,
- tagging the version in the repository and checking crash reports after the release.
In a well-organised project, that's around 3–5 hours. In a project where something along the way doesn't work — an expired certificate, a changed store requirement, a data form that doesn't match — it can take two days.
On top of that come costs you won't see on an invoice:
- Only one person can release the app. A classic single point of failure. When they're on holiday or leave, releases stop.
- Keys and certificates on a personal laptop. Losing the keystore of an Android app without Google's app signing enabled means you can no longer release updates to that app — only a new one, under a new identifier, without your existing users.
- Manual errors. The wrong configuration, outdated release notes, a version built from the wrong branch.
- Fear of releasing. When releases hurt, the team releases less often, so each release contains more changes and is even riskier. A vicious circle that ends with releases once a quarter.
What can be automated
A release pipeline for a mobile app usually consists of several layers. Each makes sense on its own — you don't have to implement everything at once:
- Building on every change. When a pull request is opened, CI builds the app, and you immediately know whether the project even compiles for anyone other than its author.
- Tests and static analysis. Unit tests, lint, formatting checks. The result is visible in the pull request before anyone starts reviewing the code.
- Signing off the laptop. Certificates and keys kept in the CI secrets vault, not with a specific person.
- Distribution to testers. Automatically sending each new version to TestFlight and to the internal testing track in Google Play after every merge to the main branch.
- Versioning and release notes. Version numbers assigned automatically, the list of changes generated from the repository history or the issue tracker.
- Store submission. Uploading the package, metadata and screenshots and submitting for review with a single command.
- After the release. Tagging the version, uploading debug symbols to the crash monitoring tool, a notification on the company chat.
Points 1–4 give the biggest return relative to the effort, and that's where it's worth starting.
What tools to use
fastlane has been the standard in the mobile world for years — a toolset that describes a release as "lanes" run with a single command. It handles iOS certificates, building, uploading to TestFlight, publishing to Google Play, screenshots and metadata. Its biggest advantage: the same configuration works on a developer's computer and on the CI server, so "works on my machine" stops being an argument.
The CI system that runs it is most often GitHub Actions, GitLab CI or a service specialised in mobile apps, such as Bitrise or Codemagic. For projects fully within the Apple ecosystem, Xcode Cloud is an alternative.
One thing that surprises people when planning the budget: building iOS apps requires a macOS machine. In the cloud it's noticeably more expensive than a regular Linux server and usually billed by the minute. With a few releases a month the cost is small; when building every pull request on a large project it can grow — and then it's worth considering your own machine.
The choice of tool is secondary. What matters is that a release can be done with a single command, without tribal knowledge — whether it's triggered by GitHub Actions or Bitrise is of minor importance.
Signing — where it most often falls apart
If any part of a CI/CD rollout causes trouble, it's almost always this one.
iOS. Certificates and provisioning profiles expire, are tied to the account and tend to drift out of sync between team members. fastlane solves this with a mechanism that keeps encrypted certificates in a shared, private repository used by both CI and developers. For uploading to App Store Connect you use an API key instead of a login and password — that avoids having to deal with two-factor authentication, which is a pain in automation.
Android. The keystore and passwords go into CI secrets, never into the repository. Having Google's app signing (Play App Signing) enabled is a safety net: without it, losing the key means losing the ability to update the app. If you don't know where your keystore is, check today — it's one of the items on our project takeover checklist.
The general rule: secrets in the CI vault, store access on a company account, keys off personal computers.
How much implementation and upkeep cost
Indicative effort for an Android and iOS app, based on projects we've taken over:
- Minimal setup — building and tests on CI, signing off the laptop, automatic distribution to testers: usually 15–25 hours of work.
- Full pipeline — additionally versioning, release notes, metadata, store submission, notifications, crash symbols: usually 40–80 hours, depending on the state of the project and the number of app variants.
- Upkeep — a few hours a quarter. Tools change, certificates expire, stores raise their requirements.
- Infrastructure — from a few dozen to a few hundred PLN a month for a typical project, mainly for macOS machine time.
What affects these numbers most isn't the choice of tool but the state of the project: the version of the build tools, the number of app variants and flavours, how dependencies are managed. In a project that hasn't been updated for three years, the first step isn't CI, it's getting the project to a state where it builds at all — in other words, reactivation.
When it pays off
A simple calculation, with an example rate of PLN 180 net per hour (as in our article on mobile app maintenance cost):
- Two releases a month × 4 hours of manual work = 8 hours a month, i.e. 96 hours a year — around PLN 17k.
- A full pipeline for 60 hours is a one-off of around PLN 11k, plus a few hours a quarter for upkeep.
It pays for itself after roughly eight to ten months, and from the second year on it's pure savings. And that counts time alone, without failed releases, bugs shipped to everyone at once, or weeks of waiting for the only person who can release the app to come back.
With one release a quarter the math doesn't add up, and that needs to be said plainly — more on that below.
When it's not worth automating everything
Automation makes sense in proportion to how often you release. It's not worth building a full pipeline when:
- the app is released once every six months and there are no development plans,
- the product hasn't been validated on the market yet and its shape will change several more times — the money is better spent on features, as we write in our article on MVP scope,
- the app is going to be rewritten in a few months.
But even then, two things are always worth doing, because they protect you from losing the project, not just save time: keys and certificates off personal laptops and a documented, repeatable release procedure. That's a few hours of work, no matter how rarely you release.
Where to start
An order that delivers value after every step:
- Move the secrets. The keystore, passwords, the App Store Connect API key — into the CI vault and the company password manager.
- Build on CI for every pull request. Dependencies that only worked on one computer surface immediately.
- Add tests to the pipeline. Start with what you already have; if you have nothing, start with the most important path in the app.
- Automate distribution to testers. This is the moment the non-technical team first feels the difference: a new version is available within minutes of merging changes.
- Automate store submission together with release notes and metadata.
- Add staged rollout and crash monitoring, so a slip-up doesn't reach all users at once.
Points 1–2 are usually one or two days of work and already eliminate the most serious risks.
How to tell it worked
Four metrics worth checking before the rollout and three months after it:
- Time from merging changes to a version in testers' hands. Target: minutes, not days.
- Number of people who can release the app. Target: anyone on the team, without help from the pipeline's author.
- Share of releases that need a fix right after publishing. Automated tests and staged rollout should bring it down noticeably.
- Time needed to ship an urgent fix. This is the number management will appreciate — because it concerns the day something goes wrong.
If a release still requires a specific person and their laptop, the pipeline is unfinished, no matter how many tasks the automation performs.
Summary
Release automation pays off in projects that release regularly — usually within a year — and regardless of the economics it removes two serious risks: dependence on a single person for releases, and keeping keys somewhere nobody controls. You don't have to start with a full pipeline. Secrets in a vault, building on CI and automatic distribution to testers deliver most of the benefit for a fraction of the effort.
We build and improve release processes, including fastlane and CI/CD setup, as part of mobile app maintenance — most often around our first releases together. If you'd first like to know what state the project is in and how long it would realistically take to put in order, start with an audit or simply get in touch.