iPad an Impediment to Document Innovation

The popularity of Apple’s version of computing and the web has the potential of stifling innovation in non obvious ways. Interactive document formats are a case in point. Here Apple has two sets of rules: if you are Apple you are free to innovate, if you are not Apple you must innovate on top of HTML5 and Javascript. Are official World Wide Web Consortium standard languages sufficient tools to deliver cutting edge document functionality? The answer is no, as I will show below.

Here is an excerpt of Apple’s licensing limitations:

3.3.2 An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded and used in an Application except for code that is interpreted and run by Apple’s Published APIs and built-in interpreter(s).

From this we learn that rich, interactive document formats that require scripting must use a language that is already available on Apple’s devices. If that language is not good enough or not tailored to the environment (e.g. 3D scripting) then you are out of luck. If another manufacturer were to have similar rules but supported different languages (e.g. VBScript) then making a cross device/platform document solution would not be allowed.

In fact the rules are even more stringent because the only built-in interpreter is Javascript, and it is only available from within Webkit, and you can’t used it to manipulate your own document object model (DOM). Meaning the only content you are allowed to script is HTML. That means other interactive document formats are just plain verbotten.

There are some pretty reasonable and popular document formats out there that are not HTML. PDF and Excel spreadsheets are but two examples. PDF actually supports interactivity in several ways, including embedding Javascript (a basic use is to do the math in PDF forms) and 3D. The forms Javascript is an older variation that is not compatible with the Apple-provided interpreter (you can’t really update 10 year old documents nor call Adobe lazy for not doing so). Even if it were, the Javascript has to bind to a native DOM, and Apple’s Javascipt interpreter does not allow this.

Apple Preview supports a subset of PDF but does not support embedded Javascript. Rule 3.3.2 forbids an application from supporting PDF with Javascript. This is unfortunate, because I could have seen the iPad as being a great, portable platform for using PDFs with rich forms entry and calculations. Actually this still could happen, but we must depend on Apple for the implementation.

Looking further at PDF, PDF has 3D capabilities that by their interactive nature require scripting. The existing scripting engines provided on Apple devices (Javascript) just don’t cut it. 3D is the type of technology where developing the language is part of the innovation. Flash has similar, advanced rendering capabilities that are not available in HTML5 and Javascript. Essentially, therefore, innovation of this type becomes stifled.

Excel spreadsheets seem to not be allowed because they use formulas that are not written in Javascript. iWorks gets away with providing excel support because, well, all iPhoneOS developers are equal, however Apple is more equal then others. [This is speculation, as I don’t have direct knowledge of spreadsheets.]

Apple is essentially killing these formats on their devices, which means the formats are no longer universal. The only workaround is for the formats to avoid interpreted code, which is limiting as well as impossible to do retroactively on already widely used formats (though, as the person responsible for digital signatures in Acrobat, I will cheekily point out that I’d have welcomed a less-interactive version of PDF that was more stable when signed).

Some argue that the iPad is open because it supports native apps. I hope I am showing you that this is not a wide open field for those native apps. The apps being written are mainly lighter weight apps and tend not to be innovative platform applications on the scale of iTunes, Acrobat, Excel or a browser (note the emphasis on mainly and tend).

What about the next new document format? Look at what Wired did with their first magazine app. They essentially took screenshots of the pages, created an XML manifest of the contents, and added a bit of animation. Some are accusing Wired of being lazy, saying that they should have used HTML5 and Javascript. Perhaps they should have, but the argument is that they required and could not achieve pixel perfect rendering with HTML5. As well, HTML5 and Javascript weren’t decreed to be the standard until this year, and we can assume that Wired had legacy work targetting different formats. Here the onus is on the Wired to adapt rather then what normally happens, which is for the platform provider to provide adequately for content generators. If Wired, or someone else, wants to innovate beyond what HTML5 + Javascript delivers, what do they do? The answer is that they are stuck.

Unfortunately all this is more evidence of the control that Apple is exerting over software development and the internet, and getting away with it because they are so good at what they do. They are the first company to explicitly ban capabilities from a general computing device (rather then mobile phone). They have enough of a foothold with content consumers that content generators need to take heed. Wide success will serve to chop off any pre-existing non Apple file formats at the knees, and serve to deter future cross platform formats by pigeon holing developers to use HTML + Javascript.

What we had all hoped for in the mobile market is that these devices would adopt the open PC model. That partially happened with Apple allowing a play-by-Apple-rules set of apps onto mobile. This was so much better then what existed before. Unfortunately what we are seeing is Apple’s not-quite-open mobile model being extended to the PC. This is a scary vision.

Further Reading