'Thoughts on Flash' and the Deadline Nobody Set But Everyone Can Read

Steve Jobs published roughly seventeen hundred words on April 29. The open letter, titled ‘Thoughts on Flash’ and posted plainly on Apple’s site, explains why Apple’s mobile devices will never run Adobe’s plugin. That covers the iPhone, iPod touch, and iPad. Never build your front door out of something one vendor can turn off.

The arguments run from technical to strategic. On the technical side: reliability, security, battery life, and a poor fit with touch interfaces. On the strategic side: Apple declines to let a third party’s software sit between developers and its platforms. The responses have ranged from Adobe’s aggrieved to the commentariat’s exhausted.

We have no stake in the corporate politics and a real stake in what site owners should do. So this post does two jobs. It converts the letter into the migration triage it effectively demands. And it names the principle underneath, which will outlive both companies’ press cycles and applies to technology choices that have nothing to do with Flash.

What the letter actually settles

Nothing in it is technically new. We flagged the Flash-shaped hole in Apple’s mobile platform in our first iPhone field notes three years ago, and again when the iPad extended it. What is new is certainty. The ambiguity is gone.

Until April 29, a site owner could reasonably file ‘no Flash on Apple mobile’ under temporary conditions. Negotiations happen, versions ship, surely commerce finds a way. The letter closes that door. This is policy, argued from first principles by the chief executive, in public, in a document built to be quoted.

Combine that with the trajectory, Apple’s mobile devices selling in the tens of millions, skewing precisely toward the affluent early adopters institutional sites court, and the market math is done arguing. A large, growing slice of your audience will never see your Flash content. Permanently, by decree. Planning can proceed from a fact where it previously idled on a hope.

The triage, in priority order

We have begun running Flash-migration triage with clients, and the order matters, because effort and impact diverge sharply across categories.

• Video, first and fastest. Usually the highest-traffic Flash dependency and now the most solvable. HTML5 video is practical today with sensible fallbacks. Native playback where supported. Flash player for older browsers. The same file, encoded once in H.264, covers Apple’s devices and much of the field. The codec politics between browsers remain genuinely messy, a topic we will treat separately. But the practical institutional path exists now, and YouTube-hosted content, per our usual recommendation, largely handles the transition for you.

• Navigation and interface chrome, next. The Flash menus and headers of the mid-2000s era have standards-based equivalents that are better on every axis that matters. Accessible, indexable, printable, and now renderable everywhere. These are rebuild projects measured in days per template. Every one retires accessibility and SEO penalties you were already paying. Our 2008 fine-print piece itemized them. Nothing improved since.

• Genuine interactive features, case by case. The honest category: data visualizations, configurators, games, tools. Some port cleanly to JavaScript and canvas today. The fast-engine era our V8 coverage described keeps expanding what is practical. Some genuinely cannot yet, and pretending otherwise helps no one. Assess these one by one. Traffic, audience, and mobile exposure. Rebuild cost. And, often the winner: whether the feature earns its keep at all. Migrations are wonderful occasions for retiring things nobody would build today.

Sequencing note for budget owners: this triage aligns with natural redesign cycles. A site due for refresh within eighteen months should fold migration into that project rather than paying twice. A site with years of intended life should start the video and navigation tiers this fiscal year, because the audience math only moves one direction.

The questions arriving from clients, answered in one place

The letter has generated a predictable inbox, so the consolidated answers.

‘Is Flash dead?’ On the desktop, no. The plugin’s install base remains near-universal, and desktop-bound experiences, like internal tools and some rich applications, face no immediate cliff. On anything mobile-shaped, strategically, yes. The growth is where the plugin is not, and building new Flash-dependent public content in 2010 is commissioning future migration work at full price.

‘What about Flash for video while we transition?’ Precisely right as a fallback layer. The HTML5-first, Flash-fallback pattern serves every current browser and ages gracefully, which is why it is the pattern.

‘Our agency proposed a Flash homepage feature last month. What do we do?’ Ask them to re-propose it in standards-based technique, and weigh the answer’s fluency as part of the vendor evaluation. This month is a fine natural experiment in which shops kept current.

‘Should we build an app instead?’ Different question, different post. But the short version our mobile series keeps giving: the browser reaches everyone, apps reach installers, and most institutional content wants reach. The letter changed none of that calculus. It just retired one of the wrong answers.

The principle underneath, which is the keeper

Now the part we would have every reader retain after the news cycle fades. The strategic lesson of April 29 is not about Adobe, Apple, or multimedia. It is this: proprietary runtimes carry unilateral-shutdown risk that open standards structurally don’t.

Consider what just happened. A decade of Flash content, much of it excellent, built in good faith on a platform that was for years the only way to do what it did, has been stranded on mobile by a single company’s strategy memo. Not retired by committee. Not sunset with a migration path. Excluded, by decree, from the fastest-growing computing category.

No standards-based investment of the same vintage suffered that fate. HTML, CSS, and JavaScript from 2005 render on every device in the letter’s blast radius.

That gap is the entire argument we opened with in 2006, restated by events at maximum volume. You can build on things no single actor can take away. Or you can build on things one memo can strand. The difference is invisible until the memo publishes. Apply it to every dependency conversation you are in this year (plugins, platforms, formats, clouds) and the Flash episode will have taught something durable.

And a closing courtesy to the Flash developers in the audience, whose craft this transition strands through no fault of their own: the skills transfer better than the panic suggests. Animation sense, interaction design, timeline thinking. The standards stack needs all of it, and the people who made Flash’s best work are precisely who should be making canvas and JavaScript’s best work next. Platforms end. Craft compounds. Bring it along.