Distilling market noise into market sense

VisionMobile is the leading research company in the app economy. Our Developer Economics research program tracks developer experiences across platforms, revenues, apps, tools, APIs, segments and regions, via the largest, most global developer surveys.

The death of Flash – 8 years in the making

[Adobe’s decision to stop developing Flash for mobile browsers is the talk of the day – but the reasons behind Flash’s ultimate failure are not that obvious. Guest author Francisco Kattan discusses the chain of events that led to the death of Flash – a time bomb inadvertently planted by Adobe many years ago].

The death of Flash - 8 years in the making

Ever since Adobe announced that it will stop developing Flash for mobile browsers, the blogosphere has been buzzing with a broad range of sentiments including “I told you so” by critics, disbelief by Flash developers, Monday morning quarterbacking by analysts, and even a petition for Adobe’s CEO to resign.  Check out also the Occupy Flash and Occupy HTML manifestos from the opposing camps. Flash is one of those topics that attract very emotional responses from both its passionate developer community and its very vocal detractors. Although I am generally an Adobe supporter, I will put emotion aside and summarize, in hindsight, what went wrong. For full disclosure, I am a former Adobe employee, but this post is based only on publicly available information.

HTML5 did not kill Flash. Steve Jobs did not kill Flash. The death of Flash was caused by a time bomb planted inadvertently by Adobe many years ago.

Although Flash for mobile ultimately died because Adobe did not adapt fast enough to post iPhone changes in the ecosystem, the seeds for Adobe’s failure were planted earlier on. To understand what went wrong, let’s first review what happened before the iPhone and how those events set the stage for what happened later.

Before the iPhone – the Flash Lite era

Back in the early to mid 2000’s, there was great demand from handset makers (OEMs) who were willing to pay for Flash Lite (the mobile version of Flash at that time) and Adobe decided to collect a per-device license fee for the software. This decision set in motion the incentives and behavior that would ultimately lead to the demise of Flash in mobile, and as I explain later in this post, will also kill Flash on the desktop. Adobe’s ambition to create a platform for delivering rich internet experiences is now doomed.

A big question in many people’s minds is why Adobe didn’t just replicate the model that had been successful with PDF and the desktop Flash Player: make the runtime freely available and monetize it with increased tools revenue. Presumably this would have motivated Adobe to prioritize platform consistency over broad (but fragmented) reach. But it was not that simple.

Although there was a thriving Flash Lite ecosystem in Japan (developers creating content and distributing it via the operators), Flash Lite was initially NOT used as an apps platform in other countries. Flash Lite was used in many cases by OEMs who were looking to differentiate their devices by building expressive user interfaces for the core applications (home screen, dialer, address book, messaging, call log, and others). The LG Prada is a great example of the kind of user interface handset makers could build using Flash Lite. This device featured an iPhone-like touch interface back in 2006 (demo). The Samsung D900 and the LG Chocolate are good examples also. Although these devices included Flash Lite, they did not offer an opportunity for developers to distribute Flash-based content. The implementation of Flash Lite was closed to third party developers as there was no Flash in the browser nor the ability to execute Flash-based apps. As there was no clear opportunity for developers and therefore no tools revenue to be made, it made sense for Adobe to collect a per-device fee from handset makers rather than monetize the player via the tools.

Conflicting objectives: handset makers versus developers

As it happens, when the opportunity to deploy Flash Lite as an applications platform presented itself later on (especially on Nokia and Sony Ericsson devices), Adobe did not adapt its business model right away. In hindsight, this turned out to be a costly mistake. At that point, there was an inherent conflict between the needs of handset makers looking to differentiate their devices and the needs of developers who needed a consistent platform across devices. As OEMs were paying the bills and the mobile team was measured on revenue, it was natural for Adobe to prioritize OEM requirements over developer requirements and to let OEMs implement Flash to meet their own needs. OEMs licensed the source code from Adobe and created their own binary implementations that were not consistent across devices. Flash Lite was used sometimes for building device user interfaces, other times for browsing Flash content, and other times for running standalone apps. In addition, OEMs did not always implement the same set of APIs creating additional fragmentation for developers. Worse yet, as the runtime was not updateable over the air, device fragmentation would only get worse with time.

