The iOS Keychain is where your app keeps its secrets, tokens, credentials, keys, and by default each app's Keychain items are private to it. But sometimes you genuinely need to share a secret: an app and its extension, or a suite of apps from the same developer that should share a login. Keychain access groups are how iOS lets you do that, in a controlled way that still keeps your secrets away from other developers' apps. The thing to get right is scope: anything you put in a shared group is reachable by every app in that group, so sharing should be deliberate and minimal. Here is how Keychain access groups work and how to use them securely.
Short answer
A Keychain access group is a label that determines which apps can share a Keychain item. Per Apple, apps from the same development team can share Keychain items by placing them in a common access group, declared through the keychain-access-groups entitlement, while by default each app's items are in its own private group that other apps cannot read. The team identifier prefix ensures only your own apps can join a group, so another developer's app cannot. Because every app in a shared group can read the items in it, the guidance is to share only the secrets that genuinely need sharing, scope the group narrowly, and combine it with appropriate item accessibility. Share deliberately, not by default.
What you should know
- Access groups control Keychain sharing: which apps can read an item.
- Default items are private: each app's Keychain items are its own.
- Same-team apps can share: via a common
keychain-access-groupsentitlement. - Only your apps can join: the team identifier prefix enforces this.
- Shared items are readable by all in the group: so share narrowly.
What are Keychain access groups?
They are the mechanism that decides which apps a Keychain item is shared with. Every Keychain item belongs to an access group, and an app can access items in the groups it is entitled to. By default, an app's items go into its own private access group, derived from its identity, that no other app can read, which is why Keychain secrets are isolated per app out of the box. To share items, apps declare a common access group through the keychain-access-groups entitlement, and items stored in that group become readable by every app that has the same group entitled. Crucially, access groups are prefixed by your team identifier, so only apps signed by the same development team can share a group, an app from another developer cannot join yours, which is what keeps the sharing contained to your own apps. This is distinct from App Groups, which share a file container and preferences; Keychain access groups specifically govern sharing of Keychain items, the secrets, between apps.
How does sharing compare to the default?
The default isolates; a shared group opens access to your own apps. The table contrasts them.
| Aspect | Default group | Shared access group |
|---|---|---|
| Who can read items | Only the owning app | Every app with the group entitled |
| Configuration | Automatic, per app | Declared via keychain-access-groups |
| Scope of exposure | Single app | All apps in the group |
| Cross-developer access | Not possible | Still limited to your team |
| Use case | App-private secrets | App and extensions, or an app suite |
The default behavior is the safe one: items are private to the app, so a secret stored normally is reachable only by that app. A shared access group changes the scope, an item placed there is readable by every app entitled to the group, which is exactly what you want for legitimate sharing, an app and its app extension sharing a token, or a family of your apps sharing a login, but it also means the secret's exposure now spans all those apps. The team prefix keeps that exposure within your own apps, so the question is not whether another developer can read it, they cannot, but whether all of your own apps in the group should have it, which is a decision to make deliberately.
How do you use them securely?
Share only what must be shared, scope narrowly, and protect the items. Keep secrets in the default private group unless you have a concrete need to share them, since the default isolation is the safest state. When you do share, place only the specific items that genuinely need sharing into the access group, rather than putting everything in a shared group for convenience, so the shared surface is as small as possible. Scope the group to the apps that actually need access, and remember that adding an app to the group gives it the shared secrets, so a less-secure or compromised app in your suite widens the exposure of everything in the group. Combine access groups with appropriate item accessibility, restricting items to this-device-only where they should not migrate, and with access control such as requiring authentication, so sharing scope and protection level are both deliberate. Audit which items are in shared groups and which apps are entitled, periodically, to catch sharing that is broader than needed. The principle is that Keychain sharing is an explicit widening of who can read a secret, so do it minimally and protect the shared items at least as well as private ones.
What to watch out for
The first trap is over-sharing, putting more items than necessary into a shared access group for convenience, which widens exposure across all the group's apps; share only what must be shared. The second is forgetting that every app in the group, including a weaker one, can read the shared items, so the group is only as safe as its least-secure member. The third is confusing Keychain access groups with App Groups, which share files and preferences rather than Keychain secrets. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled IPA against OWASP MASVS and surfaces your entitlements and how the app handles Keychain storage, helping you confirm sharing is scoped as intended. The grouping decisions you make in your entitlements.
What to take away
- A Keychain access group determines which apps can read a Keychain item; by default items are private to the app, and same-team apps share by declaring a common group via the
keychain-access-groupsentitlement. - The team identifier prefix ensures only your own apps can join a group, but every app in a shared group can read its items, so sharing widens exposure across those apps.
- Share only the secrets that must be shared, scope the group to the apps that need it, and combine it with appropriate item accessibility and access control.
- Use a pre-submission scan such as PTKD.com to surface your entitlements and Keychain handling, and confirm sharing is as narrow as intended.
