App-to-App Communication in Enterprise iOS Apps

Funmilayo, an associate on our Global Investment Research Technology team in London, offers
some practical advice on building iOS apps that communicate and share data with one another.

Consumers are downloading more apps and spending more time with their smart devices than ever before. The rise of BYOD (Bring Your Own Device) enterprise initiatives is evidence of a response across industries to increased consumer demand and a powerful market opportunity. At Goldman Sachs, our total number of iOS and Android apps now stands at 13, with more to come.

The sheer number of available apps presents an exciting opportunity for developers: building apps that interact with one another. Inter-app communication extends an application’s functionality and minimizes bloat. It is widely used today in native and web applications on all device types. But it can also present new challenges around managing security risk in an application.

For example, a malicious app could construct requests targeting your app in an attempt to phish for data or corrupt its contents. How do you block such requests? Is sensitive information being shared, and is it protected? Before building a BYOD app, it’s important to evaluate the various inter-app communication methods in terms of your security demands.

How Inter-App Communication Works

There are several methods for adding inter-app functionality to iOS apps. One is by directly launching an app via its registered URL scheme:

Several Goldman Sachs apps leverage this approach: Our CRM app, smaRt, enables users to email clients using the URL scheme of Orbit Mail, our BYOD email app. Orbit Mail in turn allows users to record those client interactions in smaRt via its URL scheme. By linking our apps this way, individual applications do not tackle business problems already solved by other apps. This keeps our apps lightweight and feature-rich, while reducing maintenance overhead.

Registering a URL scheme for an iOS app is straight-forward. Start by adding a CFBundleURLTypes key to your app’s plist: 

Then determine why your app launched by looking for UIApplicationLaunchOptionsURLKey and UIApplicationLaunchOptionsSourceApplicationKey in the launch options dictionary. These provide the requests URL and the requesting app’s bundle identifier, respectively:

Finally, parse the request and perform the requested action in your application delegate’s application:openURL:sourceApplication:annotation: method. iOS automatically fires this method during an app’s launch process if it receives a URL request for the app:

Limitations of Existing Inter-App Communication Approaches

One drawback of the URL Scheme approach is that it forces users to leave the current app to view content in the requested app. Even with a back button – which some apps provide by including their own URL scheme as a parameter of the request – the user’s concentration has already been broken. Navigating deeply into the second app could cause users to lose their place, without an easy way to return to the original app.

iOS 8 attempts to solve this problem with a richer Extensions API, allowing apps to provide custom functionality that run within other apps. Using the previous example, Orbit Mail could provide a “Compose GS Email” action extension to allow smaRt’s users to email clients without leaving smaRt. That way, smaRt could invoke Orbit Mail’s compose extension without having to launch the Orbit Mail app:

Security Considerations

There are several steps you can take to minimize potential security risks when using inter-app communication. One precaution is to retrieve the requesting app’s sourceApplicationId from the operating system rather than as a URL parameter. This unique identifier is used by iTunes Connect, the App Store and the OS to identify an app, guaranteeing the security of the resulting string.

Another measure is source app whitelisting. Before processing any URL request, your apps can cross-check the sourceApplicationId and any callback schemes in the URL against a whitelist of allowed apps, which you can securely store in the device keychain. Your apps can then simply block requests from unexpected apps.

It is also important never to transmit sensitive data explicitly as parameters of a URL, since the request may be intercepted. Instead, consider storing such data in a keychain location accessible only to your BYOD apps, and instructing the target app to retrieve it from there. We do just this in our BYOD apps: after an email is sent, Orbit Mail encrypts and stores details of the interaction in the keychain. When smaRt is launched via the inter-app request, it extracts and decrypts the corresponding data from the keychain and presents it to the user for verification.

Lastly, your app cannot be truly secure without proper validation of URL parts and parameters. Our apps use regular expressions to validate each section of the URL, giving us tighter control over its different components. We immediately reject any URLs that do not conform to the expected format and shut down the app or display a message to the user.

Overall, inter-app communication is a simple yet powerful tool for building feature-rich BYOD applications, a necessity for standing out in the current consumer climate and catering to the business needs of our people. With the proper security measures, developers can ensure that their mobile platforms are robust and long-lasting.