Android has intents as a way to request an action from another app. Windows Phone has contracts and extensions to declare supported interactions. Apple added inter-app communication in iOS 7, but only for audio. That's why more pervasive inter-app communications remains one of the most requested features for iOS 8. So what is it and why is it taking so long?
inter-app communication means different things to different people. For some it's the ability to push files from one app to another. For others it's the ability to pull data into any field in any app. For still others it's the ability to set default apps different than the current ones made by Apple. The core issue, however, is workflow. People just want an easier way to move their stuff around.
Working to complicate this is the nature of iOS itself, which is a security and privacy first operating system. That includes apps being locked into their own "sandboxes" so, if something somehow exploits a vulnerability to get into one app it can't then continue on to infect other apps or the system as a whole. This is in complete contrast to Android, which was built with flexibility and customizability at its core.
So, doing things like intents is likely intrinsically easier on Android than it would be on iOS, as any inter-app communication system Apple exposes to developers would have to be architected to punch through the sandbox in an absolutely secure way. It might also mean iOS inter-app communication could never be as broad as what Android's intents are. It could, however, be enough.
Apple's had URL schemes since the early days of iOS. Developers have used them, and figured out x-callback URL, as a way to move bits of data between apps. But it's cumbersome to coordinate and implement, and limited in what it can do.
XPC{.nofollow}, the Mac's interprocess communication mechanism, was ported to iOS a few year ago, but it remains private an unavailable to developers.
SpringBoard, the iOS interface system, was also broken into a smaller SpringBoard (foreground) and separate Backboardd (background) for event handling. But the ability to run headless apps hasn't been made available to developers either.
There are also various other things like Share Sheets and Open In which currently allow, with severe limitations, some files and data to be pushed out to other services and apps. Embedded Mail, App Store, and other sheets also bring bits of interface from other Apple apps into the current app to make it feel like inter-app communication is happening.
That last part, the perception, is what's most important. Back before iOS 4 people repeatedly asked for third-party multitasking. Apple, however, prioritized battery life and, realizing what people really wanted was the ability to surf Safari and listen to Pandora, offered very specific API to allow for very specific background processes instead. They also allowed apps to hibernate and resume instead of forcing them to quit and relaunch which made for a — admittedly clunky — illusion of full-on multitasking.
iOS 7 took this a step further with background refresh. Realizing that if content was available when a person wanted it, it didn't matter if it arrived hours or mere moments before. So, using a variety of triggers to create what's effectively just-in-time multitasking.
Could that same type of thinking and problem solving be used to create the perception of inter-app communication within the security model essential to iOS?
People want to move their photos from Camera+ to Snapseed to VSCO Cam without having to save them to and open them back up from the Camera Roll each and every step of the way. People want to have 1Password or LastPass insert their saved password into Settings, Safari, or Gmail without having to go to one app, search for the right bit of data, copy it, go back to the other app, and paste. People want to have links open in Chrome rather than Safari and locations open in Google Maps rather than Apple Maps.
These are the problems that need solving. Whether it involves securely surfacing XPC and leveraging BackBoardd, creating a plugin architecture — wait for it! — implementing a file repository and DocumentPicker controller, or figuring out a way for apps to declare the file and data types they can handle so those types can be assigned to them in Settings, I don't know.
What I do know, again, is that this is a problem people are facing. It's something that hinders their productivity on iOS and drives a segment of them towards other platforms, including the Mac.
If Apple could solve inter-app communications in a way that enabled workflows but maintained security, it would be a tremendous boost, and it would be something great to see, even in first-step form, in iOS 8.