Lack of Distribution and Monetization Opportunities for Developers

Even when Flash Lite was deployed as a platform to run standalone apps (not in the browser), there was no easy way for developers to distribute their apps. There were no iPhone style app stores at the time. Developers had to distribute their content via middlemen (aggregators) who collected a tax and who had distribution deals with handset OEMs and network operators. Worse, the OEMs and Operators did not have good merchandising channels and discovery of apps by consumers was very poor to say the least. There was no streamlined way for Flash developers to reach consumers. This was a major issue for developers as it was for Adobe. At the same time, revenue from OEMs continued to grow –shipments of Flash enabled devices were more than doubling every year– masking the severity of the problem and allowing the time bomb to continue to tick.

A glimpse of hope: partnering with operators to reach consumers

In an effort to create a thriving ecosystem for developers, Adobe turned its attention to mobile operators who at the time controlled content distribution via their infamous walled gardens. Working with operators was not a popular move especially with Adobe’s Web developers who were new to mobile and did not appreciate the level of control that operators had at the time. Adobe worked with several operators but most prominently with Verizon Wireless (see the April 2006 news release) which on paper was an ideal partner. As one of the world’s largest CDMA operators, Verizon Wireless had great influence over its OEMs and was able to specify the Flash runtime on its devices. Verizon Wireless also had the most successful app store in the US at the time (the BREW-based Get it Now download market).

Adobe and Verizon launched two services: A Flash app download service as part of the BREW Get it Now ecosystem (see the October 2006 news) and Verizon “Dashboard” (announced in March 2007), a much more ambitious service based on Adobe’s on-device portal called Flash Cast. Both services, had issues. The BREW Get it Now offering failed because it was too difficult for developers to onboard new apps, developer revenue shares were too thin, app discovery was difficult for consumers, and Verizon moved too slowly to certify new handsets with Flash (for more on this see: Is Brew Dead? Lessons Learned).

The Dashboard service failed because it took far too long to launch, missing its market window. Verizon announced Dashboard in March 2007 promising availability in the second half of the year, but the service did not see the light of day until September 2008. Even then the service was available on only one handset out of a broad device lineup available on Verizon stores. With the iPhone and Android devices attracting all developer attention by then, Flash Cast and Dashboard were too little too late.

It is worth mentioning that the innovation around Flash Cast and Verizon Dashboard was quite promising. In hindsight, the service resembled many of the key attributes of the iPhone: like the iPhone, it had an App Store concept where consumers could discover and purchase widgets with a revenue share back to developers. Like the iPhone, it was designed as a walled garden with a gate keeper (the operator in this case). Like the iPhone it featured an expressive user experience as the widgets and the user interface were based on Adobe Flash. However, unlike Apple, Adobe did not have end to end control of the ecosystem and the service was late to market as a result. The service was designed for 2006, not 2008, a big difference considering the iPhone showed up in 2007 changing all the rules. Although Adobe was innovating fast, its innovation did not reach consumers in time because it relied on slow moving partners.

Enter Steve Jobs and the iPhone — CONTROL-ALT-DELETE on the ecosystem

The launch of the iPhone changed the mobile ecosystem so dramatically that it disrupted all incumbents in ways that were not readily apparent right away. The disruption was so great, that it favored new entrants that were starting from scratch under the new rules (Apple and Google) over incumbents who had existing market positions and established business models (Nokia, RIM, Motorola, Palm, Microsoft, Qualcomm/BREW, Symbian, Sony Ericsson, and of course, Adobe). Like many other players, Adobe did not adapt fast enough and paid the price as a result. Consider three major changes in the ecosystem and how they negatively impacted Adobe Flash:

  • Apple caused the existing operator walled gardens to crumble while Adobe was focused on building ecosystems with operators.
  • Consumers started dumping feature phones in favor of buying smart phones, but Adobe had focused on feature phones which represented a much larger share of device shipments (and revenue to the mobile business unit).
  • Mobile browsing finally took off as a mainstream service, but Adobe’s mobile player did not support 100% of the desktop Flash content as demanded by Steve Jobs.

