Scripting iOS

Last week Apple acquired automation workflow application Workflow. Of course there was a nice buzz around it and it was a big topic of conversation on various podcasts and websites.

This, of course, got me thinking about automation. I’ve always been a fan of open API’s and the ability to automate applications. We’ve also seen recently that Omni Group is opening up OmniGraffle to automation via JavaScript.

Back in 2010 x-callback-url was created as a way to allow applications to call into each other and return results so you could chain together calls to build custom workflows. Apps like Launch Center Pro and Workflow took advantage of x-callback-url to let you build those workflows and execute them. Now we have a bonafide standard, without a standard. The app ecosystem found a way to support automation without Apple’s help.

I’ve used Launch Center Pro but until recently I’d never used Workflow, and it’s pretty amazing. The Workflow guys did an amazing job creating a drag and drop UI for building what amounts to a program. Well worth a look.

So, this brings me to what I’ve been thinking about over the past few days. Given x-callback-url and App URL schemes in general it would be extremely cool to use those to create object hierarchies using JavaScript. Why JavaScript? Well, it’s native to iOS and applications can use the runtime. Given the advances made by the Workflow team why not take it one step further?

Allow applications to specify a  Scripting Dictionary or Type Library as part of the application bundle, this should allow runtime creation of objects. I know this isn’t rocket science and it’s been done many times over.

Short of adding support to the OS it would be pretty sweet if an App like Workflow, Launch Center Pro, or Pythonista would standardize on a way to parse a URL Scheme into an Object Hierarchy.

I’m going to use Evernote, Bear, Overcast, and Arrgly as examples.

What do you mean by Object Hierarchy?

That’s a good question. Here’s what I’m thinking. Since the Apps mentioned above all support URL Schemes we can derive an Object Hierarchy from them. Basically the beginning of a URI begins with a scheme. The scheme is the name. In the case of Evernote it’s evernote. Pretty simple, right?

Given the scheme name we follow that with a path. In the case of x-callback-url based URL schemes we will skip over that part and move to the second item in the path. This will be the action, or function, or the object we’re going to execute.

evernote://x-callback-url/new-note?type=text&title=EC%203

The above URL will tell Evernote to create a new note of type text with a title of “EC 3”. If we had a way to parse that in a runtime application we could present the user with an Object that has methods that take arguments, like this.

evernote.new-note(type, title)

Let’s do a couple for Bear. First the URL Scheme.

bear://x-callback-url/create?title=My%20Note%20Title&text=First%20line&tags=home,groceries

Now translated into code

bear.create(title, text, tags)

Overcast URL Scheme.

overcast://x-callback-url/add?url=

Code

overcast.add(url)

And finally, my favorite, Arrgly URL Scheme.

arrgly://shorten?url=

Arrgly Code

arrgly.shorten(url)

Pretty simple to turn all of those into objects. When I say you can create a hierarchy it means you could, by convention, lump groups of actions into objects, or like the above examples have a set of actions that all live on a single object.

Here’s what a object might look like as a URL Scheme.

thing://x-callback-url/document/add?title=
thing://x-callback-url/document/delete?id=

That would result in using it like this

thing.document.add(title)
thing.document.delete(id)

Of course this need more fleshing out and it would require app developers to decide on a well known convention to make it work as expected, but it could be done with a bit time and effort. It could be these become an extension of the x-callback-url specification?

Gruber and Simmons

RibbitI had a couple hours of driving to do today, had to take my busted computer in for repair. To while away the time on road trips I often listen to a podcast or two. Today’s selection was The Talk Show, Episode 75.

Messrs. Simmons and Gruber discussed scripting languages and asked if Apple needs to create a modern language for iOS and Mac development. The discussion was good, but I think there were a couple topics they could have touched on.

Pointers

Every C, C++, and Objective-C developer has had to deal with them. With the introduction of ARC a few years back pointers are all but an afterthought in Objective-C. Sure, there are exceptions, but mostly we no longer have to worry about freeing memory and it’s taken care of by the compiler, not a garbage collector. We have the best of both worlds with Cocoa and Objective-C; Native speed and memory management.

C#

Something they mentioned was Microsoft’s creation of a modern language based on a C lineage. It makes sense to do that because there is a big pool of developers that understand it, but I digress. I think the more important technology is Microsoft’s creating of the CLR and the .Net framework. One of the reasons these two items are so important is, they’re language agnostic. You don’t need to know C# to realize the full power of the CLR and the .Net frameworks. Take a look at CLI languages. It’s big. This gives developers the ability to use libraries from other developers and still work in their preferred language.

In the end I’m not so sure Apple needs to do anything. They’ve build, and continue to build, a great developer ecosystem. The Cocoa Framework is mature and is a huge benefit to iOS and Mac developers because we get a lot of shared code between the two.

Do we need scripting languages? Absolutely! Do we need them to build high performance native applications? Not really.

I’ve keep harping on this next point. Where we need advancement is in the browser. It’s locked in JavaScript hell. The browser is the new OS. The browser really needs a full CLI implementation.

If you have some time to kill download the episode. I really enjoyed it.