Ongoing Misunderstanding of Flash and HTML5

The latest article that uses absolutes and broad generalizations to imply an otherwise non-existent struggle between Flash and HTML5 is from UX Booth, "What the Demise of Flash Means for the User Experience." To be fair to this article, I see regular missives on Flash vs. HTML5 and this particular UX Booth article is just an example of many of them in one easy to cite place.

The opening gives away the false premises for the rest of the piece:

Adobe's decision to cease development of the mobile Flash platform and increase their investment in HTML5-related efforts created perhaps the final piece of conclusive evidence that HTML5 is the current go-to technology for creating ubiquitous user experiences regardless of device.

First I have to accept that the author is talking about more than the HTML5 specification and is also referring to CSS3, JavaScript, and the W3C specifications that are related to HTML5. This lack of clear delineation chips away at the argument.

Adobe has held that the fragmentation of mobile devices is too hard to keep up with on its own. Flash will still exist for mobile wrapped in AIR applications instead, and Flash is not going away from the desktop. Adobe's decision to increase investment in HTML5 (via Edge and to a lesser extent Muse) is mostly unrelated since there is a market for an HTML5 authoring tool independent of Flash.

Not only is this neither conclusive nor the final piece of evidence that HTML5 is the current go-to technology, this is anecdotal evidence at best. In addition, HTML5 itself is nowhere near complete and the element often regarded as the Flash-killer, canvas, isn't anywhere near as robust as Flash and still lacks strong scripting or styling support in the specs.

I think it's fair to challenge the claim that HTML5 creates "ubiquitous user experiences regardless of device" when you consider all the polyfills and shims that need to be implemented to create similar experiences on a few devices. It's also fair to say that my netbook does not handle some of the related HTML5 specifications the same as my tablet or mobile phone, partly due to various levels of hardware and browser support. Let's not even get into video and audio codecs or the touch events specification (neither of which are part of the core HTML5 specification).

HTML5 excels at giving users a delightfully inconsistent experience on any device through the concepts of "graceful degradation" and "progressive enhancement."

Those terms pre-date HTML5 and I can do both with HTML4 and CSS2. The author continues on and cites responsive design as a feature of HTML5, even though my own site is an example of an HTML4 site using responsive design to adapt to assorted displays.

Additionally, more than 90 percent of all smartphones and tablets are HTML5-enabled, which means that all the benefits of HTML5 can be utilized today to provide impressive mobile websites.

The author's math doesn't bear out the assertion — by the author's numbers, 10% are not HTML5-enabled and so cannot benefit from HTML5. For the other 90% that are, even they cannot enjoy all (author's word) the benefits of HTML5 today.

Making or upgrading to an HTML5 site can be as minimal as simply using HTML5's doctype [...]

The implication here is that simply changing a doctype gets you all the benefits of HTML5, when in reality you still have the same HTML, CSS and script.

The post never does answer its own question — what does the demise of Flash mean for the user experience? From the article, more HTML5 use. In itself that doesn't tell me how the user experience is affected, just how developers are affected. If the developer does a good job, the user experience doesn't need to change. The user shouldn't need to worry about the underlying technology.

