Category Archives: iPad

I’m currently reading a book called “Beautiful Architecture“. This has at its core the concept that some software structures are inherently elegant, things of beauty as well as great function, like many of our greatest buildings.

The trouble is that for every St. Paul’s there must be a Bletchley Park – an architectural mish-mash which while possibly important, successful or even revered is inherently inelegant, or even downright ugly.
My analysis is that behind the glossy facade, the iPad software architecture has to be the best current example of “Ugly Architecture”.

In many ways it’s strongly reminiscent of PCs in the days of DOS, or maybe Windows 3.0, before the emergence of strong component-based architectures and unifying design standards in Windows 95 and NT.
The fundamental problem is the application-centric model, in which each application is a stand-alone combination of code and data, with very few shared services or components. This naturally leads each application developer to “do their own thing”, implementing separate, widely varying solutions for communications, document storage, printing support and so on. Apart from a token “open in another app…” supported by some applications, there’s effectively no cross-application linking, leading to massive duplication of functionality and data, and some significant functional limitations, for example the inability to directly open a URL embedded in a document.

Each application has its own data area, which may or may not interact with iTunes, web sites or a PC via FTP, websites via WebDAV or various different cloud storage services. Data which should arguably be general visible just isn’t – you can upload video files to the photos area, but they won’t be visible in the videos list. To test a variety of editors with a document you need to deliver a different copy of the document to each app.

Each application supports different models for document exchange, and different cloud stores, so a user potentially has to have multiple separate cloud accounts. While “public” cloud storage may be fine for individuals’ personal data (although individuals may still have valid security and privacy concerns), it is a real concern if used for corporate information. In corporate contexts, connectivity, security, copyright, access rights, service levels, data protection and privacy obligations, regulatory and legal constraints may all be compromised or complicated by cloud use, and become significant issues.

There’s also an interesting security implication to this which you don’t often see discussed. Because there’s no accessible file system, and no extensibility model for the application filing model, there’s nowhere for anti-virus solutions to run, and as of today iPhones and iPads are effectively unprotected devices. There are probably numerous iPads in the wild acting as festering reservoirs of infected documents. Those who are security conscious can’t be happy about this, and I know that many corporate security departments are making moves to ban connectivity to corporate services for that reason.

Even if an application interacts with the host PC more directly, you get multiple copies of documents, typically the original, a copy in iTunes and one on the device, with no mechanism to synchronise them or compare version information. Apple’s own applications such as Pages are even worse, with a completely separate iTunes space from their own “My Documents” spaces, and an additional copy step in each direction. This is a version control and management nightmare!

Why could the iPad not support a simple shared filing area with proper two-way synchronisation to the host PC, as the Pocket PC has had from day 1?

The communications architecture is a similar mess. The only application which can communicate with the host PC over USB is iTunes, but iTunes can’t use WiFi. All other apps have to use WiFi, but there’s no real shared comms application infrastructure, so the result is another diverse and fragmented “roll your own” free for all. The most obvious way for a companion device to talk to its host PC, BlueTooth, isn’t supported at all!

The WiFi only design works fine in the confines of, say, a small home office. Elsewhere it’s problematic at best. Paid WiFi (e.g. in a hotel) is typically limited to a single device, so you’ll end up paying twice if you want to connect both devices. Corporate WiFi systems are typically similar, and you may not be allowed to connect the iPad directly. Even if you do get connectivity, these networks are often set up to prevent routing between devices, as a security measure, so that’s that, then.

The alternative is to set up either the PC or iPad as a hot-spot itself. On the iPad, this is only possible on jailbroken devices. On the PC, it can be complicated and opens up potential security issues. Neither is ideal.

Apple’s policies effectively put software development back in the Stone Age, in the particular sense that “monolithic” means “single lump of rock”. Each application has to be “stand alone”, implementing many things which should arguably be shared. For example, each file management application implements its own storage management dialogs, its own comms model, its own browser, its own PDF and Word file viewers, each with their own subset of functionality, dialogs and gesture support, and so forth. There simply doesn’t seem to be any real concept of shared components or companion applications. Let’s be clear: I’m not criticising the application developers for trying their best to provide a comprehensive solution – my criticism is directed squarely at the crass architecture through which Apple force such an approach.

Even those applications which implement the “open in another app…” capability to open documents in other viewers suffer two common problems: you frequently have to open the document natively before you can send it elsewhere, and the act of doing so usually creates yet another copy of the document to manage separately! 🙁

Ironically, where there are shared components they impose significant constraints and limitations. The most obvious is the keyboard. Essentially there’s only one way to get text directly into any application, and that’s to use the on-screen keyboard configured exactly as the application developer decides. It’s “my way or the highway”. This is a dramatic contrast with the Microsoft world, where even a humble 2003-era Pocket PC supports not only a variety of built-in and third-party on-screen keyboards, but also handwriting recognition, character recognition (like the Palm Pilot), Swype, and even limited voice recognition. Importantly, these are all user-selectable at any time text input is required. On the iPad you can buy an app with a different keyboard layout, or dictation capability, but you have to cut and paste the raw text into your target application and typically reformat it to suit. This is simply primitive.

What makes all this worse is that the iPad application approval/delivery model makes it unlikely that anyone will innovate a better solution. No approved application can have legal access to another app’s or central iTunes data. Without approval, you won’t appear in the App Store or run on non-jailbroken devices, so Apple simply impose their will, whether good or bad.

OK. I am starting to love my iPad, but the software architect within me is incredibly frustrated. This great hardware is hamstrung by a clumsy, unimaginative, software architecture and oppressive centralist control by those who worship according to The Book of Jobs. It could be so much better.

</rant>