App Groups: Sharing Data Between Your Apps & Extensions

WHY IT EXISTS By default, every iOS app lives in its own secure sandbox, isolated from all other apps for security and privacy. This prevents apps from interfering with each other but makes it impossible for related processes, like a main app and its widget, to share data directly. App Groups were created to solve this specific problem.

THE MENTAL MODEL Think of each app as a house with its own private property—its sandbox. An App Group is like creating a shared, secure community garden between a few specific houses that you own. Only those houses have a key to the garden's gate, allowing them to read and write data in that common ground, while all other houses on the block are kept out.

HOW IT WORKS When you enable the App Group capability in Xcode for multiple targets (your app, widget, etc.), you define a unique group identifier, like 'group.com.yourcompany.yourapp'. iOS then creates a single shared directory on the file system that all members of that group can access. You can get a URL to this directory to read and write files, or you can use a special initializer for UserDefaults, UserDefaults(suiteName: groupIdentifier), to access a shared key-value store.

WHEN TO USE IT Use App Groups for sharing data between a container app and its extensions, such as Widgets, Share Extensions, or Notification Service Extensions. It's also the standard way to share data between two of your own distinct apps on the same device, like a free and a pro version that need to share settings or content.

WHEN NOT TO USE IT Do not use App Groups to communicate with apps from other developers; that's what URL schemes and other dedicated APIs are for. It is not a replacement for a backend server, as the data is only shared on that specific device. Also be aware that if the user deletes the last app belonging to the group, iOS deletes the shared container and all its data.

ONE CANONICAL EXAMPLE A weather app and its home screen widget need to share data. The main app fetches the forecast and saves it to a file in the shared container. The widget's timeline provider then reads that same file from the shared container to display the latest forecast. This avoids the widget making its own network request, saving battery and data. To access the shared data, the code in both targets would use the same group identifier to locate the shared directory.