New Skepticism About the Old iOS Inter-App Communication Problem

WWDC is next week, and hope springs eternal that the walls between apps will come down, or at least they’ll be a little more permeable. Typifying this long-running wish is the rumor that iPads will offer a side-by-side mode, ala Windows 8.1, allowing more direct data sharing between two apps running concurrently.

As always, I’m skeptical. And I guess what’s driving that skepticism is the sense that few iOS developers are using the data-sharing APIs we already have.

We already have a few options for sharing between apps (I’m omitting exotic options like using the Keychain to share data between apps that share signing credentials). The bigs are:

  • UIPasteboard for copy-and-paste
  • UIDocumentInteractionController for exporting documents to other applications, and using UTIs to advertise what types your app can receive through this technique
  • UIActivity for advertising your ability to handle data from other apps, but not as a document. Built-in activities include things like posting to social networks, adding to the camera roll, etc.

I’m tempted to also add Audiobus to this list, as it offers real-time inter-app communication, albeit only with live audio data. Still, it should get the mind going about what you could do with it. For example, I would love for VoIP clients like Skype to support Audiobus, because then it would become possible to create podcasts on an iPad: you’d do your chat with Skype, use Audiobus to capture it into Garage Band or a dedicated podcasting app, edit, export, post.

Frankly, I’d like to see all audio apps assume that Audiobus (or Remote Audio Unit) support is a basic requirement of audio on the platform, because then users would expect that they can use their audio however they see fit.

But this is not the case. As I was noodling on this thought, I happened to send a tweet to Marco Arment, asking if his upcoming podcatcher Overcast would support Audiobus, or if he’d even thought of it. His reply:

Now I don’t mean to harangue Marco, because I fully expected that he wouldn’t be baking in Audiobus support. But his response is interesting, in that he asks what the point of exposing his data would be.

I would argue that should be up to the user to decide.

Let’s dig a little deeper. Forget Audiobus, and go back to the built-in APIs. Think of the UIDocumentInteractionController. Should a podcatcher expose the MP3s and AACs it downloads via this API, so the user would have a “share” button by which they could send the podcast files to other apps that could play or edit them?

We don’t normally think of apps offering this, but then again, when we want to edit stuff, we’re usally on a PC with a shared filesystem, so if we are going to mess with that file, all we have to do is find where it is on the filesystem. Since we can’t do that on iOS, the only way to enable it would be for podcatchers to expose their files via a share button.

I’m pretty sure that no iOS podcatchers actually do this.

Let’s say I’m using a podcatcher and I want to copy off the description of the episode, so I can e-mail to a friend or post it to Tumblr or something. On the Mac, I’m inclined to at least try to select text wherever it appears, even as static labels. Sometimes it works and sometimes it doesn’t, but it’s at least it’s in my mindset to try. On iOS, there is no expectation that static text is ever copyable. Even though it seems like it would be simple to do so: couldn’t we just create a category on UILabel to add a copy: method (that just says “copy [self text] to the system clipboard”), plop UILongPressGestureRecognizers on the labels in Interface Builder, and control-drag to the copy: method?

Well, pretty much nobody does this.

So when we start talking about how great it would be if there were better data sharing between iOS applications, I have to ask myself: if I were Apple, and I saw that developers were largely ignoring copy-and-paste, document-exchange, and activities, would I be all that interested in putting further engineering resources into developing new APIs of this ilk?

Are more productive apps being held back by a lack of good APIs from Apple, or has the platform just evolved into a read-only content-consumption device, despite our protests to the contrary?

If we want to share data between apps on iOS, maybe we should be letting our users do so already, and start to establish an expectation of copyability and shareability.

Comments (3)

  1. BTW, I tried my category thing and it works, but it’s a crap UI, since the user doesn’t know they’ve copied anything. A better implementation would be to have the UILabel pop up the UIMenuController with just the “Copy” menu item available.

  2. Dorada

    Agree with Marco – i’m not sure what the use case for Audiobus would be on a podcast app, also if i remember from when i looked at it a while ago its not that simple to implement.
    RSSRadio does allow you to send the audio file to other apps (and receive it back again) though.
    Daniel – Author RSSRadio

  3. Thanks for the comment, Daniel. I definitely need to check out RSSRadio.
    A thought I had about the response from you and Marco that you don’t know what the point of adopting Audiobus would be is that it’s kind of analogous to adopting AppleScript on OS X. To wit: I have no idea why I would want to control a browser with AppleScript, but I’m glad that Safari, Chrome, and Firefox all support it. In fact, we get mad when any serious OS X apps don’t support AppleScript, as with the iWork relaunch last year. There’s an expectation of sharing and inter-operability on OS X, and I think to make the same thing happen on iOS, we as developers may need to start pushing it ourselves.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.