fastlane match is still the default way iOS teams share signing material. It encrypts certificates, private keys, and provisioning profiles into a private git repo behind one shared passphrase, and every developer and CI runner pulls and decrypts on demand. It is free, it is open source, and it works.
People start looking for an alternative for reasons that are pretty consistent: one MATCH_PASSWORD that every contractor who ever onboarded still knows, a repo that drifts until somebody runs match nuke and takes three teammates' builds down with it, Apple's three-certificate cap quietly consumed by a CI job that forgot --readonly, and a git history that cannot tell you who pulled signing material or why. None of those are bugs. They are what happens when a shared folder is your identity system.
Below are eight alternatives, in rough order from most CI-coupled to least. For each one: what it actually is, where the signing material lives, whether anything renews it or tells you before it expires, and which build platform you are married to afterwards. HexSign is on the list because this is the HexSign site, and it is last and described the same way as the rest.
1. Appcircle Signing Identities
Appcircle bills itself as an Enterprise-Grade Mobile CI/CD Platform, available in the cloud or fully self-hosted. Its Signing Identities module is the part that competes with match: a central store for certificates and provisioning profiles that supports both automatic and manual signing, can generate certificates and CSRs without a Mac in the loop, registers devices into profiles, covers Development, Ad Hoc, App Store and In-House profile types, and re-signs binaries when a profile changes. It holds ISO 27001 and SOC 2 Type II certification.
- Stores signing material
- Centrally, in Appcircle's Signing Identities module, cloud-hosted or on your own infrastructure if you self-host.
- Renews and alerts
- Alerts, yes: in-app notifications plus optional Email, Slack and Microsoft Teams, on a fixed 30, 15, 7, 3 and 1 day schedule. Renewal is a button, not a schedule. When you press it, Appcircle revokes the old certificate and regenerates the associated profiles for you.
- Ties you to
- The Appcircle platform, more than its builds.
appcircle signing-identity certificate downloadand the matching provisioning-profile command will pull material onto any machine, so this is less of a lock-in than the rest of this section. - Who it suits
- Enterprises that want one vendor for builds and signing, especially where a compliance team is asking for ISO 27001, SOC 2 Type II, or a fully self-hosted deployment.
2. Codemagic automatic code signing
Codemagic is a Flutter-first CI/CD platform whose automatic code signing takes an App Store Connect API key and fetches or creates the certificate and provisioning profile a build needs, at build time. You can also upload a .p12 and a .mobileprovision and reference them by name. It removes the match repo from the equation entirely, which is the point.
- Stores signing material
- In Codemagic's own code signing storage, per team, or generated on the fly from your App Store Connect API key during the build.
- Renews and alerts
- Signing is evaluated when a build runs, so an expiry shows up as a failed build. Revocation is not done inside Codemagic; the docs send you to Apple's Developer Portal. No documented first-party expiry alerts for certificates and profiles.
- Ties you to
- Codemagic. A certificate created outside Codemagic cannot be auto-fetched, because Codemagic does not hold the private key for it.
- Who it suits
- Flutter teams already on Codemagic who want signing to be one line of YAML and never think about it again, on a codebase with one or two bundle IDs.
3. Bitrise managed code signing
Bitrise gives you a Code Signing tab where you upload .p12 certificates and provisioning profiles per app, plus an Automatic Code Signing path that uses an App Store Connect API key to provision what a build needs. Bitrise also publishes codesigndoc, an open-source tool that works out which signing material your Xcode project actually uses.
- Stores signing material
- Per app, in the Bitrise workspace. Each app is capped at 30 combined certificates and provisioning profiles; past that, Bitrise's own docs recommend fastlane match, which is a slightly awkward thing for a match alternative to do.
- Renews and alerts
- Expiration is checked at build time. Bitrise documents build notifications, not certificate expiry alerts, so the notification you get is a red build.
- Ties you to
- The Bitrise workspace. The material is scoped to apps there rather than being a portable identity registry.
- Who it suits
- Teams whose builds already live on Bitrise, with a handful of apps and enough headroom under the 30-asset cap that they will never meet it.
4. Expo EAS managed credentials
For Expo and React Native apps, eas build generates iOS distribution certificates and provisioning profiles on first run, stores them on EAS servers, and reuses them for later builds. eas credentials lets you inspect, modify, or remove what is stored. The useful part is the onboarding story: once credentials exist, a teammate can ship a build without being added to your Apple Developer team at all. There is also a local-credentials mode if you would rather keep the files yourself.
- Stores signing material
- On EAS servers, managed for you.
eas credentialswill download them into credentials.json when you want them locally, and local credentials mode keeps the .p12 and .mobileprovision on disk permanently. - Renews and alerts
- No documented scheduled renewal ahead of expiry and no documented expiry alerts. Apple's one-year clock runs regardless of who is holding the file.
- Ties you to
- EAS builds, and to the React Native and Expo world generally. A native iOS target or a Developer ID build of a companion Mac app is outside that scope.
- Who it suits
- Expo teams who build every release on EAS and have no second target to worry about. If that is you, managed credentials are already a better deal than a match repo.
5. Capawesome Cloud managed signing
Capawesome Cloud is the Capacitor-world answer, and it has picked up a lot of teams since Ionic announced Appflow would be sunset on 31 December 2027. It does over-the-air live updates, native iOS and Android builds, and store publishing, with managed code signing in the middle: you upload a .p12 and its password plus the .mobileprovision files for the app and any extensions, and Capawesome matches them to targets by bundle identifier at build time. There is also a browser-based certificate generator if you would rather not open Keychain Access.
- Stores signing material
- In Capawesome Cloud, per app, as files you uploaded. Android keystores and store credentials (App Store Connect keys, Google Play service accounts) live in the same place.
- Renews and alerts
- Neither is documented. The docs are candid about it: profiles expire after about a year, and if a build fails because of an expired profile you regenerate it and upload the new one.
- Ties you to
- Capawesome Cloud, and to Capacitor, Ionic or Cordova. The CLI has apps:certificates create and update for pushing material in, but no documented command for pulling it back out.
- Who it suits
- Capacitor teams migrating off Appflow who want live updates, builds, and store submission from one vendor with published prices, starting at $19 a month.
6. Xcode Cloud
Xcode Cloud is Apple's own CI, wired into Xcode and App Store Connect. It creates and manages the certificates and provisioning profiles its builds use, so signing inside Xcode Cloud is genuinely a non-event. That convenience is also the whole trade: Apple does not document a way to export that identity and use it somewhere else.
- Stores signing material
- With Apple, managed on your behalf. You do not hold the private key and there is no documented export path.
- Renews and alerts
- Apple renews what its own builds need, automatically and opaquely. It does not renew certificates your other pipelines, Developer ID builds, or local archives use, and there are no documented first-party expiry alerts.
- Ties you to
- Xcode Cloud, plus Apple's Xcode versions and compute-hour billing. Moving to another CI means standing signing up from scratch.
- Who it suits
- Teams shipping a single Apple app whose every release is built in Xcode Cloud, with nobody archiving locally and nothing signed outside it.
7. GitLab Secure Files
This one belongs on the list with an asterisk. GitLab Secure Files is a per-project store for binary files like .p12 certificates and .mobileprovision profiles, and match supports it as a storage backend. So it is not an alternative to match at all: it is an alternative to keeping match's encrypted blobs in a git repo. You still run match, you still have the same commands and the same lifecycle; you just stop having a second repository to manage and stop putting the encrypted material in your history.
- Stores signing material
- In GitLab's per-project Secure Files store, read via the GitLab API rather than cloned. Access follows GitLab project permissions instead of a shared passphrase for the repo itself.
- Renews and alerts
- Neither. Secure Files is storage. Renewal is still
matchand a human, and nothing tells you a certificate is expiring. - Ties you to
- GitLab, for the storage. Builds can still run anywhere that can reach the GitLab API and run fastlane.
- Who it suits
- Teams already on GitLab who are happy with match itself and only want the certificates out of a git repo. It is the smallest possible change on this page.
8. HexSign
HexSign is a hosted dashboard and CLI for the Apple signing lifecycle, and it deliberately does not run builds. It connects to your Apple Developer account with an App Store Connect API key, keeps certificates and private keys in a KMS-encrypted vault, and models the relationships between certificates, profiles, bundle IDs, and devices so you can see what a rotation would break before you do it.
- Stores signing material
- In a KMS-encrypted vault, with per-user Owner, Admin, and Member roles instead of one shared passphrase, and an audit log entry for every certificate, profile, device, and identifier change.
- Renews and alerts
- Both, and this is the reason the product exists. A daily job reissues distribution certificates and rebuilds provisioning profiles 30 days before expiry, rotating against a stored CSR so the new certificate keeps the same public key. Alerts go to email, Slack, Microsoft Teams, Jira, PagerDuty, and incident.io at thresholds you pick. See auto-renew certificates and profiles for the mechanics.
- Ties you to
- HexSign, as a SaaS subscription with a switching cost. Not to a CI: there is a GitHub Action, a Bitrise Step, a CircleCI orb, a GitLab CI/CD component, a fastlane plugin, and a plain binary for everything else.
- Who it suits
- Teams past the point where one person can hold the signing state in their head: several apps, more than one Apple account, contractors rotating on and off, or a release that has already been broken once by something expiring.
Side-by-side comparison
| Option | Signing material lives | Renews before expiry | Expiry alerts | Ties you to |
|---|---|---|---|---|
| fastlane match | Encrypted git repo (or S3, GCS, Secure Files) | No | No | Nothing |
| Appcircle | Appcircle Signing Identities | Manual renew button | In-app, email, Slack, Teams | Appcircle platform |
| Codemagic | Codemagic team storage | No (build-time) | Not documented | Codemagic |
| Bitrise | Bitrise workspace, per app | No (build-time) | Not documented | Bitrise workspace |
| Expo EAS | EAS servers | Not documented | Not documented | EAS builds |
| Capawesome Cloud | Capawesome Cloud, per app | Not documented | Not documented | Capawesome, Capacitor apps |
| Xcode Cloud | Apple, no documented export | For its own builds only | Not documented | Xcode Cloud |
| GitLab Secure Files | GitLab project store | No (still match) | No | GitLab (storage only) |
| HexSign | KMS-encrypted vault | Yes, 30 days out | Email, Slack, Teams, Jira, PagerDuty, incident.io | No CI lock-in |
The pattern in that table is the thing worth taking away, whichever option you pick. Seven of the eight alternatives are storage attached to a build platform, and Appcircle is the only one of those that will tell you before something expires. The rest solve the shared-passphrase problem and leave the calendar problem exactly where match left it: a certificate expires a year after it was issued, and the thing that tells you is a failed release.
A migration playbook that doesn't break releases
Whichever alternative you pick, the migration has the same shape. Pick a quiet week, go in order, and do not delete anything match created until you have shipped a real release from the new path.
- 1
Inventory what match currently manages
Run
fastlane match readonlyand note every certificate and profile it touches, plus the App IDs, Team IDs, and distribution types. That list is the surface the new path has to cover. - 2
Connect the new tool and sync, in parallel
Give the new tool read access to your Apple Developer account, usually an App Store Connect API key, and let it sync. Leave match connected. The new tool should either read the same certificates match created or issue parallel material you can switch to gradually.
- 3
Cut over one pipeline at a time
Start with a low-traffic pipeline, a preview or internal build. Swap the match invocation for the new tool's command, ship end to end, and confirm it signs, archives, and uploads cleanly. Then do the next one. Do not try to move all of CI in a single PR.
- 4
Cut over developer Macs
Point the onboarding doc at the new tool so new teammates skip match entirely. Everyone else can keep running
match readonlyuntil their current branch lands. - 5
Decommission match
After one real release has shipped from the new path and every pipeline is on it, archive the match repo rather than deleting it. The certificates and profiles match created keep working until they expire or you revoke them.
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 and HexSign side by side: compare/fastlane-match.
- Why certificates expire when they do, and what to do about it: Apple certificate expiration.