Good.iWare Announces GoodReader SDK With “Save Back” Feature

Good.iWare, the company behind popular iOS file manager and document annotation tool GoodReader, has announced an SDK to let third-party developers send files and folders to GoodReader and receive them back after GoodReader has read/annotated them.

If you have an app that generates or downloads files meant to be read and annotated, and you want to use GoodReader's powerful engine to do that, you can take advantage of our new SendToGoodReader SDK. This SDK is absolutely free of charge.

As explained on a dedicated developer page, the SDK seems more oriented towards PDF documents for now, but Good.iWare also mentions “complex collections” of files and folders:

If you're a developer of iOS apps interested in offering your customers a convenient way to use powerful GoodReader's abilities to read and annotate PDF files, you've come to the right place.

What's interesting about this solution is that a “Save Back” feature should allow users to avoid the creation of duplicates by first receiving a file in GoodReader and then moving it – not copying it – back to the original app that “called” GoodReader. As I wrote a few weeks ago, the creation of duplicates is one of the biggest downsides of Apple's Open In menu:

You just used five apps and created four copies of a file (two of them are iOS Camera Roll + Photo Stream) to annotate a photo. Lather, rinse, repeat for note taking, PDF reading, electronic bill management, and assembling that nice slideshow of your vacation in Italy.

I say “should” because I haven't been able to try any app with support for GoodReader's SDK yet, but that's my takeaway from the developers' explanation.

If GoodReader's “Save Back” feature turns out to be what I imagine it is, it has the potential to become a great addition to existing Open In implementations, and perhaps even a possible path Apple could consider for a future version of iOS. I believe better communication between different apps is an area where iOS is severely lacking, and this concept – “saving back” and moving files instead of duplicating them – if implemented correctly could become, essentially, the x-callback-url of files. The obvious limitation is that the SDK is limited to GoodReader, and that there are no apps supporting it yet. I'm thinking of how Evernote could take advantage of this by letting users annotate PDFs in GoodReader, or how a mail application could let GoodReader unzip an archive and receive an uncompressed version with two taps. The possibilities are certainly intriguing.

It's too early to say whether GoodReader's experiment will be successful, but I think “saving back” is a much better idea than “opening in”.

“Open In” and Mobile Safari

Continuing the discussion about the “Open In” menu for iOS, David Chartier proposes “Open In” for Safari URLs:

Finally, Document Sharing in Mobile Safari would further promote an app-centric workflow on iOS. Bookmarklets are often designed to open another web service in a new browser tab, and let’s face it, working on the web is a crummy experience. But even if they’re wired to open an app, bookmarklets are still a colossal pain to install which cuts off most attempts at the knees. This largely confines Mobile Safari and its content to an island, making iOS’s URL-to-app workflow needlessly tedious for anyone brave enough to try it.

In its current form, Mobile Safari only supports “Open In” for documents displayed in the browser, such as PDFs that Safari can render. The (new in iOS 6) share sheet doesn’t come with options to send a URL around, but only to copy it to the system clipboard.

Bookmarklets were never meant to take off among consumers, because they require a minimal amount of knowledge (or steps) that average users don’t want to deal with. However, developers had to resort to using bookmarklets because it was the only way to provide something that worked to pass a URL from Safari to a third-party app/web service. Some developers have gone out of their way to provide an “Install Bookmarklet” experience that wouldn’t scare off the majority of users.

Overall, “Open In” for links doesn’t sound like a bad idea. Imagine being able to quickly send a YouTube video to Facebook or a link to the Twitter app with an Apple-sanctioned menu and not some JavaScript hack. There are aspects I don’t know how I’d solve right now (How do supported apps appear in the iOS 6 share sheet? Are they available in a dedicated page, or can users re-arrange them? Could Siri be told to perform such actions?), but, generally speaking, providing better web-to-apps communication would be a good start.

Two years ago, Marco Arment offered some ideas on a possible “Send To” panel for Safari. This is absolutely still relevant today, because it hasn’t gotten better.

Obviously, that would be far from my envisioned iOS automation for power users. I’ve been trying the beta release of Alfred 2 lately, and I like how the developers created a workflow visualization that is both powerful and intuitive in the way it connects visually triggers to actions and outputs. Ideally, I’d love to see Apple considering an “Automator for iOS” — the kind of feature that most users don’t care about but that would likely make a subset of them reconsider iPads as “real work” machines. Apple could even go as far as making that kind of user automation look “cool” with the right interface decisions and a powerful inter-app communication layer that is not limited to Apple apps (read: with an API).

I hope this kind of stuff is in the cards for iOS 7.