Apple vs. Flash: The InfoWorld peace plan

The fight between Apple and Adobe over Flash on the iPhone OS has all the trappings of a major industry rift. No one doubts at this point that Apple is on a mission to kill Flash. After many long years, the on-again, off-again conflict between two companies that have relied on one another since the early days of the Mac has finally gone nuclear.

READ THE INFOWORLD FLASH PEACE PLAN DETAILS THEN VOTE ON IT BELOW

This conflagration is a bad way to step into the mobile Internet future. Flash, for all its flaws, is ubiquitous to the Web and essential to rich interaction on a huge number of sites. Were it not barred from the iPad and iPhone, it would be one of the shortest paths to creating rich Internet applications that run across multiple mobile platforms (including Android), not to mention every major desktop browser.

[ InfoWorld’s Eric Knorr urges users to stop bashing Flash. | Neil McAllister argues that it’s time to say “good riddance” to Flash. | Keep up on the top tech news and analyses with the InfoWorld Daily newsletter. ]

At InfoWorld.com, we believe such lockouts of technology, however well rationalized, could eventually lead to an Internet future of multiple, incompatible platforms that demand multiple proprietary technologies.

Give peace between Apple and Adobe a chance In a spirit of fairness, with full knowledge that we will be shot at by both sides, InfoWorld would like to propose a peace plan. Both sides need to compromise; this is not simply a matter of Steve Jobs opening his platform to Flash. Adobe must take a step toward openness as well and help ensure that developers create Flash apps that are secure, stable, and suited to mobile use. Before we get to the details of the peace plan, however, a review of the conflict at hand is in order.

The roots of conflict: From PostScript to Safari crashes You could argue that the antipathy between Apple and Adobe goes all the way back to 1989. In 1985, during Steve Jobs’ first stint as CEO, Apple licensed PostScript to create the first PostScript laser printer and invested in Adobe because of the promise he saw in the technology. The result was the desktop publishing revolution.

But the relationship soured four years later, after Jobs was forced out of Apple, when Adobe and Apple fought over scalable font technology, which Adobe jealously guarded. Apple teamed up with Microsoft to create a competitor, known now as TrueType, and Adobe was forced to back down.

While today’s clash is ostensibly about Flash, in Steve Jobs’ now-infamous post on the Apple site, Adobe the company is in the line of fire as well.

Application stability. Jobs claims that Flash is responsible for more Mac OS X system crashes than any other software, and he doesn’t want the iPhone OS to suffer the same instability. This claim is completely credible. Many, many Flash apps are created by so-called programmers who have no clue about memory utilization, cleanup, and the like. It’s easy to create Flash apps that consume all of a browser’s memory, interfere with other Flash or JavaScript apps, don’t close properly, and generally obstruct the user and the browser. Adobe has hardly helped these amateur developers avoid these problems in its Flash Pro software; there’s a reason that several Flash-blocking browser plug-ins are available to prevent Flash-induced browser crashes.

Moreover, the new version of InDesign lets you export Flash SWF presentations directly from your layout, complete with button actions and animations. How good is that code?

More reason to worry that maybe Adobe can’t deliver a quality Flash Player for mobile: Adobe began shipping Flash Lite players in 2006 for several mobile operating systems, but they don’t run much standard Flash content. Even today, Flash Lite is buggy and unreliable on devices such as the new Android-based HTC Droid Incredible.

In Adobe’s defense, the company has created an enterprise platform for Flash under the LiveCycle brand that includes an Eclipse framework, data integration, and an application server. The suite is currently in use by enterprise developers and professional services organizations.

Resource-hogging. A related issue to the quality of the code is the quality of the player; both conspire to eat up resources such as CPU cycles, memory, and battery power. Jobs has pointed out that Adobe has been promising mobile versions of the full Flash Player for years but has yet to deliver one.

Without Flash players actually on the market, it’s hard to know if Jobs’ concerns are valid. But the delays are worrisome. We may get a clue if Adobe meets its promised June ship date — which has slipped a few times already — for Flash Player 10 for Android.

Compromised security. As Microsoft has tightened the security features in its Windows operating system, its apps, and its development tools and as Apple has begun to do the same on its end, Adobe stands out as the emerging threat magnet, due to a regular flow of security holes in its Flash, AIR, and PDF technologies.

