What problem does fastlane's match (sync_code_signing) solve for iOS code signing?

## Why iOS code signing is shared team state Every iOS build must be signed before a device or the App Store will accept it, and signing needs three things present on the machine that runs the build: a **private key**, the **Apple-issued certificate** that names that key, and a **provisioning profile** binding the certificate, the app's bundle identifier and — for anything distributed outside the App Store — a list of registered devices. None of it lives in the application repository, and the private key cannot be regenerated: lose it and the certificate that names it is scrap. Left to per-machine automation, every laptop enrols its own certificate. Six engineers on the falconry weight-log app end up holding six distribution identities against a quota that is deliberately small, a drawer of profiles nobody can reproduce, and a CI runner that begins each job with an empty keychain and cannot sign at all. The certificate on whichever machine happened to cut the last release becomes load-bearing, undocumented state. ## What sync_code_signing actually does `match` is the nickname; **`sync_code_signing`** is the canonical fastlane action, and the canonical name is worth using because it describes the behaviour: this is a *sync*, not a per-machine generator. A run does the following. 1. **Opens the storage backend** named by `storage_mode` — one of `git`, `google_cloud`, `s3` or `gitlab_secure_files`. With Git that means cloning `git_url`, optionally at `git_branch` and with `shallow_clone`. 2. **Decrypts the contents.** match encrypts client side with **OpenSSL**, so the backend only ever holds ciphertext and the passphrase is what turns it back into usable keys. 3. **Looks for assets matching `app_identifier` and `type`.** If they exist it installs them. If they do not, and the run is not `readonly`, it creates them through the Apple Developer Portal and writes the new material back, encrypted. 4. **Installs what it found.** The private key and certificate go into a keychain — `keychain_name` and `keychain_password` select and unlock it — and the provisioning profiles are written where Xcode expects them. 5. **Publishes the result into the lane context**, including `SharedValues::MATCH_PROVISIONING_PROFILE_MAPPING`, so the later export step can map each target to the profile it should use. The outcome is the property the tool exists for: your laptop and the CI runner install the *same* identity instead of each inventing one. ## Assets are keyed by app_identifier and type The repository is not one undifferentiated blob. Material is filed by the app it belongs to (`app_identifier`) and by what it is for (`type`), and `type` is a closed list of seven values: - `appstore` — the distribution identity for builds destined for App Store Connect. - `adhoc` — distribution to a fixed list of registered devices, so this is the profile that goes stale the moment a tester's iPhone is added. - `development` — everyday builds onto developers' own devices. - `enterprise` — in-house distribution outside the store. - `developer_id`, `mac_installer_distribution` and `developer_id_installer` — the macOS side of the family. One repository can therefore hold the weight-log app's `appstore` and `adhoc` material side by side, and other apps' material alongside it, without collisions. ## iOS and Android are not symmetric here This is the part candidates most often get wrong, because fastlane itself is cross-platform while this tool is not. | | iOS / Apple | Android | |---|---|---| | identity | private key plus an Apple-issued certificate | private key inside a keystore file | | extra artefact | provisioning profile, bound to bundle id and devices | none; there is no per-device profile | | issuing authority | the Apple Developer Portal, which can revoke | you, self-signed, with nobody to revoke it | | kept in sync by match | yes — this is the whole job | no | | where it is configured | the signing lane, consumed by the export step | the Gradle build's signing configuration | The divergence is not an omission. Android has no portal-issued certificate and no per-device profile to reconcile, so there is nothing for a sync tool to reconcile; the keystore is a single file whose handling belongs to the Android build configuration rather than to `sync_code_signing`. ## Where match's job ends - It does not build or export. The export step consumes the profile match installed and produces the artifact. - It does not upload anything to a store or a beta service. - It does not decide where the encryption passphrase or the backend credentials live in your pipeline; that is a CI secrets question, not a match option. Knowing those edges is most of the value of this answer in an interview: match owns the *identity*, and everything downstream merely consumes it.