A guide to hiring Fastlane developers
Releasing a mobile app involves many small jobs. Someone builds the app, signs it, runs the tests, sends a beta, writes release notes, uploads screenshots and fills in the store forms. Done by hand, this takes hours, and a missed step can mean a rejected build. Fastlane is an open-source tool that lets a team write those jobs down as code and run them with one command. A Fastlane developer builds and looks after that setup. This guide explains what the role covers, how it differs from nearby roles, and how to hire someone who leaves you with a release process the whole team understands.
Where this role fits
If you need new features in your app, you want an iOS developer or an Android developer. If you want servers, cloud and monitoring set up, look at a DevOps engineer. A Fastlane developer sits between the two. They know enough about mobile apps to build and sign them, and enough about pipelines to make the steps run on their own. Teams that ship on both Apple and Android devices often get the most out of this role, because one set of habits covers both stores.
Signs you may need one
- Only one person on the team knows how to make a release.
- Releases are done on a single laptop, and nobody wants to touch it.
- Signing errors keep returning, or certificates expire without warning.
- Beta builds are sent late because the steps take half a day.
- Store text and screenshots are copied by hand for every release.
- You want a release every week, but the process makes that hard.
What a lane looks like
A lane is a named list of steps. A beta lane might bump the build number, sign the app, build it, run the tests and send it to testers. A release lane might do the same, then upload the build and the store text for review. Each step is a small action, and the lanes live in a file in your repository, so they are reviewed, versioned and shared like any other code. Good lanes are short and plain. Anyone on the team should be able to read one and say what it does.
Signing, keys and secrets
Signing is where most mobile pipelines fail first. Apple builds need certificates and provisioning profiles, and Android builds need a keystore and its passwords. A good setup keeps these in one protected place, gives the build service only the access it needs, and keeps passwords and keys out of the repository. Your developer should write down who owns each key and what happens if one is lost. The store accounts themselves should be registered to your company, not to a contractor.
Working with your build service
Most teams run their lanes on a build service such as GitHub Actions or Bitrise. The service decides when a job runs, and Fastlane holds the steps. This split keeps the steps readable and lets you change service later without rewriting them. A careful developer also thinks about build time, caching and the cost of the machines, because Apple builds need Mac hardware and can be slow and costly if they are not set up well.
What to decide before you hire
- Which apps and platforms the pipeline must cover.
- Where the builds will run, and who pays for the machines.
- Who owns the Apple and Google developer accounts.
- How often you want to release, and who approves each release.
- Whether the developer also fixes app bugs, or only looks after the pipeline.
Interview questions to try
- Walk us through the lanes you would write for a weekly beta and a monthly store release.
- How do you share signing files across a team without sending them in chat?
- A release build fails only on the build server. How do you find out why?
- How do you keep the Fastfile readable as the app grows?
- Tell us about a time a store change broke a pipeline. What did you do?
Listen for how they handle failure. A good pipeline is one that is easy to debug at the worst time.
Run a small paid task
Give each finalist a short task on a sample app. Good tasks include writing a beta lane that builds, tests and sends the app to testers, moving a messy shell script into clean lanes, or reviewing your current release steps and listing the risks. The time should be paid. Judge the clarity of the lanes, how secrets are handled and how the person explains the result.
Give them access and a routine
Your developer needs the repositories, the build service and the right level of access to your store accounts. Keep the accounts and keys in your name. Early on, run a release together and watch each step. Later a short written update each week is enough, as long as it states what changed, what was tested and what is next. Our guide to mobile app developers shows how these roles work together on a team.
Mistakes to avoid
- Putting keys or passwords in the repository.
- Giving a contractor the only login to your store accounts.
- Building a long pipeline before the first simple lane works.
- Skipping tests in the lane because they are slow.
- Leaving no notes, so only one person can fix the pipeline.
Planning a wider mobile team? Read about how to hire an iOS developer, an Android developer or a Xamarin developer, and see how hiring works on our pages.