I'm struggling to see what is the difference between the native iOS UIActivity vs Ink.

http://developer.apple.com/library/ios/documentation/uikit/r...

I thought that's what UIActivity does and many applications are already using this particular feature to share photos between apps.

The primary difference is that Ink allows for applications to register new actions across applications, and to launch content directly into other applications as well. Think of Ink as a cross-application version of UIActivity that's open to anyone registering handlers, as opposed to only being able to use the UIActivity's of your own app or the system provided ones.

I wonder if Apple will approve this, as it seems to allow the iPhone to do something that Apple doesn't want it to do?

If Apple wanted apps to talk to each other in the (IMO very sensible) way that Android does, wouldn't they have done so?

We've been working with apple since WWDC, they know what we're doing and are fine with it.

Are you afraid they are using you for market verification?

Not particularly. In a sense larger, established companies are always looking at startups for market verification; the startups that succeed are the ones that can out-pace the established companies.

In addition, there are market dynamics that preclude any of the larger players truly building a platform for interoperability. See for example the recent Google/Microsoft turf wars, that Mailbox only supports attachments from Dropbox, iOS native composer only works with Mail and not gmail, etc.

I'm curious how the inter-device communication will work. Will I be able to send data from my iPad to my Android phone, for example? That would be pretty slick if so.

Speaking of DropBox, they seem like a natural competitor in this space. Given that they are also a YCombinator startup, has that been discussed? Or is it more likely they will just be happy to be one of the many backends you support?

They already approved AudioBus[1], something similar for music apps. In fact, the iOS version of GarageBand supports it now, which was unexpected.

[1]: http://audiob.us

Is this secure enough that a local password manager (like 1Password) could responsibly use it to pass credentials into apps?

The current release candidate (v0.4.0 - https://github.com/Ink/InkiOSFramework) does not do end-to-end encryption between apps, so we would want to work with them to add in AES256 at a minimum before I'd recommend sending over passwords.

It's both technologically possible to make this secure enough and on our roadmap for the next major release.

The article brings up a great point. This tool is so esencial I wonder why is it that Apple and Android have not made this natively much simpler. Seems like a great venture to be a part of.

> Android have not made this natively much simpler.

This is already amazingly simple on Android natively though. This is an attempt to make it similarly simple on iOS.

Intents has done a great job on android - I have some minor quibbles with it, but it's light years ahead of what iOS had pre-Ink

Edit since I can't reply to milesokeefe: As an avid android user (Galaxy Nexus), some things about intents that I feel are poorly designed: - No support for bidirectionality. There's no sense of "I'm done with this action, take the results and send it back" - No sense of intelligence in terms of what actions are shown. As far as I can tell, it seems to be filtered by content type, sorted by Most Recently Used. - Unclear actions - iOS suffers the same issue, where it's not really clear what it means to open in another application.

> No support for bidirectionality. There's no sense of "I'm done with this action, take the results and send it back" -

Doesn't startActivityForResult fit this use case?

> No sense of intelligence in terms of what actions are shown.

I agree here, it can be annoying to pair down the list of applications which will handle an intent. If one wants specific applications one can use the package manager to check its existence and then use that.

You can also reduce the list before presenting it to the user.

As myko stated, you're wrong about intents lacking bidirectionality, see http://stackoverflow.com/questions/8823206/how-to-return-dat...

Just curious, what are your minor quibbles?

see additional discussion on the other HN topic here, including comments from one of the founders

https://news.ycombinator.com/item?id=6218991

I'll comment here as well, the other one seemed to have gotten bumped

A short description of how it works would probably go a long way for developer adoption. There doesn't seem to be any.

The most obvious way to implement this might not work the same in iOS 7 -- I'd want to know more before relying on it.

Re. how it works behind the scenes, we do a streaming protocol over UIPasteboard, with actions being cached locally and periodically updated from the servers when connection is available. At least for now - we will continue to iterate on the underlying tech to make it faster/more reliable/more secure.

Re. iOS7, it required being a bit more clever, but Ink works with iOS7.

Give it a try, let us know what you think.

I wonder is this going via the internet anyway, or just using the pasteboard thing.

We do the data transfer locally on the device. We had an early prototype that did things over the web, but it was too slow and was frustrating to use on 3G.

Edit for clarification: the transfer occurs locally and works while offline.

Locally would certainly be preferable (especially for iPads, where the user may not even have an internet connection).

And let's not forget that even iPhones can be away from cellular coverage.

Our announcement at http://blog.inkmobility.com/post/58338915828/announcing-the-...

Can't you just use IPC and basic file I/O, rather than tech bubble 2.0?

Amazing job, excited to see where this goes.

Isn't this Apples job?

I have a feeling it will be.