Has Adobe figured out how to get Flash to play on your iPhone?

Recently I’ve been making the case that Apple’s anti-competitive ban on Flash has stopped rich cross-platform development in its tracks.

As such I was naturally intrigued by a video post I came across recently asking “Has Adobe figured out how to get Flash to play on your iPhone?”

First of all, it’s important to stress that the obvious and by far the best way to get Flash content to play on your iPhone/iPad remains as far off as ever. Much though it would love to, Adobe hasn’t been able to announce the launch of a Flash player for Apple’s iOS-based devices to match its Android player. There’s no question that Apple’s hardware – see the latest iPad 2 review – would be able to support it, but for reasons that I covered recently – money and lots of it, for ever and with no competition – Steve Jobs won’t allow it.

So if it’s not a Flash player for the iPhone and iPad, what is it?

A Bridge from Flash to HTML5

Is this a bridge from the old days of Flash and player-based development to the promised land of HTML5? Was Steve Jobs right after all?

It’s a new technology preview made available on the Adobe Labs site under the code-name “Wallaby” and it’s essentially a Flash-to-HTML5 converter. Open your FLA file and hit OK and Wallaby will attempt to output all the necessary HTML, CSS, JavaScript and other standards-based files to recreate your player project within the browser.

If anything this looks even more interesting. After all, when Steve Jobs announced that iOS wouldn’t be supporting Flash, the case he made against it was that Flash was no longer necessary and that it should be replaced by HTML5 (a blanket term covering all the W3C standards such as CSS, DOM, SVG etc). The sign-off line to his Thoughts on Flash was:

“Perhaps Adobe should focus more on creating great HTML5 tools for the future, and less on criticising Apple for leaving the past behind.”

At first sight it looks like Adobe has done just this and that Steve Jobs has won the argument. After all, if you can deliver Flash functionality in the browser via HTML5 why shouldn’t you? Especially so now, when there’s one overwhelming reason why you need to: if you want to access the full web audience, including the crucial iPhone/iPad demographic walled up in Steve Jobs’ closed kingdom, there’s simply no alternative. The browser is the only way to go.

So is Wallaby a bridge from the old days of Flash and player-based development to the promised land of HTML5 and truly rich browser-based development? Was Steve Jobs right after all?

I’m sure that this is exactly how it will be seen and presented by many – “don’t worry that the iPad doesn’t support Flash, you just don’t need it nowadays, everyone’s agreed that it’s much better to do it in the browser rather than the player, in fact even Adobe has given up on it now and has built its own Flash-to-HTML5 converter”.

Any such talk is misguided, misleading and dangerous. To understand why, you need to dig a little deeper and see what Flash-to-HTML5 conversion really involves in practice.

Unsupported Features

In fact you don’t need to dig very far before a very different picture begins to emerge. Read the introduction to Wallaby and it becomes clear that Flash-to-HTML5 conversion is not a simple matter.

This initial version of Wallaby has several unsupported features due to the complexity of FLA files and the inability to represent some Flash Professional features in HTML5. The major ones include no conversion of: ActionScript, Movies, Sound. Also some design elements such as Filters are not supported. For a detailed list of supported and unsupported features see the Features and Status page.

Visit the page or try and convert a typical sample FLA and you’ll see that the unsupported features certainly aren’t insignificant – my first “successful conversion” came back with 291 warnings. Many of these limitations are important particularly when it comes to text – line break differences, glyph spacing/positioning, no support for links, selectable or vertical text and so on.

However it’s the lack of ActionScript support that is the real show stopper. It means that you are not going to be able to take your advanced Flash-based Rich Internet Application (RIA), say your online word processor, XML-based news reader, live messenger widget or video conferencing portal and suddenly make them available for iOS. In fact you won’t be able to convert the simplest game if it depends on ActionScript.

So what will you be able to convert? Again the introduction is clear:

Wallaby does a good job of converting graphical content along with complex, timeline-based animation to HTML5.

In particular

The focus for this initial version of Wallaby is to do the best job possible of converting typical banner ads to HTML5.

Workflow complexity

Wallaby’s conversion capabilities are clearly very limited, but that’s not all. Don’t expect the end results to be ready-to-go. Again as the introduction puts it:

Wallaby’s design goal was not to produce final form HTML ready for deployment to web pages. Instead it focuses on converting the rich animated graphical content into a form that can easily be imported into other web pages in development with web page design tools like Dreamweaver. The web page designer will likely want to add interactivity and design elements such as video and sound before deployment.

