Adobe vs. Apple

Apple and Adobe have been having a rather public tiff about the use of Adobe’s Flash on Apple’s mobile platforms, the phenomenally successful iPhone and iPad platforms. I’m going to have to split my response to this into two logical parts:

1. The Web

Flash is predominantly used as a container for video content, Flash-based games, and the occasional little widget. Almost every other use is a disaster; I’m sure we all have horror stories of terrible Flash-based websites.

Apple’s argument in this space is one I completely agree with: letting one company, with one proprietary implementation, control several important classes of web application is just wrong. Emerging standards like HTML5 video and canvas tags, and support for them in all the major browsers (Chrome/Safari, Firefox, IE9)  mean that we have no need to stick to Flash. Even if we were to assume that Flash was high-quality, secure, performant, and stable, which it isn’t, letting it have total control of web video would be an incredibly bad idea. The sooner it dies a miserable death, the better for all of us.

2. For The Writing of Cross-Platform Apps

This one is somewhat more of a grey area.

First off, let’s be honest; Flash doesn’t help you build cross-platform apps. It helps you write apps that run on Adobe’s platform. They want you to write Flash-based apps for the same reason that Microsoft wants you to write Windows apps, or Apple wants you to write iPhone OS apps, or Valve wants people to use the Steamworks APIs: they want you locked to their platform, for their own business reasons. There isn’t any altruism here, no matter how much Adobe wants to play the martyr.

This is why Apple is refusing to let apps which target Adobe’s platform to run on their OS. Adobe are making a power-play to subvert Apple on their own platform, and Apple are rightly telling them to go fuck themselves. It’s not an unreasonable position, even from a user’s perspective. One of the reasons that Windows is a cluster-fuck is that fundamentally Microsoft lost control; they need to keep backwards compatibility with almost every Windows app ever written, even the ones that don’t play by the rules and call undocumented APIs in broken ways. That’s a millstone around their neck, preventing them from ever moving quickly. That situation is good for nobody; it hurts application stability, and it hurts innovation.

On the other hand, Apple are keeping control with an iron fist, in a fairly velvety (albeit thin) glove. Call undocumented APIs, don’t natively target Apple APIs, you get bounced out. On the other hand, it means Apple can keep nimble. They know that because all their app developers are playing by the rules, they can change things rapidly. Change CPU architectures? Boom, most apps will just recompile without needing changes. Stick a third-party toolchain in there, and you get unpredictable effects; every app using that third-party system could stop working.  What if Apple want to add new features? If Apple exposes a new API, native apps can start consuming that API straight away. They don’t have to wait for a third-party platform to figure a way to pass through that API, if they ever do. They don’t have to worry about developers only targeting the minimum common feature set.

It’s a Faustian pact. Nobody is denying that. If you don’t like Apple’s strategy, you don’t have to buy an iPhone OS device.

For the moment, I’m happy with the trade-off. When I decide on my next phone, you bet I’m going to look at Android. But I’m happy right now, and I quite want an iPad…

Anyways, if you really want to write cross-platform code, you do it the same way we’ve always done it. Write core code in C++, staying agnostic as possible to the real environment you’re running in. C++ pretty much works everywhere. Hooray for open standards! Also, on another note, I also think that half the time the FSF is full of shit. Or to be less inflammatory, they’re so committed to their ideology that they’re blind to reality. But that’s a story for another day.

Leave a Reply

Your email address will not be published. Required fields are marked *