[mirzemehdi]

The previous design stored signing material on a match-certificates branch of each app's own repo. That is wrong, and it fails hard at the fourth app.

Why

• An iOS distribution certificate belongs to the Apple Developer account, not to an app. Apple issues at most three.
• A provisioning profile is the per-app piece — it binds one bundle ID to that shared certificate.

match mints a new certificate whenever its store has none. A per-app store therefore means: app 1 creates cert #1, app 2 creates cert #2, app 3 creates cert #3, app 4 cannot ship at all. It also wasted the cap — three identical certificates doing one certificate's job — and left the encrypted material inside app repos whose visibility the user may not control.

Now

One private repo per account, default <owner>/apple-certificates, created automatically:

certs/distribution/ABC123.p12                       ← shared by every app
profiles/appstore/AppStore_com.example.first.mobileprovision
profiles/appstore/AppStore_com.example.second.mobileprovision

• Configurable per user — --certs-repo, remembered as iosCertsRepo. Nothing is hardcoded to any particular org, so anyone using KAppMaker points it at their own.
• MATCH_PASSWORD is keyed to the store, not the app; all apps sharing it need the same passphrase.
• Reaching a second private repo needs a PAT (iosCertsRepoToken) — the runner's built-in GITHUB_TOKEN only reaches its own repo. Set once, reused by every app, and the checklist explains it rather than letting the build fail at match with a confusing clone error.
• The store is private, so certificates are never exposed regardless of app-repo visibility — strictly better than the previous branch approach.

For users whose apps share a GitHub organisation, the account-level secrets are noted as good candidates for organisation secrets, leaving a new app to set only its own build keys.

Workflow stamp → v4, so existing projects pick this up on the next ios-ci init.

CLI 1.22.0, plugin 2.8.0.