Too many HTML5 articles and posts today, like this one, work to promote the markup language (and usually CSS3 and JavaScript, even if they don't know it) by contrasting it against another technology that is falling away or is just a popular target of derision. The pro-HTML5 cheering is easy when another technology has already been recognized as out-of-date, but this doesn't do anything to advance HTML5 and its related specifications.

I'd love to see more practical discussions of what HTML5 (and related specs) can do today along with all the nifty experiments that are moving the collection of specifications along.

Update: May 8, 2012

The BBC makes this same set of mistakes in its piece Coding the future: HTML5 takes the internet by storm.

Flash is Dead! Long Live Flash!

Re-posted from its original home on the Algonquin Studios blog.

A lot of news has been made of Adobe’s recent move to end development of the Flash player for mobile devices (such as your smartphone or tablet). Even people outside of the tech community have heard about it and are trying to understand what it really means. I wrote up the details last month (Flash Isn’t Going Away, Except from Your Mobile) and tried to remind everyone that Adobe isn’t giving up on Flash, it’s just changing its direction on its mobile player based on industry trends.

Consider that Apple won’t allow the Flash player on its iOS devices, and that the mobile version of Windows is following suit. Consider that web developers are (finally, after a decade now) starting to focus on standards-based web development and accessibility. Consider how many different mobile devices and browser combinations exist, requiring Adobe to develop a Flash player for each.

Much of Flash on the web has been used to deliver rich multimedia experiences that either don’t translate well to mobile browsers (giant file sizes, areas too small to “click” with a finger, optimized for large displays, etc.) or can be replaced with new HTML capabilities which mobile browsers tend to support now without the Flash player (such as the lowly Flash video player).

Add all these factors together and it doesn’t make sense to push the Flash player to mobile devices any more. Adobe is instead using AIR to allow Flash developers to build native apps on the phone, bypassing the hassle of the browser plug-in altogether and still allowing those legions of Flash developers to do what they do best.

Here’s where people get confused — Flash as a platform isn’t going away. Regardless of the hype you hear about HTML5, HTML5 (including CSS3, SVG, and so on) just doesn’t have the capability (whether via the specification or by browser support) to do what Flash does. Flash is the only technology that can currently do what Flash does for such a broad audience. Its ubiquity across the web (98% installation) has guaranteed that users see what the developer wants, regardless of platform; regardless of whether or not what the developer created is any good.

This doesn’t mean we are Flash-crazy over here. Quite the opposite — we have historically counseled against Flash for web sites for many reasons, some of which are simply because it doesn’t address the goal. As we develop sites that are both mobile-friendly and desktop-friendly, we are increasingly coaching our clients on the right technologies to use to achieve their goals. Our position on Flash isn’t changing because of Adobe’s move, Adobe is simply reflecting the trend.

You can expect to see less Flash in web pages on your mobile, but you can also expect to see more of it behind the scenes in apps for mobile devices. As for your desktop browser, Adobe will release Flash players for years to come and people will still develop in it for as long as it takes HTML5 and its related specifications to finalize the rules and for the browsers to support them.

Flash Isn't Going Away, Except from Your Mobile

You may have heard some rumors that Flash is going away. You may read it as vindication for Steve Jobs. You may have decided web development will now change. You may be under the impression that HTML5 can do all the things Flash can. You can be excused when you read much of they hype, including such link-baiting headlines as Jobs Was Right: Adobe Abandons Mobile Flash Development, Report Says, clearly intended to draw Apple fanboys. Some of the news today:

• Exclusive: Adobe ceases development on mobile browser Flash, refocuses efforts on HTML5 (UPDATED)
• It’s Official: Flash Mobile Player is Dead
• Adobe stops developing Flash for mobile

Before we get too far ahead of ourselves, this cessation of development is for mobile devices only (read Adobe's release). I also want everyone to take a deep breath and stop crediting Apple with this. Adobe has long been unable to make a Flash player for mobile devices with a small enough footprint to not feel like you are wading through pudding to see some pointless animation (or worse, a navigation bar). The iOS market share in the mobile space is still below Android's (suggesting to me that Apple cannot kill it on its own), but Flash's ability to play well on anything in the mobile space is still below all of that.

We can expect this to affect how Flash will be implemented on other sites, but not immediately. Web developers worth their pay are moving toward adaptive layouts that scale and reformat themselves for mobile devices. These developers have mostly excised Flash from their toolkit because it doesn't play well with these new approaches. Younger, less experienced developers, along with developers trapped in 2001, will still use the only tool they have (insert hammer/nail metaphor) until they have exhausted it.

As someone who has been resistant to Flash on client projects for years, partly because of accessibility concerns and partly due to its resource demands, there is no love lost here for the platform. I am happy to see it wander off into a corner and yield right-of-way to CSS3, HTML5 and its related specifications. Over 10 years ago, when Flash was already causing stress to web developers and user interface designers, Jakob Nielsen finally got on board with his article Flash: 99% Bad. Today is just another step in a much larger process of web standards development, even if Flash wasn't an official one (de facto has carried it this far).

In the meantime, expect to see Flash persist on the web of desktop browsers and expect to see it persist in old, forgotten sites for years (perhaps most of the restaurant web sites I see). Until HTML5 can figure out what it wants to be when it grows up (End of time Is Not Helping the Case for HTML5) and the debate over video codecs truly ends (Are Patents Killing HTML5 Video?), things aren't going to change for most of us very soon.

I am intentionally skipping the discussion around Adobe's statement to more broadly support HTML5, since it's not really news given its latest products. I'm also skipping the statements from Adobe about using Flash to feed to app development platforms like AIR since I think we all have seen that move for a while now.

Related (on this blog)

• Adobe vs. Apple or Flash vs. HTML5, April 12, 2010.
• Adobe to Drop iPhone Support, Target Android, April 21, 2010.
• More Salvos from Apple and Adobe, to No One in Particular, May 13, 2010.
• More on HTML5 as DHTML, August 8, 2011 (for the Adobe Edge points).
• Thoughts on Muse (Obvious Pun Avoided), August 16, 2011.

Update November 10, 2011

As I suspected, the hype is starting to settle down after a day has passed. Some more news bits with more of an overall perspective:

• Adobe axes Flash for TVs too at CNet.
• Mobile Flash ISN'T dead at ZDNet.
• Some Thoughts On Flash And Devices by Ben Forta of Adobe.

Thoughts on Muse (Obvious Pun Avoided)

I downloaded and installed Adobe's new web design tool, Muse (code name) (also at Adobe Labs) out of morbid curiosity. Just like Adobe Edge (which refuses to launch), I had very little expectation that this would be a fully-developed sales-ready product. Instead of getting into extensive detail about the quality of its code, its accessibility support, and so on, I figured I'd do a very quick review of how I think it affects web developers.

The target audience is pretty clear from the Muse (code name) web site introduction:

Create websites as easily as you create layouts for print. You can design and publish original HTML pages to the latest web standards without writing code. Now in beta, Muse [(code name)] makes it a snap to produce unique, professional websites.

And this:

Design your pages
Focus on design rather than technology. Combine images and text with complete control, as flexibly and powerfully as you do in Adobe® InDesign®.

Right there is the gist of the product — enable print designers to convert their designs into web pages. Just like Photoshop would produce massive image slices to support Photoshop "designers," this product isn't about the code. With its integration of jQuery effects and Lightbox widgets, it seems almost like this would be a tool for a photographer to build a gallery site.

If you are a coder, or someone who cares about the code, this tool isn't for you. You will quickly see that the HTML is produces is not exactly structural or semantic, and that the piles of CSS and JavaScript aren't exactly necessary. Muse (code name) doesn't allow you to edit the HTML, so you still need to "publish" your work before you can edit it. If part of your coding process involves making your HTML meet accessibility standards or even just structure your content for good SEO, you will find it impossible.

If you are part of a web team, perhaps in an ad agency or interactive firm, then you will find that this tool doesn't allow you to collaborate well. If you get a favicon, for example, from another member of your team, Muse (code name) cannot import it; it only accepts PNG, GIF or JPG. If you receive a background image to drop into an element, Muse (code name) will crop the image, even increasing its dimensions to fill the element, regardless of your plan to allow more of the image to be revealed should the container change in size.

If you find yourself pasting HTML code from Google Maps or Twitter in order to embed third-party widgets on your site, you may find that is nigh impossible short of publishing your pages and then hacking through the HTML output. While I did not find a menu option to do that, even if it exists it will require a full "publish" step every time you want to tweak your embed code.

If you find yourself leaning on CSS techniques as simple as printable styles or as complex as media queries to support alternate display sizes, you will be disappointed. This tool is not intended to support liquid designs, adaptive layouts, document re-flow, or really anything related to alternate viewing.

If you support a web content management system, then for all the reasons above Muse (code name) is not a good fit. Just building a single page to use as a template will require a great deal of work to reformat the code to fit into most content management systems that are out there. Should you ever have to change the core template you either have to go back to Muse (code name) and repeat the process, or you will have to skip Muse (code name) for all future revisions.

In short, it comes down to these two key points:

1. Muse (code name) has the potential to be a great tool for the single graphic designer interested in showing off his or her work without having to learn a technology outside of his/her knowledge area (nor worry about accessibility, standards, alternate displays, SEO, etc.);
2. If you are a web developer (or web development firm), your job is not at risk. Muse (code name) is making no effort to replace you. If anything, it might keep you from getting fewer calls from people who might not be good clients anyway.

If you are looking for a pedantic review of the HTML output, I suspect plenty of others will cover that. Since Muse's (code name) target audience won't care, and anyone who does care will already know the issues just by playing around, it's not even worth getting into here. Besides, with 120,000 other people downloading Muse (code name) after the first day, I expect plenty of reviews of the markup will come.

Now to Examples!

These aren't intended to be open shots at Muse (code name), but instead I hope someone at Adobe can use them to help better it overall.

This image shows how Muse (code name) looks on my netbook (I may have tweeted my frustration last night). As you can see, the menus are off the top of the screen along with every other useful feature. I was able to close the application thanks to standard keyboard shortcuts.

Using the default page size settings (960 pixels with a min-height of 500 pixels), this is the sample site I quickly cobbled together. I did not start with a design or goal other than throwing some elements on the page, so don't tell me my site isn't as awesome looking as it could be. Because it couldn't be awesomer.

What about the file output you ask? Here is the /css directory:

File name	Size (bytes)
articles.css	5,106
bio.css	5,106
blog.css	5,106
books.css	5,106
contact.css	5,106
ie_articles.css	5,009
ie_bio.css	5,009
ie_blog.css	5,009
ie_books.css	5,009
ie_contact.css	5,009
ie_index.css	5,009
index.css	5,106
site_global.css	4,305

The duplicates are for IE support and you can expect to see all your content in every page twice as it relies on IE conditional comments to serve up one copy for IE9 and one copy for anything below IE9.

Here is the /scripts/0.9 directory:

File name	Size (bytes)
jquery-1.4.4.min.js	78,766
jquery.museMenu.js	2,382
MuseUtils.js	9,317
SpryDOMUtils.js	14,604

Without those script files, those simple-looking menus on my example just don't render.

That background image I mentioned earlier? Muse (code name) re-cropped it and converted it to a PNG file, increasing both the dimensions and file size:

File name	Size (bytes)	Dimensions
Banner_bg.jpg	11,271	627 x 80	original image
master_U355_full.png	41,800	960 x 97	Muse (code name) -ified image

Related

• Developers respond to Adobe Muse at .net Magazine.
• Adobe's Muse (code name) site re-coded as XHTML 1 strict, dropping from 78k to 5k.
• Added August 25, 2011: ZDNet asks, as a response to Muse (code name) criticism, What is wrong with bloated markup? I answer in the first comment.
• Added September 2, 2011: Even FastCompany weighs in on this: Adobe's Muse Lets Designers Make Websites Without Knowing Code

More on HTML5 as DHTML

Guns don't kill people, the bullets do that (unless you pistol-whip someone to death, which means you probably ran out of bullets). Similarly HTML5, JavaScript, CSS and even Flash aren't dangerous on their own, but in the wrong hands and with the wrong motives they can do harm.

I wrote a post almost a couple weeks ago, Don't Let HTML5 Become the New DHTML, where I compared HTML5 with DHTML. I think it is an apt analogy still. Since then I have seen what I think is a spike in posts from people decrying poor development practices, ultimately resulting in whiz-bang sites that claim to be HTML5 but are really just platforms to demonstrate cool features for reasons that have no merit beyond "cool factor."

I have a theory on why there is a recent uptick in this general theme — Adobe released Edge, its tool to help enable HTML5 / CSS3 / JavaScript animation-style development and (wrongly) considered to be a replacement for Flash. As people downloaded it and played around with it, a trend started to emerge. People were looking at the code Edge generated and realizing it was all just div soup (Why has Edge gone with div-based animation over canvas and SVG?). I am one of the many people who downloaded and installed this pre-beta so that I could see what it produced. I was not so lucky to get it working:

I suspect once people saw this code, from software which otherwise is not production-ready (or beta-ready, as Adobe claims), the ideas of HTML5 as a Flash killer coupled with its tag soup output rolled through the heads of lots of people, and so began the posts. I have collected some here:

• Adobe Launches New HTML5 Design Tool, August 1, 2011.
• The Final days of Flash: Adobe releases public preview of Edge HTML5 editor, August 1, 2011.
• Devs respond to Adobe Edge, August 2, 2011.
• Reckless web development practices are encouraging idiots, August 2, 2011.
• Hello, Adobe Edge!, August 4, 2011.
• Primum non nocere, August 5, 2011.
• HTML5, hollow demos and forgetting the basics, August 5, 2011.
• Are CSS3 and HTML5 the "New Flash"? August 8, 2011.

I think comparing HTML5 to Flash is a mistake. They are not the same. Flash is and always has been a proprietary tool built to enable features otherwise unavailable in standard HTML, CSS and JavaScript development while offering a consistent experience for users.

DHTML, however, was just a fake-brand for HTML4, CSS2 and JavaScript. People now use HTML5 to refer to HTML5, CSS3 and JavaScript, along with some other standards-based technologies. I think the parallels are obvious.

Update: August 11, 2011

Web 2.0 was another one of those marketing terms which encapsulated different things to different people. Now its demise is predicted: The death of Web 2.0 is nigh….

Smokescreen Brings Flash to iPad, iPhone

Smokescreen - iPad demo #1 from Chris @ RevShockAds on Vimeo.

Now that it's clear that Apple has no intention of letting Adobe Flash run on the iPad or iPhone, workarounds for Flash are even more compelling to developers. Smokescreen, primarily by Chris Smoak, bypasses the need for the Flash plug-in by pulling in the SWF binaries and decompressing them in JavaScript, yanking out the images and audio and putting it all back together with the vector data rendered as animated SVG. Simon Willison got the details and posted the technical process on his blog:

It runs entirely in the browser, reads in SWF binaries, unzips them (in native JS), extracts images and embedded audio and turns them in to base64 encoded data:uris, then stitches the vector graphics back together as animated SVG. Open up the Chrome Web Inspector while the demo is running and you can see the SVG changing in real time. Smokescreen even implements its own ActionScript bytecode interpreter.

You can see demos of Smokescreen running StrongBad emails and ad banners at the site. If you are running Internet Explorer (any version), then these demos won't work for you. In general, you'll need the most recent versions of Firefox, Safari, Chrome or Opera to see the demos. A couple of them run on the iPad or iPhone and there is even a video of it in action for those who don't have either device (see above).

The Flash movies don't run quite as quickly using Smokescreen as they would in the native Flash player, but that's to be expected when all the work is offloaded to the browser's JavaScript engine (8,000 lines of code weighing in at 175kb). I also noticed that sometimes text embedded in the SWF file either didn't appear at all or had some odd anti-aliasing. Given how new this is, however, I suspect these are surmountable obstacles. Given that Chris plans to release the code as open source, more developers will likely be able to contribute to pare this down.

What would make this even more interesting is if Adobe lent its support in some way. Since this has the potential to reverse the trepidation Flash developers now feel thanks to the increase in iPads and iPhones on the web, it may stave off any doomsday scenarios for Flash. It may also blow up Apple's plans to ultimately push Flash out of the market altogether unless they want to stop supporting the JavaScript and HTML5 that this utility uses to render the former-Flash movies. It's still too early to tell which way either company will go with this, if they do anything at all, but I suspect it will be interesting to watch.

Related Links

• Smokescreen makes Flash content visible on iPhone and iPad (video) at engadget.
• Smokescreen Converts Flash to JavaScript On the Fly at Gizmodo.
• Smokescreen Project Promises 'Flash Without the Plug-in' at Webmonkey.

More Salvos from Apple and Adobe, to No One in Particular

I was out of the country when Steve Jobs posted his open letter on Flash to the Apple web site. Had I been around I would have dissected it. Today Adobe published its own open letter(s) about how great Flash is, why open markets are good, and even an ad campaign promoting choice. This passive-aggressive slap-fest is really just another reason for me to use my Apple vs. Adobe graphic that I spent nearly 10 minutes creating over a month ago.

To put my own preferences out there again, I have been critical of Flash for a long time (Jakob Nielsen roasted it 10 years ago now). The technology itself is mostly harmless, but developers have latched onto it for years to create confounding, inaccessible, and cryptic interfaces for web sites. To be fair, if they hadn't used Flash, they might have still made the same terrible chum, but Flash just enabled their poor behavior. Apple has always been the plucky upstart that despite being just another corporate computer company had somehow tricked masses of designers and wanna-be-cool-but-different (as opposed to being just different, like *nix users) folks in to giving them free advertising via legions of window stickers and the like. Except now people are recognizing them as the corporate juggernaut they are (When did Apple become uncool? at Yahoo! News).

Let me compare and contrast some points from the two letters.

Open vs. Closed

From Apple:

While Adobe's Flash products are widely available, this does not mean they are open, since they are controlled entirely by Adobe and available only from Adobe. By almost any definition, Flash is a closed system.

From Adobe:

The core engine of the Flash Player (AVM+) is open source and was donated to the Mozilla foundation where it is actively maintained. The file formats supported by the Flash Player, SWF and FLV/F4V, as well as the RTMP and AMF protocols are freely available and openly published. Anyone can use the specifications without requiring permission from Adobe. Third parties can and do build audio, video, and data services that compete with those from Adobe. [...] There are no restrictions on the development of SWF authoring tools, and anyone can build their own SWF or FLV/F4V player. [...] Adobe Flex, the primary application framework for Flash, is also open source and is actively maintained and developed by Adobe and the community.

As an end-user, I need help understanding Apple's point. How is what Adobe states any different from Apple's own WebKit? Because they claim it started as open source, whereas Flash didn't? The points in these letters don't speak to the average user, that's for sure.

From Apple:

Rather than use Flash, Apple has adopted HTML5, CSS and JavaScript – all open standards. [...] HTML5 is completely open and controlled by a standards committee, of which Apple is a member. [...] Perhaps Adobe should focus more on creating great HTML5 tools for the future, and less on criticizing Apple for leaving the past behind.

I'm going to let Adobe off the hook on this one. As I have said before, HTML is NOT a final specification yet. Apple is clearly pleased as punch that Safari supports much of HTML5, and good for them. But they are really pushing the canvas element as the Flash replacement. Given how quickly the W3C wraps up a spec, and browser makers get it into their browsers, and users download it, it's just not a good argument. It may be worth noting that JavaScript was originally Netscape's creation and is now known as ECMAScript.

Bear in mind that HTML5 has been handed off by the standards committee (W3C, of which Adobe is also a member) to the Web Hypertext Application Technology Working Group (WHATWG, of which Apple is a founding member). It turns out that Apple, Mozilla, and Opera were unhappy with the W3C progress on XHTML and HTML, and so broke off on their own. As a result, WHATWG is working on HTML5 alongside the W3C HTML working group, using the same human editor.

Touch Interfaces

From Apple:

Apple's revolutionary multi-touch interface doesn't use a mouse, and there is no concept of a rollover. [...] Even if iPhones, iPods and iPads ran Flash, it would not solve the problem that most Flash websites need to be rewritten to support touch-based devices.

From Adobe:

Flash was actually originally created as a technology for tablets with touch interfaces. And today, Flash has full support for working on touch-based devices. [...] For new Flash content developed specifically with touch in mind, Flash Player 10.1 provides a complete set of multitouch and gesture APIs.

Ok, Apple has a point, Flash does not support multi-touch. Multi-touch is relatively new, however, and Adobe promises it in their (much delayed?) Flash 10.1. I do take issue that Flash does not support touch devices. About 4 years ago we developed a Flash application to run on touch-screen displays for a kiosk, and it worked very well. The issue is again not with Flash specifically, it's with developers who are terrible at designing interfaces.

Security

From Apple:

Symantec recently highlighted Flash for having one of the worst security records in 2009.

From Adobe:

The Symantec Global Internet Threat Report for 2009 found that Flash had the second fewest number of vulnerabilities of all Internet technologies listed (which included both web plug-ins and browsers).

Erm, so who do we believe? Neither links to a report, but they both cite Symantec. So I went to the Symantec site and grabbed the document Internet Security Threat Report: Volume XV: April 2010. I searched in the PDF for Adobe Flash and found this:

In 2009, Symantec documented 321 vulnerabilities affecting plug-ins for Web browsers (figure 9). ActiveX technologies were affected by 134 vulnerabilities, which was the highest among the plug-in technologies examined. Of the remaining technologies, Java SE had 84 vulnerabilities, Adobe Reader had 49 vulnerabilities, QuickTime had 27 vulnerabilities, and Adobe Flash Player was subject to 23 vulnerabilities. The remaining four vulnerabilities affected extensions for Firefox.

Apple QuickTime had 4 more vulnerabilities than Adobe Flash? Did I mention that when I hit the Apple site, my browser keeps trying to get me to install QuickTime? There's also this quote:

The 321 total vulnerabilities in plug-in technologies for Web browsers for 2009 is less than the 424 in 2008. Of the total for 2008, 287 vulnerabilities affected ActiveX, which is significantly more than any other plug-in technology. Of the remaining plug-ins for which vulnerabilities were documented, there were 54 vulnerabilities identified in Java SE, 40 in QuickTime, 17 in Adobe Reader, 16 in Adobe Flash Player, and 5 vulnerabilities in Firefox extensions.

16 in Adobe Flash, 40 in Apple QuickTime. I really need some help finding Apple's point. I also need help finding Adobe's point. From what I see here, Flash is safer than QuickTime, even though (in further reading) it gets targeted more. If you want clear answers, you may need to read all 97 pages of the Symantec document, which was not linked from either Apple or Adobe.

Overall

Apple's letter clearly belies frustration with may have been Adobe's missed promised delivery dates. Apple also has a point that Flash doesn't hand off the video decoding work to the processor, eating battery life. Adobe has stated this is coming in the 10.1 release. Apple points to YouTube running as an app on the iPhone, but is silent on the fact that videos embedded in a page are inaccessible but does concede, backhandedly, that users aren't missing much video. And then Apple goes on about how Flash is designed to be cross-platform, and as such doesn't enable developers to write the best iPhone/iPad apps. And this is the crux of it all. Apple just wants the control and Adobe wants in.

Update (May 14): Read Adobe and Apple: Please Spare Us the Platitudes About "Open" over at Mashable for another take on all this.

Update (May 20): Read How secure is Flash? Here's what Adobe won't tell you at ZDNet where the writer also compares the Symantec report against Adobe. He missed the point, however, that Symantec recommends both Flash and JavaScript be disabled for a secure browsing experience, something that would hamper Safari's reliance on HTML5 in lieu of Flash.

Adobe to Drop iPhone Support, Target Android

And the saga continues. If you read my post Adobe vs. Apple or Flash vs. HTML5 from a few days ago, you already know that Apple and Adobe appear locked in a battle over Flash and the iPhone OS. It's clear Apple wasn't planning on backing down and it's certainly not in Adobe's best interests to continue the fight.

It should come as no surprise that Adobe is walking away. Mike Chambers, the Principal Product Manager for developer relations for the Flash Platform at Adobe (that's how he lists it on his blog), has said as much in his blog post, On Adobe, Flash CS5 and iPhone Applications.

He starts out with the clause from Apple that started this all, noting that developers can expect to see their Flash-developed applications slowly get booted from the iTunes store. However, Adobe has already built the export features into Flash CS5 that allows developers to target iPhones and iPads and plans to ship the software with those features still intact, even if Apple still blocks acceptance of applications built with that technology.

Instead, he claims that Adobe and Google have been working together to target Android phones and Android-based tablets with Flash 10.1. In short, all the work you have already done as a Flash developer to target the iPhone OS can simply be brought over to the Android OS. He provides links to some developers who are already making the switch, targeting Android now instead of iPhone.

There are some links in the blog post which I am including here. Since Apple has been silent on this entire dust-upand the general trend has been that Apple's licensing enforcement (both for app content and programming language) is arbitrary, I can't really offer counter-links or even counter-arguments. It also justifies my cheating and just parroting links from the original blog post.

• Apple Locks iPhone Developers in Its Walled Garden at PCWorld.
• Apple Wants To Own You at Slate.
• Mark Fiore can win a Pulitzer Prize, but he can't get his iPhone cartoon app past Apple’s satire police at Nieman Journalism Lab.
• Apple's New Developer Agreement Unlevels the iAd Playing Field at Wired.

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

• "Apple v Adobe: this time it's executable" at The Guardian, April 9, 2010.
• "Adobe CTO Defends Flash Against Apple, HTML5" at Webmonkey, February 2, 2010.
• "Adobe CEO: Apple 'hurts customers'" at MacDailyNews, April 14, 2010.
• "Adobe vs Apple: Flash of the Titans" at Mac Observer, April 14, 2010.