A higher level of inter-app communication in iOS

Along with the apparent de-Forstallization and Ive-ification of iOS scheduled to be announced around this time tomorrow at Moscone West, another big thing most people want from iOS 7 is a better way for apps to work with each other.

So far, this can only be achieved via URL schemes and x-callback-URL by using apps like Launch Center Pro and Drafts, and more recently, Dispatch.

Apple is supposed to remedy that need for a much more complex workaround by introducing a system of intents, similar to how it is on Android, which, coupled with defaults, would truly be a godsend.

While this seems to be well and enough for even most power users, I personally don’t think that Apple will stop at defaults and intents only for what is rumoured to be such a huge overhaul. Tim Cook’s words at D11 about new APIs to open up iOS a bit more to developers further strengthens this belief of mine, so I’ve put together a few ways Apple can possibly facilitate not just inter-app, but OS-app communication too.

iOS 7 banner from WWDC

1.) A unified document repository:

One of the main problems of iCloud is that it relies on apps to sync files. A text file written in app ‘A’ doesn’t just not appear in app ‘B’ automagically (as it does in compatible apps made by the same developer/ copies of the same app on different devices with the same iCloud account), but even if it is copied to there, it does not sync with edits made to the copy in app ‘A’ – with there being no way to automate that, at least through iCloud – and also takes that much of extra space on your device and the cloud. A unified repository from which apps can “borrow” files and return them, thereby keeping one copy per file on the device, which gets updated to reflect the changes made in any app, just like with photos and video in Photos.app, seems like a solution to this. In this way, a change made in say, Byword, will also pop up automagically in Daedalus, Write, and any other number of apps you have, without the need to start up the power-hungry LTE or WiFi radios in background to do so.

It can be an actual app on the homescreen, say a ‘Files.app’, but it can even exist as something without a tangible front-end but accessible from any app capable of using file formats stored in it, just like the photo library is accessible from all camera-based apps without there never being any need to use the actual app. It will also sync with a corresponding library in iCloud, meaning all the content in all your apps is updated with one periodical sync, getting rid of concerns about battery life if periodic background sync is implemented as with Photo Stream.

Rene Ritchie of iMore has written at length about this, and I highly recommend that you read his take on a Files.app in iOS 7.

Files.app in iOS 7

2.) A truly unified photo library/ a Photo Stream API:

Because of the lack of one definite library to sync, iCloud syncs all text files from whatever app you enable it in . A similar feature is available from photos in the form of Photo Stream, but unlike with text files, Photo Stream needs one to transfer the files to the existing photo repository in Photos,app manually for it to work. Because of the sandboxed nature of iOS, every app stores a fresh copy of whatever file is opened in it by the current “Open In” interface. This results in a huge amount of unnecessary data duplication and fragmentation.

I can see only two solutions to this as of now:

A.) A truly unified photo library, wherein all photo apps are forced to use Photos.app to store photos edited and taken in them. This seems to be a nice idea, but I’m not quite sure as to what happens to edits in this one. As of now, when a photo is copied over to a non-stock app and edited and restored back, it’s a separate photo altogether and the original one is conserved, but in the built-in editor, edited images non-destructively overwrite the originals. With a unified library, it can either create a separate copy, or replace the existing one in all cases, but it has to do one and only one in all cases, and unlike with text files where not many cases exist where a user would want the original after editing it, this seems to be a polarizing choice when it comes to photos. One may want to keep the original for some photos, and do away with it for others. To me, this seems too confusing a feature for Apple to implement.

B.) A Photo Stream API is issued which allows apps to sync their photos with the Photo Stream without having to transfer them to the default library, with photos opening automatically in their original apps when they are available and in the unified Photo Stream too, but not in the Camera Roll. This seems like the one with the lesser flaws to me, as it doesn’t compromise the app’s own library while allowing photos to be exported to the Camera Roll directly through Photo Stream in it’s absence too.


3.) A DND (Do-Not-Disturb) API

Being able to schedule DND for certain events as you’re adding that to your calendar or GTD app was something I was sure would be possible when Do Not Disturb was announced in the iOS 6 keynote last year. It seems to be one of those things you think of as “obvious” when you think of it. Just adding the word “DND” at the end of any time-based event while adding it via Siri or a natural language processor like Fantastical to enable it for said event’s duration would be great.

Also, with the age of mainstream wearable computers just around the corner, many of which already offer sleep-tracking functionality, it isn’t hard to imagine that you’re Fuelband or iWatch automatically switching DND on or off depending on your state of consciousness.

This really seems to me like the Apple way of “gathering” information to help you in a. Google Now-like predictive manner to me, with no any actual transfer, let alone analysis, storage, or tracking by the Government, of your personal data.

Do Not Disturb

4.) Defaults extend to Siri and Spotlight

A full-fledged API for Siri anytime soon is highly improbably, if not entirely impossible. Like always, it’s not hard to imagine that Apple feels that maintaining control over what is available on its platform is the only way to maintain its quality. That, along with big cash deals with those services already integrated with Siri, like OpenTable and Fandango, are supposed to be reason enough for Apple to not open up Siri.

However, Apple is rumoured to be allowing users to reset their default apps with iOS 7. In that case, one of the “problem” of quality-control disappears, with the stock replacements, quite obviously having to have to be at par with the users’ quality standards, and since the services tie into Siri, being non-stock apps, are not susceptible to replacement, all fears of any loss of potential financial gains via tie-ins are also allayed.

Also, specific defaults rid one other problems too: that of keywords. Many people argue that as of now, the reason for Siri not working with other apps is keyword parsing. When the words “remind me” or their equivalent are picked up by Siri, that is translated as a command to be stored as a reminder. If multiple apps with the same keyword were given Siri access, it might result in a conflict. Siri wouldn’t know whether to store the reminder in Things or Omnifocus, culminating in a crash. If an app is selected as a default, however, the keyword of the app it replaces can be allotted to it, thereby getting rid of the keyword dilemma too. In other words, if an app is to actually replace a stock app as your default, it will also become the app Siri speaks to instead of that app.

In the same way, Spotlight ahold be able to browse through your Cobook contacts, Drafts notes, and Ecoute music if they’re your defaults.


5.) Actionable notifications

This has been almost perfectly covered by, again, Rene Ritchie of iMore in [this brilliant piece](http://www.imore.com/ios-7-wants-actionable-notifications-push-interface “Rene Ritchie of iMore on actionable notifications in iOS 7). I can’t think of absolutely anything to add, honestly.

Actionable notifications

You can follow me on Twitter here.