Fastlane

Scripted build, signing and store upload with shared certificate management.

adds it to an existing project · no account needed
Currentas published in v1.5.1

The rule

This is the whole text, exactly as your agent receives it. Nothing is held back for the paid tier.

Signing

  • Signing identities come from match, never from certificates generated per developer.
  • `readonly: true` in CI. Without it a runner can regenerate certificates and invalidate every other machine's.
  • setup_ci at the start of any lane that runs on a fresh runner, or keychain access fails.

Credentials

  • Keystore, .p8 key and Play service account JSON are supplied by CI at runtime. None of them are committed.
  • The match repository is private, and its passphrase lives only in CI secrets.
  • Use an App Store Connect API key, not an Apple ID password — CI cannot answer a 2FA prompt.

Reproducibility

  • Pin fastlane in a Gemfile and commit Gemfile.lock. An unpinned gem update changes release behaviour without a code change.
  • A lane must behave the same locally and in CI. Branching on ENV['CI'] beyond setup_ci usually means the lane is doing too much.

Releases

  • Upload to a beta or internal track and promote deliberately.
  • Increment build numbers automatically — duplicates are rejected after upload.

Never

  • Never commit a signing credential of any kind.
  • Never run a team release from a personal machine; it is unreproducible.

6 formats, one per tool

Each tab is the file that tool actually reads, at the path it actually looks in. Knowing where each one looks is most of the work of supporting it.

.cursor/rules/fastlane.mdchand-written
---
description: Fastlane conventions
globs: ["fastlane/**", "ios/fastlane/**", "android/fastlane/**", "Gemfile"]
alwaysApply: false
---

# Fastlane

## Signing

- Signing identities come from `match`, never from certificates generated per
  developer.
- **`readonly: true` in CI.** Without it a runner can regenerate certificates
  and invalidate every other machine's.
- `setup_ci` at the start of any lane that runs on a fresh runner, or keychain
  access fails.

## Credentials

- Keystore, `.p8` key and Play service account JSON are supplied by CI at
  runtime. None of them are committed.
- The match repository is private, and its passphrase lives only in CI secrets.
- Use an App Store Connect API key, not an Apple ID password — CI cannot answer
  a 2FA prompt.

## Reproducibility

- Pin fastlane in a `Gemfile` and commit `Gemfile.lock`. An unpinned gem update
  changes release behaviour without a code change.
- A lane must behave the same locally and in CI. Branching on `ENV['CI']` beyond
  `setup_ci` usually means the lane is doing too much.

## Releases

- Upload to a beta or internal track and promote deliberately.
- Increment build numbers automatically — duplicates are rejected after upload.

## Never

- Never commit a signing credential of any kind.
- Never run a team release from a personal machine; it is unreproducible.

Hand-written by the module author, frontmatter and all. It is the source the four derived formats are rendered from, so a correction lands here first.

What else this module writes

The rule is one file of several. Selecting Fastlane contributes all of this too — merged with every other module you pick, with conflicts resolved rather than duplicated.

Environment
MATCH_PASSWORDrequiredDecrypts the match certificate repository. CI secrets only.
MATCH_GIT_URLrequiredPrivate repository holding encrypted signing identities.
ASC_KEY_IDrequiredApp Store Connect API key id.
ASC_ISSUER_IDrequiredApp Store Connect issuer id.
ASC_KEY_CONTENTrequiredContents of the `.p8` key. Provided as a CI secret, never a file in git.
PLAY_JSON_KEY_PATHoptionalPath to the Play service account JSON written by CI at runtime.
ANDROID_KEYSTORE_PASSWORDoptionalRelease keystore password. CI secrets only.
Folders
fastlane/

Advisory history

Every time this rule turned out to be wrong, and what we did about it.

No corrections yet

This rule has been accurate since it was published. That is a fact about the rule, not a promise about the future — which is the whole reason this section exists.

Pro tells you the day a correction lands that affects a repo you actually have.

See what Pro adds →

Rules people add alongside this one

needsReact Nativeconflicts withEAS Submit
Put this rule in a real project

The wizard picks the rest of the stack with you, writes all 6 formats, and leaves a manifest so check can tell you when any of it drifts.