The story of Flash on the iPhone is interesting.

I don’t want flash on my iPhone, to be honest, and I don’t want it for all the reasons Steve Jobs said in his essay yesterday. Firefox is a lot more stable if you don’t install flash, so is Chrome. Apple say that Flash is the number one reason for crash reports in OS X.

However, I said in my last thoughts on the subject that the iPhone isn’t very ideologically sound. I cut out the paragraph explaining that, because it distracted from the main point, but it’s probably worthwhile anyway. One of the main complaints about the iPhone from both a metaphorical software point of you and a literal hardware perspective, is that that it lives in a hermatically sealed environment. Partly, this is a function a phone OS developed in the US mobile market, which has always been more closed than the European one. You can make less hermetically sealled by jailbreaking it, but the process of Jailbreaking an iPhone is basically a three-shell game with firmware revisions, and if this doesn’t go 100% smoothly you may end up with a phone that no longer has any concept of such things as “how to respond to the on switch”. Apple’s approach appears to be to make this three-shell game slightly more complicated – more out of due-diligence to the phone companies who say you can’t run custom software on a phone than because they hate us – but every so often do things like rewrite the entire bootloader to make it 30% faster, with the side effect that there are now *five* shells and two of them are made out of explosives.

All of this is because most of the US phone network is built of sticky-back plastic, string, hope and tangerines; and this has traditionally lead to the US phone networks making an absolute – and somewhat paranoid – ruling that nothing not personally signed off by the network could be executed on a phone , just in case it went ballywacky and managed to bring down the entire local phone network (GSM, the mobile phone network protocol we use in Europe and that is beginning to take hold in the states, has a couple more safeguards). This has existed since days of Java apps. The years before the iPhone, where people could grab java games and apps and put them on their phone? The US missed 90% of that, because building an app for java in the states meant submitting every new build (and a java app needs to have several different builds for each version, because no two phones have the same capabilities) though an expensive, arbitrary and somewhat brittle certification process *per network* whose phones you wanted to run on. This is why the iPhone was such a revelation to the US market, it was a phone that didn’t suck on a fundamental level (Most .eu phones – being GSM – didn’t make it to the states. The most popular phone up until the iPhone there was, I believe, the Motorola Razr, which is a device with a user interface that actively wishes you to THROW THE PHONE UPON THE FLOOR AND STAMP ON IT WITH MIGHTY BOOTS).

Anyway, the upshot of this was that the iPhone had no capability to add software on launch – it was scary enough as it was for AT&T, being a phone they didn’t have enough control over – but even when they added the App Store for revision 2 it had no hooks for it to take over any of the phone’s basic features. In fact, the App Store official policy states that you cannot post to the store any app that duplicates existing iPhone functionality, and even if you could, there simply aren’t the “hooks” in the system to say “When you get a phone call, run this app instead of Phone”, or even “Use this app instead of the email client”.

Most of the reason for that appears to be control-freakery. Apple’s primary selling point is simplicity of use, that you do not need to know how to work it to work it, and stopping an arbitary app you install from being able to modify what happens when you click on an email address in an SMS is part of it. There is a way that an iPhone works, and this is it, everything else is in its own little sandbox.

Recently, they’ve made steps towards building a climbing frame in the sandbox that things have to build upon. The idea of an app that works the same on Android as on Palm as on iPhone isn’t good for them, because it won’t follow the UI guidelines for iPhone applications in order that, by having used an iPhone application, you roughly know what this button on this other application is going to do. This is actually important to Apple, which is part of the reason they put the block on cross-compiling applications. I agree with this, for the most part. The easist route for an app *should* be the one that follows the UI guidelines for what they are releasing it on, and doesn’t look entirely out of place on the phone.

However, it should be a fence. A short fence, white picket, which can – if necessary – be stepped over. It should not be a wall. For example, Safari and iTunes for Windows both look exactly the same as their Apple counterparts. Partly because maintaining one lot of code is easier, partly because they’re adverts for how shiny a real mac would look. They both follow some guidelines – the window manipulation buttons aren’t arbitary trafic lights, the application closes when you press the close button (not just the window), iTunes even integrates with the taskbar to provide a mini-player when minimised, if you want it to. Microsoft didn’t block iTunes from Windows because it looks entirely out of place (Which is fortunate, otherwise they’d have had to block Steam, Xfire, Winamp, Sonique, and thousands of apps down the line, including Office 2010. Also IE8).

So, basically, it’s not your decision, Steve. It should be mine.

That’s why I’ve just ordered an HTC Desire. I may go back to the iPhone, but at least this way I can pick my own variety of battery drain for a while.