In practice this means loading up your Wallaby output as a complex HTML file built up of multiple SVG text blocks and PNG image files that are then absolutely positioned via CSS (including each animation frame). Certainly as things stand you can forget about usability features such as LiveView and easy editability. You are then expected to add back any video, audio and what interactivity you can within Dreamweaver.

Browser incompatibilities

Assuming the original Flash project was simple enough and that you are then up to the complexities of recreating it within Dreamweaver, you are finally ready to deploy. And here you come across another very important caveat:

At this time, the Wallaby HTML5 output uses Webkit specific CSS3 tags and therefore is not compatible with Firefox, IE9, or other HTML5 browsers.

In other words the whole enterprise is focused on just one browser engine, Webkit, as used in only two browsers: Chrome and – the only one that really matters because it’s the only one that doesn’t support the Flash player – Safari on the iPhone and iPad.

All this for iPad banner ads?

Flash-to-HTML5 conversion has absolutely nothing to do with replacing Flash. Quite the opposite.

We’ve arrived at a very different place. It turns out that Wallaby’s Flash-to-HTML5 conversion has absolutely nothing to do with replacing Flash with a truly universal, browser-based HTML5 equivalent. Instead it’s a complex, targeted workaround designed to enable Flash users to overcome Steve Jobs’ player ban by enabling a small subset of projects to be recreated within the WebKit-based iOS browser runtime.

All in all it’s a huge amount of effort for what at first sight looks like very little gain. Again though, it’s important to dig a little deeper.

First, it’s important to recognize that eye-catching banner ads might be irritating, but they are also incredibly important. They are helping to pay for your free access to this article and to much of the high quality content on the web. Apple’s unilateral ban on Flash threatened to remove the most highly sought-after demographic (affluent early adopters) from the equation (and coincidentally open them up to Jobs’ own iAds system).

It certainly won’t be welcomed in all quarters but, by enabling rich Flash ads to again be delivered to a truly universal web audience including iPhone and iPad users, Adobe is actually doing the web economy a major service.

And if it goes some way to breaking the knee-jerk association of irritating ads with Flash that’s a good thing too. Who knows, maybe the legion of Apple-based ad haters who supported Jobs’ ban so strongly when it was first announced will now be as vociferous in their support for Flash. After all you can block Flash, but you can’t block HTML5.

Yes banner ads are central, but I also think that Adobe has bigger fish to fry. Recently I wrote about Adobe’s Digital Publishing system and was astonished to find that the early trial release seemed to depend on bitmaps to enable InDesign users to recreate their typographically-rich layouts for iPad delivery. Clearly recreating rich designs via more efficient, scalable SVGs and CSS is a far superior solution (though still nowhere near as simple, efficient or elegant as doing so via Flash).

The underlying principle: universal access

Crucially, recreating publications via WebKit provides a way for designers and publishers to ensure that their rich content can be viewed by all users including those who would otherwise be off limits in Steve Jobs’ walled kingdom.

It’s this determination to provide the richest possible experience, whether inside the browser or inside the player, that cross-platform web development is all about. It also demonstrates Adobe’s determination to be seen as the leading HTML5 force, as well as the company behind Flash.

But if you’ve shown that you can deliver rich content universally within the browser via HTML5 rather than the player, isn’t this the right thing to do? If you’ve proved that you can do it without Flash then why not just drop it entirely? Why not just extend the system to the other browsers and develop dedicated stronger HTML5 tools as Jobs suggested? In fact isn’t this proof that Jobs was right all along?

Well according to its recent AdobeMAX, Adobe is indeed working on dedicated HTML5 tools. However it’s important to understand that even these will not replace Flash. And for the same reasons that we’ve already seen in practice.

Unsupported capabilities

The unspoken assumption that of course the browser can somehow just “do Flash” is fundamentally mistaken.

Yes, Wallaby is a trial preview and its HTML5 power can certainly grow, but it will never replace Flash. This isn’t because Adobe is holding back; rather it’s because “the inability to represent some Flash Professional features in HTML5” is inherent.

In particular Flash has come a long way from its animation and banner-ad origins and nowadays the rich functionality of today’s powerful modern Flash-based RIAs are based on ActionScript’s rich APIs. These APIs are enabled by the Flash runtime and while the HTML5 browser runtime will be better than it was, and can already just about take over Flash’s animated advert duties, it can’t possibly be expected to completely replace the dedicated players.

