Calling your other iOS app with parameters, even if it’s not yet installed; Without a website, or 3rd party services.

Consider the following scenario:

You have 2 apps, A and B. App A needs to launch App B with a username, and maybe some other more complex data structure. And we can’t assume App B is even installed.

There are various ways to do this.

Possible solution #1: A simple Deep-Linking with parameters should do the trick; And for when App B is not yet installed, we can use a 3rd party service like Branch. But, can you really trust them to connect the dots and be able to communicate the data reliably after the user installs App B?

Due to the hacky nature of such 3rd party services, while they work most of the time, occasionally they do fail to pass the data to the target app.

Also, don’t forget that Apple is all about privacy these days, and services like Branch are no different than tracking tools.
Speaking of privacy, the data you want to send to App B might be sensitive, so you need to trust Branch with your users’ data.

Possible solution #2: Universal Linking, is Apple’s alternative to Deep-Linking, and it does allow you to pass parameters to App B, even if it’s not yet installed. But, then you need a website and network availability. It might not be for everyone.

If only App A could communicate complex (preferably Codable) data to App B, without all the hassle and disadvantages of the above orthodox solutions.

Introducing App Groups

App Groups was designed to share data between the main app and it’s extensions, but it can also be used to share data between two apps under the same publisher.
From the code perspective, App Groups is basically a UserDefaults in a shared container.

A quick example

Here is what needs to be done to communicate a username string, from App A (sender) to App B (receiver), even if App B is not yet installed.

I. Create App Groups, on both apps:

For both App A & App B, go to Capabilities, enable App Groups, and create a group. For this example let’s call it “group.myAmazingApp”.

Note: according to Apple, it must be group.<group name>.

II. Create URL Scheme for app B:

In order to allow app A to open App B, we need to setup the URL Scheme in App B. In App B, go to Info.plist -> URL Types, and create new; For this example we’ll call it “appB”.

III. Allow App A to access App B’s URL Scheme:

Explicitly whitelist App B’s URL Scheme, to allow App A to call it.
In App A, go to Info.plist -> Custom iOS Target Properties, create LSApplicationQueriesSchemes as an Array, and add “appB”.

IV. Code for App A (sender):

V. Code for App B (receiver):

Summary

App Groups is an interesting alternative to communicate data between your apps, with plenty of pros, and some cons.

Pros:

• Simple setup and use.
• Allows to start an app with one or more parameters, even if the target app is not yet installed.
• No need to own a website for your app, or even access to network.
• Unlike with Universal-Link and Deep-Linking, data can be complex with Codables via Data.
• Pretty secure/private, as any data on a user’s device; Everything is stored locally, and can only be accessed by the same publisher.

Cons:

• It might be more secure than Deep-Linking, but it’s no more secure than your app’s container UserDefaults; So you shouldn’t use it for sensitive data.

Your opinion matters

Should this method be turned into a dual communication channel for same publisher’s app to transfer data locally? Let’s discuss in the comments.

Cheers! 🎈