fastlane is a wall of tool directories in one gem, and the manual lives elsewhere

One gem, twenty directories, and a Swift package in the same tree

fastlane is not one program. The repository root holds a directory per tool: cert, deliver, frameit, gym, match, pem, pilot, precheck, produce, scan, screengrab, sigh, snapshot, supply and trainer, with credentials_manager, spaceship, fastlane_core and fastlane sitting alongside them. Every one of those becomes a command you can call, which is why a Fastfile reads like a short script of tool names rather than a program with subcommands.

The tree is not purely Ruby. Package.swift and Package.resolved sit at the root, and the metrics page says fastlane reports how it was executed, Swift versus Ruby, so there are two implementations of the same interface. The project also ships a fastlane.gemspec, a Gemfile with a committed Gemfile.lock, a Brewfile, an Rakefile, spec/ with .rspec, and .rubocop.yml next to .rubocop_todo.yml, which tells you the release tooling is linted and tested on the same rules it asks contributors to follow.

The description is one sentence: automating tedious tasks like generating screenshots, dealing with provisioning profiles, and releasing your application.

Every document moved to docs.fastlane.tools, so the README is a support form

The README states twice, in a banner, that all fastlane docs were moved to docs.fastlane.tools. What remains in the repository file is a help section, a team table, a metrics section and a licence note. There is no install command, no Fastfile example, no action reference, and no list of what the twenty tool directories do.

That has a direct effect on a reader. If you arrived from the homepage at fastlane.tools, the path to a working setup runs through a website, not through a file you can grep. The repository itself never shows what a lane looks like or which options a tool accepts, so a team that wants its release process reviewable in the same repository as its app will be reading docs.fastlane.tools and writing the result into a Fastfile by hand.

The one place the README does name a command is diagnostic. Before opening an issue it asks for the output of the fastlane env command, which is the project's own answer to what to attach to a bug report.

Issue triage runs on one command and one title prefix

Two conventions shape how fastlane handles problems, and both are enforced socially rather than by code. The first is that every new issue is expected to come with the output of the fastlane env command, alongside a description of the setup. Without it, the maintainers are asking you to rebuild their environment before they can read yours.

The second is narrower. To report something that worked in an earlier release and broke in a newer one, the issue title has to start with the exact marker [Regression] Your title here. The README says this enables the project to quickly detect and fix regressions, which is a routing signal: it is there so a broken upgrade is separated from a feature request and a configuration mistake.

Both conventions cost a newcomer very little and save the maintainers a round trip. The catch for a reader is that neither convention is enforced by the tool. Nothing in a Fastfile fails a build because a lane skips a diagnostic, and no linter in the repository checks that an issue was written in the expected shape.

Nine metrics by default, and two ways to switch them off

The metrics section is the most specific part of the README, and it enumerates what is collected on every run: the number of fastlane runs, a salted hash of the app identifier or package name that identifies unique usage anonymously, how fastlane was executed (Swift vs Ruby), the fastlane version, how fastlane was installed (Homebrew, gem, bundler, etc), the Ruby version, the operating system in use, the Xcode version, and whether the run was non-interactive or interactive.

Read that list as an organisation administrator would. It names the Xcode version and the operating system on machines that hold signing credentials, and the project says no personal or sensitive information is ever collected. Turning it off takes one of two actions: add opt_out_usage at the top of your Fastfile, or set the environment variable FASTLANE_OPT_OUT_USAGE. The implementation sits in fastlane_core/lib/fastlane_core/analytics, linked from the README, so the behaviour can be read rather than trusted.

For a company that scans for telemetry, that path is the whole conversation. Nothing else in the repository asks for consent.

Credentials stay on your machine, and Apple is not involved

The licence note carries the security argument and the disclaimer in one paragraph. The project is MIT licensed, which the README says means full access to the source code and the freedom to modify it. It states that all fastlane tools run on your own computer or server, so credentials or other sensitive information never leave your own computer. And it says plainly that the project and all its tools are in no way affiliated with Apple Inc.

That last sentence matters more than it looks. Tools like cert, sigh, match and pem exist to deal with provisioning profiles and signing assets, the exact material an App Store review or a security audit asks about. The claim to check is therefore mechanical rather than reputational: on your machine, which key and which profile does the lane actually use, and where does it write them.

The README leaves that to you. It does not document a keychain path, a default profile location, or a way to make a lane refuse to read a credential from somewhere unexpected.

Homebrew, gem or bundler, and the install method is itself a metric

The README has no install command, but it does point at the two places the gem is published: the rubygems.org page for fastlane and the Homebrew formula. The metrics list names the third route when it asks how fastlane was installed, listing Homebrew, gem, bundler and similar, and the repository commits both a Gemfile.lock and a Brewfile, so a project that uses bundler is reproducing exact versions while a Homebrew install floats on the formula.

The release numbers explain why that choice is not academic. The three most recent releases are 2.239.0 on 2026-09-04, 2.240.0 on 2026-09-14 and 2.240.1 on 2026-09-15, and the last push to master was on 2026-09-29. Patch versions land on their own, so a floating install can change underneath a build that nobody edited.

There is also a changelog with a name that matters: CHANGELOG.latest.md, not CHANGELOG.md. Read it before pinning, because a 2.240.x upgrade can change behaviour in a tool directory you did not know you were calling.

The alternative is xcodebuild and the App Store Connect API with no DSL in between

fastlane is not the only way to automate a release, and the honest comparison is not feature by feature. The alternative most teams start from is calling xcodebuild and Apple's own upload tooling directly from a shell script or a CI job. That approach has no DSL, no Fastfile, and no shared vocabulary, so each engineer writes their own steps and each script diverges. The trade runs the other way: nothing enforces a convention, and nothing in the repository asks a machine for its Xcode version.

Choosing fastlane buys you the twenty tool directories as named commands and a config file you can review and diff. It costs you a Ruby runtime, a gem to version, and a telemetry default that has to be switched off deliberately if your policy forbids it.

Neither approach is verified by the README, which makes no comparison and offers no migration notes. The first thing to check before committing is the one fact fastlane states about itself: the tools run on your own machine, which is the property your security review will actually test.

Editorial conclusion

fastlane fits iOS and Android teams that want one shared vocabulary for signing, screenshots and store uploads across every developer's machine, and it does not fit a team that wants its release steps to live in version control without a telemetry default. Verify first that you have settled the metrics question, by putting opt_out_usage at the top of your Fastfile or exporting FASTLANE_OPT_OUT_USAGE, and read CHANGELOG.latest.md before pinning a 2.240.x build.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes