fastlane match is the de-facto pattern for sharing iOS signing material across a team. It encrypts certificates, private keys, and provisioning profiles into a private git repo with one shared passphrase, and every developer or CI runner pulls and decrypts on demand. It is free, it works, and most iOS teams use it.
It also has a known set of pain points that show up as a team grows past a couple of developers. This guide is for the teams that have hit those: what match does well, what it does badly, the three categories of alternatives, and a migration playbook to move off match without burning the team's three-certificate cap or breaking releases mid-week.
What match does well
Worth being clear-eyed about, since match's strengths are real:
- Free. No SaaS bill, no procurement cycle.
- Battle-tested. Every iOS team has either used it or knows someone who has.
- Open source. You can read the source and patch your own behavior.
- Self-contained. The signing material lives in a git repo you already control, on infrastructure you already pay for.
- Works on every CI. Any system that can clone git and run `bundle exec fastlane match readonly` is fine.
If a team is small (1-3 developers), ships one App ID, and rotates rarely, match is genuinely the right answer. Most of the rest of this guide is about what happens when one of those assumptions stops holding.
Where match starts to hurt
There are five pain points that show up consistently as a team grows:
One shared passphrase
Every teammate has the same `MATCH_PASSWORD`. Every CI provider has the same one. Onboarding a new engineer means handing it over. Offboarding means rotating it everywhere, plus running `match change_password` and pushing a re-encrypted repo. In practice most teams skip the rotation step, so a contractor or ex-employee who saved the passphrase six months ago can still sign as the team.
The nuke flow is destructive
When the match repo gets into a confused state (profile regeneration loop, certificate cap hit, branch corruption), the documented escape hatch is `fastlane match nuke development` (or distribution). Nuke revokes every certificate match manages, deletes every profile, and rebuilds from scratch. It also breaks every in-flight build using those certificates, including teammates on other branches.
Apple's three-certificate cap
Apple limits each team to three active Apple Distribution certificates. Match's default behavior on first run is to create a new one if it does not find an existing match in the repo. Two issues:
- A teammate running `match appstore --force` on a fresh checkout because they forgot to clone the right branch.
- A CI runner that ran read-write by accident because someone forgot `--readonly`.
- Both of those silently consume one of the three slots, and you only find out the next time you try to rotate.
No audit trail
The git history of the match repo shows when an encrypted file was committed and by whom, but not what the file is, which profile it generated, or which CI job pulled it. When a certificate leak is suspected, reconstructing 'who pulled signing material, when, and for what build' is a multi-day exercise.
Profile and capability drift
Match regenerates profiles by deleting and recreating them. When a teammate enables a new capability in Xcode (push, App Groups, Sign in with Apple), the new entitlement makes it into the .entitlements file but the App ID's capability set in the Apple Developer portal may not be updated, or the regeneration may pick up the new entitlement only after the next match run. Builds compile, install, and then silently fail to use the capability in production.
The three categories of alternatives
Category 1: managed code signing services
Services like HexSign (and a small set of others) replace the encrypted git repo with a hosted vault. Signing material is encrypted at rest with a key the team controls, audit logs cover every download, certificates rotate without the cap problem, and a CLI or fastlane plugin handles the keychain plumbing on CI. The trade-off is a SaaS bill in exchange for the operational ergonomics of a managed service. See the comparison page for HexSign vs match and other tools side-by-side.
Category 2: secret managers + scripts
1Password, HashiCorp Vault, AWS Secrets Manager, Doppler, or Infisical can store base64-encoded .p12s plus passwords and your CI pulls them on each build. This pattern works when there is a dedicated platform engineer who owns the scripts that fetch + import + sign. It loses match's automation (no certificate-and-profile creation, no rotation; you do those yourself in the Apple Developer portal), and the audit trail is whatever the secret manager gives you.
Category 3: roll-your-own with Xcode Cloud or EAS
Xcode Cloud handles iOS signing automatically: it generates certificates and profiles, stores them with Apple, and uses them inside the Xcode Cloud build. EAS Build (Expo) does something similar for React Native. Both work if you adopt the surrounding build platform whole. Neither helps if you have to keep using GitHub Actions, Bitrise, or your own infrastructure for builds.
Side-by-side comparison
| fastlane match | Managed service (HexSign) | Secret manager + scripts | |
|---|---|---|---|
| Cost | Free | SaaS subscription | Secret-manager bill |
| Per-user auth | Shared passphrase | Per-user account + SSO | Per-user secret access |
| Audit log | git history | Per-action audit log | Secret-manager log |
| Rotation | match nuke (destructive) | In-place against stored CSR | Manual in Apple portal |
| 3-cert cap | Easy to hit | Tracked; rotation doesn't consume | Tracked; rotation manual |
| Onboarding cost | Share passphrase | Add to org, assign role | Grant secret access |
| CI integration | fastlane match command | CLI, GitHub Action, Bitrise Step, etc. | Hand-rolled script per CI |
| Multi-team / multi-app | One repo per team | Native multi-team support | Custom secret namespaces |
| Vendor lock-in | None (open source) | Switching cost | None |
A migration playbook that doesn't break releases
Whichever alternative you pick, the migration follows the same shape. Pick a low-traffic week, follow the steps in order, and do not delete match material until you have shipped at least one release from the new path.
- 1
Inventory what match currently manages
Run `fastlane match readonly` and grep the output for every certificate and profile match would touch. Note the App IDs, Team IDs, and distribution types. This is the surface the new path has to cover.
- 2
Connect Apple to the new tool
Whichever path you pick, the new tool needs read access to your Apple Developer account. For managed services this is an App Store Connect API key. For secret managers this is whatever credential your script uses (typically the same API key). Hand it over and run an initial sync.
- 3
Run the new tool in parallel with match
Don't disconnect match yet. The new tool either reads the same certificates and profiles match created (in which case the team's three-certificate cap is unaffected) or it issues parallel material that you can switch to gradually.
- 4
Cut over CI one pipeline at a time
On a single CI pipeline (e.g. a low-traffic preview-app build), swap `match` for the new tool's command. Ship a build end-to-end and confirm everything signs, archives, and uploads cleanly. Then do the next pipeline. Don't try to cut all of CI in one PR.
- 5
Cut over developer Macs
Update the team's onboarding doc to point at the new tool. New teammates skip match entirely. Existing teammates can keep running `match readonly` on their Macs while they finish current branches, then switch.
- 6
Decommission match
After you have shipped at least one release from the new path and confirmed every CI pipeline is on it, archive the match repo (don't delete it, in case you need to read the history later) and stop running `match nuke` or `match generate`. The certificates and profiles match created keep working until they expire or you revoke them.
How HexSign positions against match
Worth being explicit since you are reading this on the HexSign site:
- Per-user roles instead of one shared passphrase. SSO and audit logs are first-class.
- Rotation against a stored CSR, so the new certificate has the same public key and dependent profiles keep working.
- The three-certificate cap is tracked in the dashboard; rotation never consumes a slot.
- A drop-in fastlane plugin so you can keep your existing Fastfile.
- GitHub Action, Bitrise Step, CircleCI orb, and GitLab CI/CD component for first-class CI integration.
- Free trial, then a per-team subscription. See pricing for the full plans.
Where to go next
- The signing fundamentals: iOS code signing: the complete guide.
- How signing actually runs on CI: Apple code signing in CI/CD.
- fastlane match vs HexSign side-by-side: compare/fastlane-match.