As you may recall, the first generation iPhone did not have an App Store or SDK. It was all about browsing the internet (see the “internet in your pocket” ad campaign). The iPhone was the first handset with a decent browsing experience and quickly took the bulk share of mobile browsing (even though it represented only a very small share of device shipments). The lack of Flash was a glaring gap at the time.

If there was ever a time that Steve Jobs needed Flash, it was in 2007 with the first generation iPhone 

Unfortunately Flash was not ready at the time. Because Adobe generated revenue from device shipments, it had been focused on the feature phone category which represented a much larger share of the market in terms of shipments (but nearly zero percent in terms of web browsing page views!). Neither version of the Flash Player met Steve Job’s requirements. Flash Lite did not support all the Flash content on the Internet because it had been optimized for more constrained devices and the full Flash Player did not run well on smart phones because it required the power of a desktop computer. Steve Jobs famously once said, “there is this missing product in the middle,” referring to this issue.

Incredibly, Adobe did not ship the mobile version of the full Flash Player until June of 2010 (version 10.1), three long years after the launch of the iPhone! By then, the iPhone was the most popular device on the planet and Apple had shifted focus from browsing the internet to apps where Flash did not matter (recall the “there is an app for that” ad campaign). Adobe had missed the window of opportunity to be part of the iPhone.

Sure, Apple could have still adopted the Flash Platform in 2010, but it was not in the company’s best interest at that time. In the end, Apple decided not to adopt the Flash Platform because Flash would limit its ability to differentiate its devices. Apple marketing was focused on the broad availability of apps that worked best on iOS. To support such positioning, Apple needed developers to target the latest set of proprietary APIs (accelerometer, compass, gyroscope, etc.) rather than write to a higher level cross-device platform that would deliver undifferentiated experiences across Apple and non-Apple devices.  This is why Apple decided to block Flash from iOS (for more on this see: Why Steve Jobs will never put Adobe Flash on iOS devices).

Adobe did react to the disruption the iPhone had created and adjusted its business model, but it was too late by then. In March of 2008, Adobe announced the Open Screen Project essentially making the player free for OEMs as long as they implemented it in a consistent way for developers. To ensure consistency for developers, Adobe also began to create its own binary implementation of the player for the leading mobile platforms in the same way it had always done for Windows and Mac OS on the desktop. However, with “Flashless” iOS devices leading the charts and HTML5 adoption increasing on mobile devices and web properties, the writing was already on the wall and there was no turning back. Adobe had been unable to disarm the time bomb in time and it eventually exploded.

Flash for mobile is dead, but Flash for the desktop lives on, right? Wrong!

It’s pretty simple: Flash for the desktop cannot survive without mobile support. With PCs becoming a smaller and smaller share of Internet connected devices (see chart below), it’s only a matter of time before most web sites will be updated to not require Flash. It is hard to imagine many examples of web properties that would want to exclude the majority of the eyeballs on the internet by requiring Flash.

VisionMobile - Desktop vs. mobile device shipments

Of course, web sites don’t have to remove Flash content outright. They can add logic to serve Flash content for desktops and HTML5 content for other devices. This will in fact be the case during a multi-year transition to a “Flashless” internet. As new content is created that excludes Flash, as HTML5 adoption and capabilities catch up to Flash, and as the share of PCs continues to decline, the percent of web sites that serve Flash content on the internet will approach zero, causing Flash on the desktop to die a slow death.

Note that this transition began several years ago as web properties adapted to support iOS devices — which account for a whopping 62% of mobile browsing page views! YouTube, one of Adobe’s flagship references already added support for HTML5, dealing Flash a major blow. jQuery, a popular JavaScript library that competes with Flash for building interactive sites has already overtaken Flash. The tide on HTML5 is turning and it’s only a matter of time before Flash on the desktop suffers the same fate as its mobile sibling.

