Scripting and the iPad

I’m happy to see that Alex Payne has retracted some of the ill-considered things he said about the iPad back in January. While it would be nice to think that his change of heart came from listening to his elders, the real reasons he no longer thinks of the iPad as the harbinger of a computer dystopia are

  1. he’s a smart guy and willing to question his own views; and
  2. he now has an iPad and likes it.

In fact, this latest post of his has one really good criticism of the iPad:

Apple should lift restrictions on running interpreted code on its mobile devices. Let people run Basic, Python, and Ruby interpreters on iPad and iPhone; we could make amazing tutorial applications for these and other programming languages. Let them run emulators for obsolete devices so intellectual property for them that has passed into the public domain can live on. Given that users can do much of this by virtue of Safari containing a JavaScript interpreter, the restriction seems arbitrary and backwards.

Of course, I say this is a good criticism because it’s my criticism. The apparent inability to script the iPad is the main reason I won’t be getting one—at least for a while.

What do I mean by apparent inability? Well, certainly you can’t use Perl, Python, or Ruby (or Basic or AppleScript or any other language best not to think of on a full stomach), but the iPad is sort of scriptable. As I said in January, the presence of Numbers gives the iPad an interpreter—assuming that IF, AND, and OR are among its 250 predefined mathematical functions.

More important is the JavaScript interpreter. We’ve certainly learned over the past few years how “real” web apps can be. Of course, you need space on a server to deliver web apps, and your iPad needs an internet connection to access them.

Or does it? One of the iPad’s most interesting features is the ability it gives apps to share certain types of files with other apps. Here’s Andy Ihnatko’s description of how it works:

The iPad OS still denies onboard apps the ability to access each others files and data. But there’s a mechanism that lets these apps tell the OS “Here are a list of filetypes that I know how to handle” and also to allow the user to easily steer a file to an app that can edit or view it.

If your boss emails you a Word document and you tap the document icon, Mail will present an “Open In …” button. Tap it to bring up a list of Word-compatible apps on yor iPad. Select the app you want, and the app will launch and import the document.

Any app can implement this and add its known filetypes to the service. A comic book reader can handle .CBR and CBZ files; a photo editor might offer to handle .PSDs … etc.

The feature delivers a lot of solutions in the ongoing problem of moving docs on and off the device. If you use a cloud storage service like Box.net, for example, the Box.net iPad app can present you with a list of all of the desktop documents you’ve saved in the cloud, and allow you to import and edit them into any appropriate iPad app.

One would think, then, that Safari would tell the OS that it knows how to handle HTML files,1 and you could, therefore, run certain web apps—those that are self-contained and don’t require communication with a server—locally. No one has confirmed this, despite my plea on Twitter.

As I learned quite a while ago, you can run self-contained web apps on the iPhone, but not in Safari. You have to use one of the many transfer-and-view applications, like Olive Toast’s Files. Unfortunately, in my limited experience, these apps don’t provide a user experience as good as Safari’s.

So, iPad users: can you answer my Twitter question. Can you transfer HTML files to your iPad and open them in Safari? Because if you can, that opens up a much broader realm for scripting.

Update 4/7/10
In the comments, reader jih mentions data: URLs as a possible workaround if there’s no way to open local HTML files in Safari. These data: URLs work on the iPhone, so I see no reason they wouldn’t work on the iPad. Here’s a simple explanation and example.


  1. And possibly CSS and JavaScript files, too, although it can only handle them in the context of an HTML files. In practice, it’s the ability to handle HTML that counts, because the CSS and JavaScript can always be embedded.