Of course, Apple has had its share of security issues on the Mac OS, so it’s no paragon of security virtue. But the iPhone OS — because of Apple’s tight controls — has so far been spared breaches outside of jailbroken devices, and it’s understandable Apple wants to keep it that way.

Lack of gesture support. Jobs claims the Flash’s keyboard-and-mouse interface expectations — derived from its PC roots — simply don’t make sense in a gesture-based mobile device. He’s sort of right. On the other hand, most Web pages also are designed for keyboard and mouse input, yet Apple lets users access those sites on its iPhone OS devices. What’s the difference?

True, Apple has substituted its own UI approaches for some native HTML UI conventions — such as the scroller for picking menu items in <select> tags — but it doesn’t do so for JavaScript UI elements, even though most of those are not touch-friendly. So why apply a different standard to Flash UI elements?

InfoWorld’s peace plan for Flash on iPhone OS In his assault on Adobe, Jobs repeatedly questions the company’s ability to execute — and not only regarding the security and stability of Flash apps. He calls the company “painfully slow” to adopt enhancements to Apple’s platforms, and he suggests that Adobe should focus on creating HTML5 tools for the future, rather than criticizing Apple for leaving Flash behind.

We can all agree, however, that the HTML5 future is years away. By barring Flash from the most popular and exciting mobile devices in existence, Apple denies developers and users an opportunity to create and consume applications that can provide a consistent user experience across platforms.

Both Adobe and Apple need to step up to the plate for that possibility to be realized. Here is our four-point plan for peace that could allow Flash on Apple’s mobile devices:

1. Create a Flash video player plug-in. The security, stability, resource, and UI issues Jobs cites in his opposition to Flash simply don’t exist for Flash video. Apple should let Adobe create a Flash video player plug-in for the Phone OS to be used in mobile Safari and by developers of iPhone OS apps for their own apps. Perhaps this will have to wait until the multitasking-enabled iPhone OS 4.0, but as that’s due this summer, it’s not a long wait.

Apple can set the memory usage limits for the video player, and as part of its normal app review can make sure that security, stability, and other concerns are met. Apple can also set the processing threshold required for supporting Adobe’s F4V video format and its more resource-intensive VP6 codec. But the Sorenson Spark codec is equivalent to the requirements for the H.264 codec used in HTML5 and on the iPhone, so it should be allowed.

2. Put the core Flash technologies into the standards bodies. Both Adobe and Apple claim the other company relies on proprietary technologies, while saying they themselves are each open. Both companies are playing fast and loose on this issue.

Although Apple insists that its operating system and SDK be proprietary and subject to its control, so too does every software company, from Microsoft to Adobe. On the other hand, Adobe wants its proprietary technologies to be de facto standards across as many operating systems and platforms as possible — while remaining proprietary to Adobe and its development tools.

For Adobe to realize its ubiquity goal, it needs to do with the Flash technologies — the ActionScript language and the Flash file formats — what it did with PDF files: Release the core subset to the standards community.

ActionScript was actually derived from JavaScript (formally known as ECMAScript), a standards-based language that Apple supports in the iPhone OS. It’s time for ActionScript to become a standard, too. That should remove one of Apple’s reasons to not support it on Web pages at least.

Likewise, the Flash video formats should be released to the standards bodies, since Adobe wants it to be a de facto alternative to the MPEG-4 video standard. It’s true that Apple has its proprietary video format, QuickTime, just as Microsoft has its AVI, but Apple has not favored QuickTime over the MPEG-4 standard. If Adobe releases the Flash video format to the standards bodies, Apple would — and should — be able to support it natively as it does MPEG-4.

Adobe has based its Flex Builder development environment on Eclipse Foundation code and has Flash development plug-ins for Zend and other Eclipse frameworks. However, if it truly wants its Flash technology to be ubiquitous, it should go all the way and embrace the standards and open source approaches to promulgating its technology.

3. Create an iPhone-certified SWF exporter for Creative Suite. The new Creative Suite 5 released this month offers two tools for creating Flash content for mobile devices: a Flash-to-iPhone export option for app creation in Flash Pro CS5, and a SWF export capability for animations and interactive content in InDesign CS5. Apple moved quickly to ban the first one by changing the iPhone SDK rules to disallow use of any APIs other than those it approved and to forbid the use of translation tools to access those APIs — the code has to be native Apple Xcode. The second is barred de facto by the ban on Flash content on the iPhone.

