Share data between apps and extensions in iOS

Tram Ho


Surely the concept of extensions is quite familiar to us, because they are the extension features for the app. However, iOS app extensions run as part of a device app rather than part of an application containing the application (e.g. your app runs in someone else’s app), sharing data. not automatically. So searching for document folder locations doesn’t work with shared data. In this article we will learn how to share data between iOS apps and extensions.

Let’s find out together!

Sharing non-local or non-app data

Of course easy way is there is no need to share local app-specific data. If the data is not local or specific to your application, the sharing may already be protected.

Non-local data implies that it is linked or available from some source that is not in the application, like a web server somewhere. Since application extensions generally don’t run for very long, adding network latency might not be feasible. But in principle, there is no reason that the extension cannot make the same network calls as the application.

Apple’s approach in their Lister demo app is to use iCloud with Core Data. It’s also not local as it syncs with the iCloud service, but has the benefit of system-level local caching to avoid network delays. Of course, Core Data with iCloud has its own set of problems …

The data that is not specific to your app will be the same as the iOS address book database. If you’re using data that Apple has provided you with an API for data sharing, you’re set up.

Set up an App Group

App Groups are diagrams that iOS uses to allow different apps to share data. If the application has the appropriate permissions and permissions, they can access the shared folder outside of the iOS sanbox security data.

Let’s see how to set up App Group on Xcode as follows:

Of course, before doing this step, we need to create the App Group on Apple’s develop page, and proceed to enable the AppGroup feature in the app IDs and extensions.

Using your App Group

The easiest way to use an app group is through sharing the default user. Instead of using the [NSUserDefaults standardUserDefaults] command, create a custom user defaults object:

If you need to share more data then in addition to using user defaults, you can access the shared group directory through the NSFileManager:

Any application or extension with the right group benefits can access the same folder, so any data stored there is shared among all of them. If you want any sub folders, you will need to create them.

Keep Your Data Intact

But first, make sure you don’t accidentally damage the data. Sharing data files means that there can be multiple processes trying to use one file at the same time. Sandboxing on iOS means this is a fairly rare situation, but that doesn’t mean you can ignore it.

You will want to use NSFileCoordinator any time you want to read or write your shared files. You will also want to execute NSFilePresenter any time you need to know if a file has changed. They are introduced as a companion to iCloud, where both your apps and the iCloud daemon may want to access the same file. They are not iCloud specific, though.

NSFileCoordinator NSFileCoordinator implements a read / write key so that file access can combine access between different processes. It helps ensure that a process gets exclusive access to a file while writing on it.

It’s important to note that the NSFileCoordinator method runs concurrently, so your code will block it until it’s done. That’s advantageous because you don’t have to wait for an asynchronous block callback. But it also means that they block the current thread. If some other process will be busy with the file for a long time, you will end up waiting for it.


NSFilePresenter is a protocol you can add to any class. A file slideshow is just any object that cares about the state of the file and wants to know when something happens. Most methods are optional and have to notify you that the file has changed in one way or another so that your code can respond. Some other methods recommend your code of what to do – for example: “hey, now would be a good time to save any changes you have” (savePresentedItemChangesWithCompletionHandler:.

The file submission methods you follow depend on how much you need to know about the changes to your shared files. The simplest case can use presentedItemDidChange but no one else. That general call tells you that some other process (your application or extension) has changed the contents of the file. What you do depends on how you use the data.

Make sure to pass the file presentation object to the NSFileCoordinator when you create it. Though it’s not necessary, it helps prevent your code from being notified of changes by itself. Also, if you are implementing methods like NSFileCoordinator be sure to tell NSFileCoordinator that you are interested:

Notifications between Apps and App Extensions

There is still no full IPC mechanism on iOS. NSDistributedNotificationCenter didn’t take the leap from OS X to iOS and probably never will. However, file coordination and presentation can serve the same purpose, as long as the applications use the same set of applications.

As I add orchestral and presentation files to my demo application, I realize that they can also be used for notifications between an application and its extensions. If one of them writes a coordinate article, while another is using a file slide show for the file, the call to presentedItemDidChange happens almost immediately. Notice is the whole purpose of that method, so it makes sense it will work this way. I want to be notified if a particular file changes and that’s how I get the notification.

But you don’t need to care about the content of the file to care about the notice. If you only want one notification, choose a filename and use it as the notification mechanism. Anytime a process needs to notify someone else, make a change to the file. The other will receive a file presentation call, and the message is complete. It feels like a hack, but really exactly this is how the API was designed to work.

Another approach that has gained in popularity is the MMWormhole project. It ignores file presentation and uses Darwin level notifications via CFNotificationCenterGetDarwinNotifyCenter. This is actually a bit like NSDistributedNotificationCenter

For Watch Apps Only If you’re writing an Apple Watch app, you’ll have an additional option that isn’t available for other types of app extensions. In your subclass, call openParentApplication: reply: to pass data to the containing application and receive the response. That will trigger a call to application: handleWatchKitExtensionRequest: reply: in the delegate of the application containing the application. This method serves as a direct message but can also carry arbitrary data.

Unlike other approaches, this has the benefit that it will launch the containing application if it is not already running. Using file coordinate or MMWormhole is great but they cannot launch applications containing.

The drawback of this approach is that it can only be started from the View app. The application contains no corresponding calls to tell the View application that new data is available.


Although AppExtension and its containing application are in the same Bundle , they cannot directly contact or share data. Even direct communication between iOS Apps is not possible. Here, AppGroups help us, AppGroup is used to share data between AppExtension and its container application and also helps to share data between different iOS applications.


Share the news now

Source : Viblo