Adobe vs. Apple or Flash vs. HTML5

Any of you watching the recent iPad coverage may already know that the iPad not only does not support Flash, there is no intention on the part of Apple to support Flash. Granted, the iPhone doesn’t support Flash, but neither do most other mobile devices. iPhone users had been complaining about this for a while and Apple cited its policy toward acceptance of software from third-party manufacturers as a reason not to expect it (“Why Apple Won’t Allow Adobe Flash on iPhone,” Wired, Nov. 17, 2008).

With Apple’s pitch that the iPad would replace netbooks and slide into the average user’s hands as the de facto web surfing platform, hopes were high that the iPad would support Flash. The original iPad promos even showed Flash in use, but those were quietly changed without any acknowledgment from Apple (“Apple Pulls Flash Content From iPad Promos,” PCWorld, Jan. 30, 2010).

In the last couple weeks things have heated up even more. Apple modified its iPhone Developer Program License Agreement (part of the iPhone OS SDK) to expand on a section covering how external applications can be developed:

3.3.1 Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++ or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++ and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

While Flash Player 10.1 is now available (or on its way) for other mobile devices (Android, Symbian, Windows Mobile, webOS and BlackBerry), the iPhone is still not having it. This new language essentially blocks a utility Adobe created to allow Flash developers to convert their Flash projects to the iPhone app format. And that utility still didn’t bring Flash support to Safari on the iPhone (“Adobe Announces Flash Support for iPhone (But Only for Apps),” Mashable, Oct. 5, 2009). On the bright side, Adobe is also planning to support exporting to the HTML5 canvas element.

Apple has been quick to point out that anything you can do in Flash can be done in HTML5. Not only is this patently not true (primarily because HTML5 isn’t even a finished spec yet — see “Too Soon to Advocate HTML5?” at this blog), the Safari browser doesn’t support it all (CSS3 and HTML5 support checklist). Given how many sites use Flash for even basic features like non-critical content or add-on features, the average web surfer on his or her iPhone/iPad will just see blank areas where Flash should appear. Apple is free to limit its support at no cost to itself, but if companies truly want their Flash-specific features to work on an iPhone or iPad, they now have to consider not only how they might technically do that, but how much they are willing to spend to achieve it.

If you’ve known me or read my posts for long enough, you know I have generally considered Flash to be a usability and accessibility nightmare, primarily because Flash developers have often abandoned best practices and made up their own rules for interaction. And I’ll just gloss over search engines by only mentioning them in this sentence, because that’s just low-hanging fruit for an anti-Flash rant. But while Flash may not be my ideal method to build things, it’s also a de facto standard for many aspects of current web design — animated objects, integrated video, interactivity. Yes, much of this can be done using HTML and JavaScript, but the Flash development environment allows many companies to develop features for their sites at a relatively inexpensive cost and not worry about cross-browser scripting issues.

A handful of companies are already re-orienting their sites or at least their strategies, but these are companies who know they have to target iPhone and iPad users (“Virgin America Ditches Adobe Flash for New Site” at Mashable, March 3, 2010). They are also companies who have the budget to do it. For the rest of us, the best thing we can do is continue to watch the battle between Adobe and Apple and see where it goes. I predict no winner. However, I do see the losers in this battle — end users and smaller organizations who cannot afford a rebuild.

Related News

4 Comments

Reply

Erik, that 37signals article is great. The author does a nice job of making a case against Apple's policy, smartly noting that it's not about Flash, it's about Apple's policies. The comments are a good read, too.

The other one is not so much funny as it is painful. I enjoyed it, though.

Reply

While Apple clearly has it in for Flash, section 3.3.1 is less about Flash Player/CS5 than it is about development platforms for the iPhone OS.

Apple simply doesn't want third-party dev tools to be available. There are a lot of reasons for this: UI aesthetics, locking in devs to Apple's way of doing things, generating more revenue (since you have to use Mac HW), etc.

Reply

Except Apple already allows this in the form of Lua, which is how EA and Tapulous (among others) develop their iPhone applications. I think if Apple didn't feel threatened by another maker this wouldn't be such an issue. It's a function of control, which in itself is not a bad thing. The way they've gone about it, however, has been pretty poor.

Leave a Comment or Response

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>