Improved inter-app sharing services coming to iOS?

Improved inter-app sharing services coming to iOS?

Summary: Developers complain about the strict limits that sandboxing places on content sharing in iOS. An undocumented sharing scheme deep in iOS 6 offers a glimpse of more and better sharing in future revs of the mobile OS.


Many developers are having trouble with the strict limits that sandboxing places on content sharing in iOS (and let's face it, OS X). However, several developers have noticed that Apple is implementing an undocumented and improved sharing scheme in iOS 6 — an API that may herald more sharing in future revs.

In a couple of recent blog posts, Berlin-based developer Ole Begemann wrote about Remote View Controllers, an undocumented feature of iOS 6 that allows sharing between iOS apps even with the sandboxing security architectures. Begemann suggests that these Remote View Controllers are an implementation of the existing XPC Services API used in OS X.

Apple introduced XPC in OS X for security reasons. Apps are supposed to split themselves up into separate services that each handle a security-sensitive component. For example, a web browser might split up all its network communication and its HTML/Javascript parsing components into separate XPC services. That way, these services can run with very limited permissions (no access to the file system) and won’t be able to do much damage if they get compromised.

The Mac Developer Library's Daemons and Services Programming Guide says that XPC Services "provides a lightweight mechanism for basic interprocess communication ..." and points to two reasons for their use: stability and privilege separation. The first advantage is obvious, if there's part of an app might be unstable, it doesn't have to affect the core of the application in the event of a crash.

However Privilege Separation is the part on developers' minds. The Guide continues:

In a sandboxed environment, you can further increase security with privilege separation—dividing an application into smaller pieces that are responsible for a part of the application’s behavior. This allows each piece to have a more restrictive sandbox than the application as a whole would require.

Other mechanisms for dividing an application into smaller parts, such as NSTask and posix_spawn(2) OS X Developer Tools Manual Page, do not let you put each part of the application in its own sandbox, so it is not possible to use them to implement privilege separation. An XPC service can inherit the sandbox of the main application, or it can have its own sandbox. Putting the XPC service in its own sandbox allows you to implement privilege separation.

So, Begemann points to this second advantage: dividing up applications and giving each different sets of permissions, thus allowing them to access system services or even data from third-party apps. He writes extensively about his exploration of the Remote View Controllers and comparisons between iOS 6 vs iOS 5.

He looks forward to seeing this feature documented and used in future versions of iOS.

Remote View Controllers are an exciting new feature for iOS. I sincerely hope that Apple will use this technology in iOS 7 to enhance data sharing and communication between third-party apps without compromising the iOS security model. We need it.

How could this work? Apple could ask developers who want to provide a sharing UI to other apps to include a second executable in their app bundle. This executable would be an XPC service that looks a lot like the we analyzed above. Its main component would be a stand-alone view controller that was able to communicate via XPC and implemented some standard Apple-defined protocols named something like UISharingRemoteHost and UISharingRemoteService.

Take a look at Begemann posts on the API and see what you think.

Topics: Apple, Apps, iOS, Operating Systems, Security, Software Development

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Copying Android Again

    Android has had its “Intents” system right from the beginning, which is why apps are able to share data so seamlessly, without having to wait for the vendor to include system-level support for access to Facebook or Twitter or GitHub or Diaspora or whatever else might come along next week. Just install an appropriate client app, and its sharing service is immediately available for access from other apps.

    But Apple has a problem, in that IOS lacks an Android-style sandboxing permissions system. Android’s permissions are also extensible: for example, a third-party app can define custom permissions for services that other apps can request of it, and of course users will see those turning up in the manifests of other apps that request those permissions, and get to approve/reject installation on that basis.

    Android has the best-thought-out security model of any mobile OS. You can’t just tack on new features with security implications, you have to architect them in very carefully.
    • Android unsecure

      Some developers are using bad practises by offering apps by other ways than official appstore. Also app piracy is rampant on Android, with people installing malware infested apps to save $1.

      By offering an easy way to bypass the official store, the whole device become compromised and unsuitible for corporate use. Android users click yes, yes, yes, without reading app permissions.
      • Re: offering apps by other ways than official appstore.

        Nothing wrong with that. Users have a choice.
        • ldo17

          HAHAHAHA you made me laugh!