To recap, the seeds for Adobe’s failure with Flash were planted many years ago with a revenue model that made sense at that time, but remained as a ticking time bomb for far too long. The model caused Adobe to move in a direction that was opposite to where the market ultimately moved to, especially after the launch of the iPhone (feature phones versus smartphones, OEM requirements versus developer requirements, operators as channel versus Apple and Google as channel). In addition, when the iPhone was launched, Adobe moved too slowly to adapt to the new market reality (3 years to launch Flash Player 10.1), ultimately killing Flash.

What do you think? What do you believe went wrong with Flash in mobile? Do you think Flash will survive on the desktop?

– Francisco

[Francisco Kattan has worked in the mobile ecosystem for over 10 years, including as Director of Product Marketing and Developer Relations for Adobe’s Mobile Business Unit. He also held leadership roles at Edify, Openwave, and currently Alcatel Lucent where he is Senior Director of Product Management. Follow Francisco on Twitter @FranciscoKattan]


  • >What do you think? What do you believe went wrong with Flash in mobile?
    You pretty much covered it. 😉

    >Do you think Flash will survive on the desktop?
    If they open source it, or if they potentially sell it off (who the heck would buy it, though?! Zynga?). Otherwise it's days are numbered.

    • Hi Scott, thanks for sharing. I think it is unlikely that someone will want to buy Flash as you suspected. The bigger point still applies, however (open source, acquired, or not): without mobile the desktop version would not survive in my view. This is because a desktop-only solution would miss an increasingly large share of eyeballs (as illustrated in the chart above). So any acquirer or open source project would have to revive the mobile version as well.

  • Ben Hookway

    One of the key aspects to forecasting the new post-Fash landscape on the desktop is DRM. To my knowledge (and I'm open to opinion), there is no agreed, practical DRM in HTML5 streaming.

    In order to have valuable content streamed on the desktop, many content companies insist on Flash or Silverlight (hence Sky's use of it) because they have DRM built in. Until this is addressed in HTML5 I wouldn't bet on desktop Flash eroding so quickly.

    • You are correct Ben. HTML5 does not yet support the needs of premium video content providers and this is one of the reasons Flash on the desktop will die a slow death as opposed to a quick death. Overtime I expect HTML5 to catch up, especially with Adobe behind it now.

      To drill down a little, there are two main methods for sending video from a server to a device: RMTP streaming and progressive download. With RTMP streaming only the bits that are being viewed are stored on the device which makes it hard to copy the video file being viewed. Progressive downloads work like regular file downloads except that the videos begin playing before the entire file is downloaded. As you can imagine, it’s much easier to pirate progressive downloads because the entire file is stored on the device. HTML5 supports progressive video downloads only, where as Flash supports both methods.

  • A few things are missing from this story:

    1. Doing Flash for mobile ranges from technically very hard to impossible, depending on the silicon. The device widely in use in tablets (the Tegra 2) cannot efficiently do HiP H.264, the most common codec profile in use on the web. I explain the difficulties here:

    Flash for mobile is not a case of management will-power: you cannot just whip engineers until they make it happen. I can quite understand why Adobe gave up flogging a dead horse.

    2. DRM. Valuable content (licensed movies in YouTube, Hulu TV, etc.) will not appear in HTML5 until HTML5 video has some form of workable DRM. When will that happen on HTML5?

    3. Codec battles. HTML5 doesn't have a universal video codec. The content providers prefer H.264 HiP (to keep streaming costs down). Flash supports this, but with HTML5 a bunch of browsers can't (for patent licensing reasons). And the free codecs (WebM, Ogg) are not supported in mobile hardware (nor, generally, is H.264 HiP). Until HTML5 resolves the codec issues such that all devices can play the content that providers wish to provide, we have a continuing problem.

    • Great insights Ken. There is definitely a technical challenge for playing many Flash videos on constrained devices. Perhaps this is something that Moore’s Law may have fixed over time.

      With your comments on DRM and the ongoing video codec battle, you make a key point that is worth highlighting: Standards based innovation (such as HTML5) moves much more slowly than proprietary innovation (such as Flash). Back in the day, Flash emerged because HTML innovation stalled for a long time. Flash enabled creative designers to deliver rich experiences consistently across browsers via the plug-in model. Now with HTML5, the web is finally moving forward, but the process is painfully slow. There is still no agreement on the video codec as you pointed out and some future innovations will also likely have to contend with similar conflicts. Perhaps if Adobe had executed faster in mobile, Flash could have survived. There is often room for proprietary innovation around slow moving standards.

  • This was an excellent article on the 'fall' of Flash: a great viewpoint from an inside source – I haven't developed in Flash for the last three years (mostly because I figured its demise would eventually come as well as various other reasons) – I choose other methods to develop so that the maximum amount of end-users are capable of following through easily with no issues doing so: maximum end-user experience and obtainment has always been above language/personal preference for me as a developer; understanding that the client wants their investment to lead to a wide audience. As noted, Flash was always playing catch-up as well as succumbing to a different ideology that eventually failed.

    In the end, it's not about whether supporting (or not supporting) Flash is the issue: it's about finding a solid resilient trend that generates maximum usability without hogging resources, leaves out certain audiences (non-Flash users), and adapts to trends. The longevity of the 'end-user experience' is the utmost important factor when developing any site.

    Thank you for an insightful article Francisco; I'll admit, while most of the obvious elements of Flash's fall were obvious, there were some new things brought up in here that got me by surprise, so thank you for that insight : )

  • Christopher Deutsch

    That may be your perspective, but as a consultant, the decrease in demand for Flash pretty much has the exact opposite curve as the rise of iOS. Your over thinking it.

    But at this point I don't really care. Flash has been off my radar for a long time now and sits in my mind next to ActiveX and AOL.

    • Christopher, thanks for the comment. You highlighted a symptom of the problem (fall of Flash =~ rise of IOS). As I mentioned at the top of the article, Flash mobile ultimately died because Adobe did not adapt fast enough to the changes in the post-iPhone ecosystem. However, some readers may be interested in understanding the root cause of the problem. Why wasn’t Adobe able to adapt? That is the main question I tried to answer.

  • redpola

    Great article, but for a couple of points.

    1) App stores have been around in Europe for some time. They were so unwieldy to use that only über-geeks bothered. A small point, but worth making I think.

    2) Flash lite was a piece of crap. Honestly, the code was atrocious. At the time I was a QA manager and then Engineering manager shipping our (high quality) port to hundreds of thousands of devices as part of our core product. It was embarrassing, and we were constantly looking for ways to dissuade our customers from requiring any flash playing component because we simply couldn't fix enough bugs in this code we didn't own. Then we'd give the flash guys detailed defect reports and even code fixes and they would ignore them, giving us more work applying our own patches to each source drop of flash.

    3) As Jobs implied, the life cycle for flash lite was so divorced from what real customers wanted in the embedded world that anyone delivering any kind of flash player of any quality was immediately delivering disappointment. Admittedly there were practical reasons why flash running on a smartphone or set top box is slow and crap, but there were management reasons that our customers were unhappy, and they were that flash lite was years behind flash proper. It was under resourced and under loved.

    For the record I would have loved flash lite to have become a great platform for embedded but even from a simplistic engineering point of view the code was too poor, too patched, too convoluted.

    • Thanks for sharing. Yes, there were many app stores before the iPhone – not only in Europe but worldwide. We just didn't call them "app stores" at the time, and as you indicated, did not work very well. I wrote about this some time ago here:

      Regarding Flash Lite:

      Flash Lite did solve an important problem at the time, especially for OEMs. It was just not the same problem that web developers needed solving (delivering consistent experiences across devices). This was not a big issue initially because mobile browsing was virtually nonexistent in any case. However, when mobile browsing finally took off in 2007 (thanks the first generation iPhone), this discrepancy in expectations created a big gap that Adobe did not solve until 2010 with Flash Player 10.1

  • sammymaudlin

    I agree with much of what you say but the whole "Flash is dead" mantra is not quite the reality. Firstly I think this says more as to what the ticking bomb was than anything- http://mobilecashsecrets.net/blog/?p=558 .

    Flash can currently do things that HTML5 can't or at least not easily. For those who want a branded, interactive, animated web presence there isn't anything that can do it as easily/affordably as Flash. Also important to note that HTML mobile sites generally suck too. At the present time the best way to have a mobile presence is to have a site that is optimized for mobile. To try and do one site that works beautifully everywhere is not practical today.

    Flash won't die as much as morph. Adobe will either allow Flash to be exported as HTML5 or will beef up Edge to allow a Flash inspired interface to export a Flash-like experience. Or maybe they'll keep Flash but have it operate in the cloud. Or…

    So even though not "Flash" persé it will still be a web experienced rooted in Flash.

    • Thanks Sammy. You are right. Flash is not dead, literally. But Adobe has already decided to kill the Flash player for mobile devices and I believe the Flash player will also die on the desktop as a result. Because of the reasons you mentioned, Flash will die a slow death, but will die nonetheless. There are still reasons to use Flash as you indicated, but those reasons will become fewer over time. Adobe is now committed to HTML5 and (with the rest of the industry) will help HTML5 catch up to Flash.

      Your insight about "Flash won't die as much as morph" is a good one. I believe this applies to Flash the tool – not the player. Adobe will invest in creating world class HTML5 tools – this is core to the company (note Adobe Edge and the acquisition of Nitobi/PhoneGap). However, Adobe's ambition to compete with Flash as a runtime platform is now doomed.

      Thanks for sharing the link to the quote from Walter Issacson, Steve Job's biographer. It is true that Steve was unhappy with Adobe because Adobe did not support the Mac as well as Windows (Adobe tools would ship first on Windows, then on Mac, for example). However, the issue about Flash on the iPhone was more complex. There were other, more compelling reasons in my view (as I described in this article).

  • Dean

    You didn't mention quality problems with Flash. Steve Jobs claimed that Flash had serious quality problems that Adobe was not addressing, and that was why he was dropping flash from Apples OSes. Was that just a red herring?

    As a Flex developer I laughed when you mentioned the possibility of Adobe making their money off of Flash tools that they would sell to developers. Their Eclipse-based Flex development tool is probably the worst commercial plugin in the Eclipse ecosystem.

    I would add to your article Adobe's poor quality and technical ineptitude.

    • I did not mention the quality (or other technical) problems because I believe those were an excuse by Steve Jobs and Apple. The real reason was a calculated business one: supporting Flash would limit Apple's ability to differentiate its devices. I wrote about this here:

      After I wrote that post, Steve Jobs himself confirmed via his "Thoughts on Flash" rant that "the most important reason" for not supporting Flash was a business one. Here is what he said:

      ”Flash is a cross platform development tool. It is not Adobe’s goal to help developers write the best iPhone, iPod and iPad apps. It is their goal to help developers write cross platform apps.” …. “We cannot be at the mercy of a third party deciding if and when they will make our enhancements available to our developers.”

      This does not mean there were no technical or quality issues. There were. But those problems could have been resolved with mutual interest on both sides. The business reasons trumped the technical reasons, as is often the case.

  • Albert

    What do you think is going to happen to the Flash authoring tool itself? And also to ActionScript? Flash professional, in my opinion, is still a great tool to use for creating animation, interactive presentations, games, etc… that don't necessarily need to run on a browser. You can export your animation into a video format, publish to a .exe or .app file, and export to iPhone. So while the death of the Flash player seems a sure thing according to many, what about the Flash IDE and ActionScript?

    • Albert, thanks for raising the issue of the Flash Authoring tools. Adobe has the daunting task of migrating its Flash/ActionScript developer community to HTML5 without losing developers to competitive HTML5 tools. As Sammy suggested (see comment above), Adobe will likely “morph” the Flash tools so they output HTML5. This would enable existing Flash developers to leverage their existing skills in timeline animations and ActionScript to produce HTML5 content. In addition, Adobe needs to maintain the Flash tools because they are also used to create standalone apps using Adobe AIR. The topic of Adobe AIR deserves its own article which I want to write later on –keep an eye on my personal Blog: "Insights on the Mobile Ecosystem" at http://franciscokattan.com 😉

  • daxo

    Full flash player 9 in nokia n770, n800 and n900. Flash 10.1 in n900 in internal prototipe. Full web experience but… no $$$$ from nokia, flash 10.1 never release. N9? No flash support.

  • Shoyo

    Not here to defend flash, but the article is a little radical.
    Flash "death" as you say, is a supossition, not a fact yet.
    Flash has it's pros and cons, just like HTML/JS/CSS.
    It's a matter of decision.

    Now as far as the flash is concerned.
    I'm still curious with what the future reserve on that matter.
    Flex being donated to Apache, and Flash with graphic acceleration.
    Maybe Apache can add some graphical acceleration on Flex components.
    Imagine some gorgeous looking components for web development, with a nice usability.

    peace out,

    • Thanks for sharing your insights Shoyo. You are Right. Flash has not died yet. I’m only predicting that it will die because it cannot survive without mobile support. I don’t think reaching this conclusion takes too much of a leap of faith. Flash was valuable because it was ubiquitous. To measure ubiquity you must look at all internet connected devices, not just desktops. Desktops are already less than 50% of internet connected devices and it’s only going to get worse (and it will get worse fast given the faster growth in mobile and tablets compared to desktops).

  • Francisco, having been an insider as well and having worked alongside with you, I think you got it pretty much dead on. Adobe killed Flash. Not Jobs, not the fragmentation, not Android, not anything but purely Adobe's management team and lack of foresight into the new breed of SmarPhones.

    There were three initiatives inside of the mobile BU for Flash on devices. That just shows you how wrong it was from them to begin with. You can just imagine the confusion it was causing not only inside of the BU but externally both to dev partners and developers as well.

    The one common theme I kept hearing from mobile developers was that they wanted a way for Flash to create stand along apps. This is early 2007. Yet, it went unheeded. When your developers tell you they want this, you pretty much have to listen otherwise, the platform will never take off. It is, at the end of the day, like the now famous Steve Ballmer dance, "Developers, Developers, Developers".

    After fighting an uphill battle, I pretty much left Adobe and started Ansca with Walter, who also happened to have been the lead architect for Flash Lite 3.0. We pretty much embarked into creating our own rapid stand alone application framework to enable us to quickly deploy apps and across different platforms.

    From our first initial prototypes, Corona SDK was borne. And today, over 6,000 apps have been created and from the same code base you can target iOS and Android. It is based on Lua which is very similar to Actionscript and Corona is light weight, fast, and has a built in physics engine (box2d) natively.

    Corona SDK apps have been on the top of the charts across all major stores. iTunes, Amazon, Nook, and Android Marketplace.

    I welcome all the flash developers who are pondering its future to take a look and give Corona a try. http://www.anscamobile.com

    • Hey Carlos, thanks for dropping by and sharing your insights as a fellow Adobe Alum. I agree with you on the issue of not responding to developer requirements promptly. As I mentioned in the article, there were often conflicting requirements between developers and OEMs. Since OEMs were paying the bills (the ticking time bomb), it made it hard to satisfy developers as well. In fairness to Adobe management, the extent of the changes in the ecosystem that were about to happen in 2007 were not easily predictable. It was a complete reboot of the ecosystem. Adobe, like so many other incumbents, was unable to adapt fast enough and paid the price. Congrats to you and Walter on building such great momentum with Corona SDK, BTW.

  • A few things I would add is that Flash Cast was something developed for NTT DoCoMo iMode and, as Kattan writes, a walled garden approach, just as the iPhone was disputing the whole ecosystem, and Adobe was not only licensing Flash Lite for a fee, but also seeking a revenue share of the premium content being delivered over Flash Cast (but got nothing from NTT DoCoMo, as they were the first customer). If the Verizon deal had been implemented and deployed in 2005 or 2006, maybe there might have been a fighting chance. – John

    • Good point on DoCoMo and thanks for mentioning it. Flash Cast had been extremely successful for DoCoMo. Like Apple, DoCoMo had complete control of its ecosystem. Although DoCoMo did not manufacture its own handsets, it had virtually complete control over its OEMs, dictating handset specs. In addition, developers had to work with DoCoMo in order to reach consumers. Verizon Wireless was in a similar position in 2005/2006, but all that changed after the iPhone and Android launched.

  • Ian

    I think you've missed quite a few things….

    One of the bigger ones is "Smart TVs", who manufactures have all started putting the flash player onto the chipset hardware directly. I would say there is possible a bigger market in TVs than there are in smartphones.
    This is a an area under most people's radar but demand for developers is already flourishing.

    Secondly, you havnt mentioned AIR at all which is an effective way of creating Flash applets cross platform (including on smart TVs).

    Thirdly, I dont think HTML5 is up to the job. It is doubtful there will be a solid cross-browser standard that will actually work in practice so we will all end up with usual development issues of trying to make it work on different browsers.

    • Ian, good call on including TVs in the discussion (and even other consumer electronics devices like game consoles). Unless I missed it, Adobe did not mention any specific plans regarding these types of devices. In any case, I don’t necessarily agree that TVs would be a bigger market than smart phones – certainly not in terms of units shipped. Still, the issue is that without mobile and tablets, Flash will not have ubiquity across internet connected devices.

      I’d like to write another post on AIR but consider this: the idea with AIR was to leverage the momentum in Flash to enable Adobe’s thriving ActionScript community to target standalone apps. If Flash dies, will AIR have enough momentum of its own to thrive? I don’t think so. Adobe is shifting resources from Flash to HTML5. In addition, Adobe is now promoting HTML5 and PhoneGap for standalone mobile apps. Adobe has been clear that the future is about HTML5.

      You raise a very important point regarding HTML5. HTML5 is no panacea. Even after it catches up to Flash, HTML5 will not be implemented consistently across browsers. Worse, because browser replacement cycles are incredibly long (IE6 is still around 5 years after IE7 launched), developers will have to live with a fragmented HTML world. However, this does not change the fact that Adobe has killed Flash in mobile, and in my view, Flash cannot survive without mobile support.

  • Yop

    flash ? dead ? Just wait and see. In 2 years you will post the same stuff with html 6 ^^

  • arth

    Great article : I would have said for enter Steve Job : ALT-COMMAND-ESC = FORCE QUIT 🙂
    Very good otherwise

    • LOL. Good point Arth! I was looking for the "restart" metaphor – not the "kill" metaphor. So "APPLE-RESTART" would be even better 😉

      The point, of course, was not that Steve Jobs killed Flash… but that the introduction of the iPhone caused a complete reorganization of the ecosystem and Adobe, like many other players — Nokia, RIM, Palm, etc.– were unable to adapt. Operators became pretty much irrelevant for developers, consumers began a mass migration from feature phones to smartphone, Silicon Valley players (Apple, Google) took the driver seat from Asian and European players… pretty much a complete "restart" of the system.

  • You missed a huge piece of the puzzle. While mobile systems used to tout streamlining, all the new handset and desktop systems (except win8, the jury is still out on that one), are beginning to bloat again. In addition, the original end users of flash (media companies and artists), are ignoring html 5 in favor of flash. It is how artists reach clients, and many do not develop or update apps.


Distilling market noise into market sense

What gets desktop developers out of bed in the morning?

desktop developer segmentation

Despite all the hype around the death of the PC and the enormous amount of media attention focused on mobile,…

Continue reading ...

A proven model for targeting IoT developers


  What if you could identify a handful of developer personas, or segments, each with a very distinct set of…

Continue reading ...

1000 skills: Amazon Alexa as a metaphor for the IoT developer community


Alexa is a centerpiece of Amazon’s Smart Home push, and quickly growing to become one of the most promising attempts…

Continue reading ...


Research on the app economy and developer ecosystems

Developer Segmentation 2014


The Developer Segmentation Q3 2014 report is the most sophisticated study of developer segments to date. The report delivers a…

Continue reading ...

App Profits and Costs


This research report examines the critical success factors for a profitable app, and how business and technology choices, such as…

Continue reading ...

Developer Segmentation 2013

Developer Segmentation 2013

The Developer Segmentation 2013 report delivers a needs-based segmentation model that actually works, with extensive profiling of the eight principle…

Continue reading ...