App Groups are how an iOS app shares data with its extensions, a widget, a share extension, a notification service, through a shared container. They are useful and necessary for those features, and they quietly widen where your data lives. Anything you place in the shared container is reachable by every member of the group, and the shared UserDefaults inside it is no more secure than ordinary UserDefaults. The mistakes are over-sharing sensitive data and treating shared storage as private. Here is what App Groups are and how to share data through them securely.
Short answer
App Groups let multiple apps and app extensions from the same developer share data through a shared container, including shared UserDefaults, a shared file container, and a shared Keychain access group. Per Apple's documentation, the security point is that everything in the shared container is accessible to every member of the group, and shared UserDefaults is unencrypted just like regular UserDefaults, so it is not a place for secrets. Share only what genuinely needs to be shared, keep secrets in a shared Keychain access group rather than shared UserDefaults or files, and be deliberate about which apps belong to the group. The container is shared space, not private storage.
What you should know
- App Groups share a container: among apps and extensions from one developer.
- Everything shared is group-readable: every member can access it.
- Shared UserDefaults is not secure: unencrypted, like regular UserDefaults.
- Use a shared Keychain group for secrets: not shared UserDefaults or files.
- Share only what is needed: do not over-share sensitive data.
What are App Groups?
They are a mechanism for sharing data between your app and its extensions. iOS sandboxes each app, so by default an app and its widget or share extension cannot see each other's data; an App Group creates a shared container they can both use, enabling features like a widget that shows data from the main app or an extension that hands data back. The group provides a shared file container, a shared UserDefaults suite keyed to the group, and the ability to share a Keychain access group. You enable it as a capability and the members declare the same group identifier. So App Groups exist to deliberately cross the sandbox boundary in a controlled way, which is exactly why the data you put in the shared container is no longer private to one app.
What are the security considerations?
The shared container is shared, and shared UserDefaults is plain. The table summarizes.
| Aspect | Consideration |
|---|---|
| Shared file container | Accessible to all apps and extensions in the group |
| Shared UserDefaults | Unencrypted, like regular UserDefaults; no secrets |
| Shared Keychain access group | The right place for secrets shared across the group |
| Group membership | Every member can read everything shared |
| Over-sharing | Putting more in the container than needs sharing widens exposure |
The two mistakes to avoid are putting sensitive data in shared UserDefaults or a shared file, which are not encrypted and are readable by every group member, and over-sharing, placing data in the container that did not need to be shared at all. The shared Keychain access group is the correct place for secrets that genuinely must be shared, since it provides the Keychain's encryption and access control across the group.
How do you share data securely?
Share the minimum, and match the storage to the sensitivity. Decide deliberately what actually needs to be shared between your app and its extensions, and put only that in the shared container, keeping everything else in each app's private storage. For non-sensitive shared data, like a value a widget needs to display, shared UserDefaults or a shared file is fine. For secrets that must be shared across the group, a token an extension needs, use a shared Keychain access group rather than shared UserDefaults or a file, so the value gets the Keychain's encryption and access control. Be deliberate about group membership too, since adding an app to the group grants it access to everything in the container. The principle is least sharing: the shared container should hold only what genuinely needs to cross the sandbox, and secrets in it belong in the shared Keychain.
What to watch out for
The first trap is treating shared UserDefaults as secure, when it is unencrypted just like regular UserDefaults, so a secret there is exposed. The second is over-sharing, placing data in the container that did not need to be shared, which widens its exposure to every group member. The third is adding apps to the group casually, since membership grants access to the whole shared container. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled IPA against OWASP MASVS and assesses how your app stores data, which complements reviewing what your App Group container holds and whether secrets are in the shared Keychain rather than shared UserDefaults. The sharing decisions you make in the app.
What to take away
- App Groups share a container, file storage, UserDefaults, and a Keychain access group, among apps and extensions from the same developer.
- Everything in the shared container is accessible to every group member, and shared UserDefaults is unencrypted, so it is not for secrets.
- Share only what genuinely needs sharing, and keep shared secrets in a shared Keychain access group rather than shared UserDefaults or files.
- Be deliberate about group membership, and use a pre-submission scan such as PTKD.com to check how your app stores shared data.