The InDesign SWF exporter is limited to files that have common actions, such as “go to page,” “play video,” “display animation,” “loop video,” and “open PDF.” All of these are canned routines, not code that individual developers write. Apple could easily work with Adobe to examine the resulting code and certify it for the iPhone OS — essentially, implementing an App Store-style review for security, stability, and the like. Once certified, the SWF exporter would add a signature to the file that the iPhone OS would use to validate they are approved. There would be a corresponding SWF Player plug-in developed by Adobe and certified by Apple. This could be done fairly quickly, so InDesign CS5 users could get an update that certifies their SWF files for iPhones.

The next step is for Adobe and Apple to work together on gesture UIs for SWF interactive content, so InDesign-based SWF creators can use mobile-oriented interface elements. That would be great for iPhone users — and it would give Apple another way to promote the UI goals that Jobs continually cites. (We’ll leave it up to Apple and Adobe to decide whether that capability would be available for non-iPhone devices and, if so, whether any money changes hands.) This effort probably would take a year or more, and thus not be available until Creative Suite 6’s likely 2012 release.

4. Explore a Flash app certification process. There’s no way in the foreseeable future that Apple is going to open up the iPhone OS so that anyone can create apps for it, as is the case on other mobile devices — there will be an app approval process. Adobe needs to accept that fact and cease its end run around Apple, which is what it did with its Flash-to-iPhone exporter in Flash Pro CS5.

Instead, Apple and Adobe should explore ways to certify Flash apps for the iPhone. Certainly Apple can help Adobe work on the standards that Flash Pro-created iPhone apps must adhere to, and Adobe has to ensure that Flash Pro generates efficient, secure code. If that base is established, Apple could set up an approval process for iPhone-certified Flash apps just as it does for its Xcode-based iPhone apps. This approach would let Apple retain the control it wants, prevent the technical issues Apple says it is seeking to avoid, and give programmers a more familiar development platform.

We realize that allowing even approved Flash apps on the iPhone raises a business concern for Apple. We suspect the issue is that Apple doesn’t want to make it easy for developers to create apps for other mobile devices at the same time they write iPhone apps. Pushing users to its Objective-C Xcode environment does that trick nicely. Allowing Flash-based apps would give rival platforms faster access to a wide range of iPhone-quality apps, so the business realities may prevent the exploration of a Flash app approval process from bearing fruit.

But there’s more to the iPhone than apps, and even within apps, there are capabilities that other mobile operating systems can’t touch. There could be ways where Apple and Adobe can both have their cake and eat it too when it comes to apps. Surely, Apple and Adobe can figure out how to solve this issue if Apple’s business strategy can accept Flash as an iPhone app dev tool.

Can the two companies actually sit down and deal? The fighting over Flash on the iPhone has been going on for several years, and from the outside, it doesn’t seem like either company has sought a win-win result. Instead, after three years of stalemate, Adobe moved forward with its iPhone app exporter in Flash, antagonizing Apple and causing tensions to boil over. Jobs reacted strongly in public, and Adobe asked the feds to investigate Apple for antitrust behavior. Listen, guys: Nuclear wars don’t end well.

Adobe has a lot to prove, given the unsolved problems with Flash after so many years. The technical ball is clearly in its court. But Apple is taking the more significant gamble by playing hardball — and it could very well lose.

After all, despite Jobs’ legitimate concerns, the truth is that if Flash Player ends up being problematic, users will abandon it, and Adobe would pay the real price of that failure. But by acting intransigent, Apple blackens its own eye, giving Adobe a pass on any problems it does have, and pushes customers and developers to its competitors. No matter how superior the iPhone OS is, people don’t like bullies and will go elsewhere as soon as they can. Google and Microsoft are counting on it.

And Apple should remember that font dispute with Adobe from 1989, which damaged a successful, strategic partnership. Back then, Apple found itself at the mercy of a key platform technology owner, so it tried to free itself from that control. Today, the roles are reversed — and more needless damage to the two companies and their customers is on the horizon.

The peace plan outlined here puts the technology burdens on Adobe, giving it a chance to prove Apple’s fears unfounded or solve them before they go live, all while ensuring Apple has the platform control it wants. Give peace a chance.

This article, “Apple vs. Flash: The InfoWorld peace plan,” was originally published at InfoWorld.com. Follow the latest developments in mobile technology at InfoWorld.com.