The unspoken assumption that, of course, the browser can somehow just “do Flash” is fundamentally mistaken. After all Flash and Silverlight are modern, intensively-developed technologies representing thousands of hours of development from the world’s two major software forces, both of whom are effectively betting the company on the success of their cross-platform web platforms.

By contrast the vector-based SVG 1.1 specification, which is absolutely central to any hopes of delivering resolution-independent, scalable, Flash and Silverlight-style rich design in the browser, was developed by an ad-hoc, part-time committee of volunteers with very different plans in mind (think rollover buttons) and hasn’t been updated since January 2003.

Workflow complexities

Yes, working with Wallaby is complicated, but again this is inherent. Standards such as CSS, SVG, DOM and JavaScript have evolved independently and erratically and trying to yoke them together is not simple. Flash Professional or Builder certainly aren’t models of simplicity (Expression Blend is far superior), but clearly ground-up, integrated, wysiwyg design-oriented solutions have a major advantage here.

Adobe is only targetting the iOS version of Safari for a very good reason: every other browser supports Flash

Not least they have the huge advantage of targeting a single, reasonably robust and reliable cross-platform, cross-browser runtime. For Wallaby to extend its HTML5 output to other browsers, Adobe would have to work out the constantly moving targets of their capabilities and foibles, come up with the necessary workarounds and, assuming delivery is possible, implement browser-sniffing to serve up the desired targeted code.

Thankfully this whole nightmare is unnecessary because every other browser on every major platform (mobile as well as desktop) apart from Safari on the iPhone and iPad supports the Flash player. Crucially this includes older browsers too. After all, as Microsoft has only now added support for SVG to IE9, any truly universal HTML5 solution would otherwise have to wait not just for IE6 to be purged from the system, but IE7 and IE8 as well.

This universal cross-browser compatibility is strangely overlooked but is perhaps the web players’ greatest strength. Crucially it ensures that the web platforms that the players enable are automatically immune to the foibles, foot-dragging, incompetence and occasional sabotage of the various browser developers. As any web designer who lived through the previous browser wars knows, trying to ensure consistent delivery across all browsers while being forced to travel at the speed of the slowest is not fun.

The fact that Wallaby only targets iOS Safari isn’t a failing. There’s a very good reason for it: every other browser, including IE6, already has a far better, more efficient, more robust, more reliable, more independent, more powerful delivery mechanism in place. It’s called “Flash”.

HTML5, Flash, Silverlight: It’s your choice. Or should be

This isn’t to say that Flash is in any way a general replacement for HTML. Of course the future of the web belongs to HTML5 (though bearing in mind the reality checks above).

If you can deliver content and functionality successfully in the browser then this is what you should do. Flash isn’t an alternative to HTML and never has been; it’s a rich wysiwyg extension. 99.9% of web pages can and should live without Flash.

However when HTML5 can’t deliver the goods as simply, as efficiently, as reliably, as universally, or as well as Flash or Silverlight or any other web technology that comes along, then all designers, developers and end users should be able to take advantage of what the cross-platform extensions have to offer. It’s a simple question of freedom of choice.

The real problem and the real solution

The real problem here isn’t Flash; it’s the lack of Flash. And Steve Jobs could solve that instantly

Cross-platform web players aren’t somehow a problem that needs to be overcome to enable truly universal, truly rich, browser-based delivery; they are the solution that makes it possible.

Steve Jobs realised this and the threat that rich device-independent development poses to his native apps and to his ugly business model and that’s why he decided to kill it.

Steve Jobs is not championing HTML5 to make the browser as rich as possible; he is championing HTML5 as cover for his attempt to kill player development to ensure that the browser never becomes a truly rich, robust and open platform.

The real problem here isn’t Flash; it’s Steve Jobs.

At any time Steve Jobs could simply lift his entirely artificial ban, save everyone all this unnecessary pain and, by doing so, deliver his users what he promised them: “the best web experience”.

Until that happens, the best we can hope for is a partial, awkward, undesirable workaround to try and restore some sort of unity and universality to the rich web. It’s in this context that Adobe’s Flash-to-HTML5 conversion should be understood and appreciated.

A shaky bridge into Apple’s walled kingdom is better than nothing.