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]

 

[Report] Developer Economics 2011 – Winners and losers in the platform race

[Who is leading in the platform race – and who’s lagging behind? Marketing Manager Matos Kapetanakis examines the flow of developer mindshare and discusses how success is measured in the app era – in part 1 of our 3-part blog series on our newly released Developer Economics 2011 report.]

Developer Economics 2011 – free download here – has been created by VisionMobile and sponsored by BlueVia.

VisionMobile - Developer Economics 2011 - Platform race

Developers driving innovation


The role of mobile developers has changed dramatically over the past three years, from a lowly position as back-room engineers to the much-sought-after engine that drives mobile software innovation. Never before have developers, from big development houses to aspiring students to garage entrepreneurs, had such an enormous impact in mobile industry innovation and dynamics.

Handset manufacturers, platform vendors and even network operators (or carriers to our American readers) are competing over who’s going to build the biggest developer community, as success today is measured in terms of thousands of apps and billions of downloads. Platform and OS vendors are the most active in this game, trying to steer developer mindshare towards their platform and create a new plateau of innovative services, as well as a whole ecosystem around them.

So, which platforms lead the race and which are lagging behind?

The platform race

In the platform race for developer mindshare, there are some clear winners. According to our research, the developer mindshare is firmly flowing towards Android and iOS, with 67% of developers currently using Android and 59% using iOS.

VisionMobile - Developer Economics - Developer Mindshare

These figures show a considerable increase since last year, with the two platforms climbing nearly 10%. In contrast, the ‘old guard’ comprised of Java and Symbian are leaking developer mindshare.

However, the most surprising finding is the adoption of mobile web, i.e. the platform for apps written in HTML or JavaScript, which claimed the 3rd spot in terms of developer mindshare, being used by over 55% of the developers. We do not attribute this to the ease of learning this platform (which has a deceptively steep learning curve, as you can see in the full report), but rather the influx of non-mobile developers to the industry. Also, mobile web is fast becoming the de-facto cross-platform choice for developers, especially now that Java and Flash are waning. In addition, there is a veritable host of HTML-to-native development tools that are helping HTML/JavaScript developers target smartphone native app markets.

More on Developer Mindshare in the full report.

It’s also worthwhile to take note of the Developer Intentshare, i.e. the platforms that developers are planning to use.

VisionMobile - Developer Economics 2011 - Intentshare

Android still reigns supreme, but the surprise comes in the form of Windows Phone, which is fast becoming a developer favourite. Despite lukewarm sales in 4Q10 and 1Q11, the newly revamped Microsoft platform has managed to gain the vote of developers.

This can be attributed to a number of reasons: First and foremost, Microsoft has actually released a competitive platform with a strong toolset. Also, the platform’s future seems bright, after the now-famous Finnish Deal. Finally, Microsoft has invested a lot of time (and money) into attracting developers, tapping into the Xbox and Silverlight developer communities to divert the flow of mindshare in their favour.

The inclusion of Chrome OS in the top 5 platforms in Intentshare is more a result of curiosity for Google’s dark horse platform – how will it stack up to other platforms? MeeGo also seems to be vibrant, which goes to show that strong developer communities go a long way in this software era.

In contrast, BlackBerry has lagged behind in Intentshare, suffering from fragmentation issues (see our full report for the surprising answer to which platforms are the most fragmented), as well as minor fixes to an aging platform.

Who’s lagging behind in the platform race? Symbian and Java have suffered the biggest losses in terms of developer mindshare. Nearly 40% of developers currently using Symbian and 35% of developers currently using Java ME are planning to abandon the platforms.

VisionMobile - Developer Economics 2011 - Abandon index

No surprises there, especially in the case of Symbian, which carries an expiration date, despite Nokia’s slow transition to the WP platform. Java’s loss of mindshare is less expected, especially considering the platform’s reach as global sales are still dominated by feature phones – but developers are not sticking around for that.

Palm’s platforms are also being rapidly abandoned by developers, since Palm is all but dead and HP has still to ship its first webOS handset.

What’s in a platform?

 

How do developers make that all-important decision of which platform to select? Well, according to our research, the biggest driver in platform adoption is large market penetration – a sentiment shared by 50% of our respondents, irrespective of the platform they spend most of their time on.

VisionMobile - Developer Economics 2011 - Platform adoption

But what exactly is market penetration? A platform’s installed base is an important aspect – i.e. just how many actual handsets can run a given app – but that is not all. Penetration is also measured in terms of a platform’s ability to reach users and that is also a factor of how and where that content is available. – a centralised distribution and discovery point, such as an app store, accessible by mobile devices, tablets and PCs goes a long way towards providing developers with a direct access to their customers.

Proving that there’s more to market penetration than a large installed base, we present the case of handsets sold vs. apps. There is a large discrepancy between the number of handsets sold and the number of apps available on a given platform.

VisionMobile - Developer Economics 2011 - Apps vs. sales

In an app economy with close to 1 billion [Update: million] apps, more than half of those are concentrated on two platforms: iOS and Android. It’s easily apparent from the graph that vastly more pervasive platforms in terms of total shipments, like S40 and Java claim just a fraction of the app pie. Granted, this is a smart-centric game, but even a pervasive smartphone platform like Symbian cannot much app to the two app moguls.

Do apps mean money? Not directly, but it’s no coincidence that 2011 marks the first time Apple overtakes Microsoft in terms of revenues and Android rushes past the finally burned-out Symbian platform in terms of shipments.

-Matos

Want more Developer Economics?

Follow us on Twitter (@visionmobile) for updates and stay tuned for part 2.

And for those of you who still haven’t done so, don’t forget to download the full report!

[Survey] Developer Economics 2011: The evolution of app development

[Developer Economics 2011 is here! As we launch our new survey on all things developer-related, Marketing Manager Matos Kapetanakis looks back at the 2010 report and examines the major events that have shaped mobile development in the past 6 months]

VisionMobile - Developer Economics 2011

The evolution of Developer Economics
Last July we published the definitive mobile developer research report: Developer Economics 2010, dubbed by TechCruch as “one of the most profound…to date”. Our report delved into all aspects of mobile application development, across a sample of 400+ developers segmented into eight major platforms.

We’ve just launched the follow-up to this research report: Developer Economics 2011, once again made possible thanks to BlueVia, the global developer platform from Telefonica that helps developers take apps, web services and ideas to market. Our goal is to see how the dynamics of the developer world have changed since early 2010 and to provide more insights into app marketing, monetization and many other factors.

Join the survey or help spread the word! This year we ‘ve also secured a prize for each of the first 400 developers; 10 hours free testing time on DeviceAnywhere’s 2000+ handsets. UPDATE: Thanks to overwhelming support, all 400 free testing time prizes have been awarded by DeviceAnywhere. Of course, the $1,500 Amazon voucher is still up for grabs!

Major shakeups of the mobile industry for H2 2010
So, what’s changed since our 2010 research? The mobile industry is an ever-evolving landcape. In the past 6 months we have seen the Symbian Foundation close shop, with Nokia hoping that the as-yet untested MeeGo project will carry their smartphone banner. We have also seen the stellar rise of Android, zooming past Apple’s iOS and BlackBerry and becoming the no2 smartphone platform behind Symbian.

In the handset OEM arena, we have seen more shakeups in 2010 alone than in the 10 years preceding it. Apple and RIM have overtaken some of the traditional handset OEM powers (Sony Ericsson, Motorola, LG) and claimed a spot in the top 5. According to some estimates, ZTE could join them soon.

Moving forward, Developer Economics 2011 is looking at how the key metrics of mobile development have changed in the last year.

The migration of developer mindshare
One of the major findings of our 2010 report was the migration of developer mindshare away from the ‘old guard’, i.e. Symbian, BlackBerry and Java, towards the new powers of the realm – iOS and Android. According to our research, nearly 60% of the 400+ respondents had developed apps on Android. Apple’s iOS took second place, with more than 50% of respondents having a go at it, with Java ME following third.

In our Developer Economics 2011 research, we’ll be asking participants which platforms they’re currently targeting, which ones they plan on targeting and which ones they’re abandoning.

So, what’s changed since then? Well, if anything, the gap between Android and iOS and the rest of the platforms has grown even larger. The Apple App Store carries more than 300 thousand apps, while recent estimates place the number of apps in Android Market at around 130 thousand.

While Nokia has been spending considerable effort on the Ovi Store and increased its popularity with consumers and developers alike, they still have a long way to go to catch up with the two app-dispensing behemoths.

Why do developers head towards iOS and Android? Our Developer Economics 2010 analysis showed that Apple offers a platform that is relatively easy to master and using which a developer can design great UIs. They also have the largest app store and although the certification problem is an issue for some,  porting and fragmentation are not a challenge;. Android, on the other hand, has been gaining momentum across all fields, storming its competitors’ key market – the US. Of course, Android’s many fragmentation issues are often overlooked in the face of many handset OEMs’ dependency on the platform.

The disparity between handset sales and available apps

Our Developer Economics 2010 research uncovered a disparity between the number of devices sold for each platform and the number of available apps. One would expect the platforms with the highest market penetration to dominate in terms of apps, but that couldn’t be further from the truth.

Taking 3Q10 as a reference, it’s easy to see that the two platforms with the lowest penetration, iOS and Android, have the highest number of available apps.

On the opposite side of the spectrum, while Java ME and Flash Lite have the greatest market penetration by far, they can scarcely measure up to the newer platforms when it comes to app volumes.

In Q4, the contrast is even sharper. Both Android and iOS stores have grown by almost 100 thousand apps apiece. Windows Phone has shown an admirable growth, reaching 4 thousand apps in just two months, although it still has a long way to go before becoming truly a threat to incumbents.

Monetization and revenue expectations

In Developer Economics 2010, we asked developers how they felt about the revenues they’re receiving from selling their apps. Almost one in four respondents reported poor revenues, while only 5% reported revenues exceeding their expectations.

VisionMobile - Developer Economics 2010 - revenue expectations

While there has been a boom of app stores, that’s not necessarily a blessing for developers. Most developers face a discoverability issues, having their apps buried under thousands of other apps. Like one developer said in our previous research “It’s like going to a record store with 200,000 CDs. You ‘ll only look at the top-10″.

What options are there for developers? One option is to adopt a multiple storefront strategy, as well as to tailor your monetization model to specific app stores. As the CEO of Rovio, creator of the prodigious Angry Birds app, noted: “Free is the way to go with Android. Nobody has been successful selling content on Android”.

Developing apps in 2011
Care to see how the apps world has changed in the last year? Stay tuned for Developer Economics 2011, where we delve into app development, monetization, distribution, retailing, porting and fragmentation issues among many others.

Mobile developer? Join the survey and have your say.


[Infographic] The Mobile Developer Journey

The Mobile Developer Journey

A few months ago, VisionMobile published Developer Economics 2010 and Beyond, a research report that tracked the entire mobile developer journey, from app design and platform selection to market delivery and monetization. Now, we’re proud to present the entire Mobile Developer Journey on a single infographic.

The Mobile Developer Journey

Developer Economics 2010 and Beyond was created by VisionMobile and sponsored by Telefonica Developer Communities.

Did you miss the chance to participate in our research and have your say on app development? Well, you can express your views in our upcoming developer research, Developer Economics 2011, which is just a few months away. Pre-subscribe here

Feel free to copy the infographic and embed it in your website.

600 pixels wide version

760 pixels wide version

1000 pixels wide version

[sociable_code]

The Flash vs. HTML5 Endgame

[In the debate of Flash vs HTML5, has the death of Flash been over exaggerated? Guest author Guilhem Ensuque peeks through thick layers of hype and facts to predict what the future holds for the mobile web].

The Flash vs. HTML5 Endgame

The last year has seen a flurry of announcements and debate around the rise of HTML5 and the fall of Flash. Some have even gone as far as declaring a “war” between the two, and predicting the “death” of Flash as the outcome. However, as Mark Twain once famously said: “The rumor of my death is an exaggeration”. As we’ll see, the jury is still out as far as the fate of Flash and Adobe are concerned.

A brief (abridged) history of the web
“HTML5” is the new high-tech industry darling, and not just in the mobile space. It has become a catch-all phrase with little meaning when taken out of context. Before we dig into the debate, it’s worth looking at what is HTML5 and where has it come from.

“HTML5” when used as a shorthand, covers of family of web technologies currently being standardised by the W3C and at various implementation stages by browser vendors. The “5” comes from the version increment in the W3C spec number: currently most of the content you read on the web conforms to the HTML specification version 4.01.

To understand what has driven the creation of this new version of web standards, we need to look at the evolution of the web in past years.

historyofwebIn the 1990s the World-Wide-Web emerged from academia to become the ubiquitous medium to share digital documents over Internet Protocol networks. The HTML4 spec was matured in that era, and has been very much geared towards read-only, document-oriented description and hyper-linking. HTML4 mixes typographical tags with document structure description, within the bounds of static pages and has limited support for script-driven page logic and forms (does anyone remember CGI?). In that era of the web, support for multimedia content was notably absent from the web specification; leading to heterogeneous plug-ins striving to provide video delivery in web pages (remember Real Networks? or having to choose the speed of your modem?).

In the 2000s, the web evolved towards more interactivity with the advent of the “Web 2.0” (yet another buzzword) and user-generated content, especially videos uploaded and then streamed over faster ADSL connections. However, the HTML spec did not fundamentally change (apart from an attempt by the W3C to migrate to the stricter XHTML syntax which has seen mixed results in terms of adoption). To cope with HTML4‘s inefficiencies in allowing designers and developers to create interactive “experiences” (i.e. not just documents, but bi-directional “applications” living in your web browser) a number of innovations were introduced :

  • JavaScript, Dynamic HTML and XML HTTP requests (a.k.a. AJAX) as a way to have thick-client app functionality in the browser, enabling users to interact with the web in a read-write fashion (not just read-only)
  • clear separation of page structure in HTML (through heavy use of <div> tags) as well as typoraphy and style in CSS (through an arcane and verbose syntax), leading to more pleasant user experience and richer page contents
  • PHP-scripted and database-powered back-end logic bolted on top web server systems. This e.g. allowed template-driven content management systems like WordPress and Joomla to rise to prominence, fueling the blog revolution.

These innovations brought the ability to present vast amounts of data in pretty-looking dynamic web pages which mash-in RSS feeds, emails, blogs, Facebook updates, and tweets, and bringing web pages a step closer to applications.

In that era, Flash (or rather the Flash Player) rose to become a ubiquitous browser plug-in for animated graphics and video. At the same time, Flash evolved to provide an out-of-browser Rich Internet Application platform with the AIR runtime and the Flex framework, albeit at a much lower penetration level than the in-browser Flash Player.

We are now at the dawn of the 2010s, and the overhaul of the HTML4 spec is long overdue. HTML5 aims to bring back into the core spec of the web the “side” developments of the previous era and improve on them with a heavy focus on web applications. It also aims to lay the foundations enabling the delivery of web content through a new medium: mobile devices, and ultimately the “Internet of Things”. That history is yet to be written, but we can now ponder about its beginnings and the future.

So, What is HTML5 Really ?
In the context of this new era, the “HTML5” shorthand refers to a family of web standards and browser technologies that span a range of topics:

  • A modernized web markup language: the true-and-only HTMLv5 specification and matching evolution in web browser capabilities. The new syntax includes the <canvas> tag allowing bitmap manipulation through JavaScript drawing APIs, better support for vector graphics authored in SVG, the <video> tag allowing streamed media playback as simply as embedding images and the streamlining of tag usage.
  • A richer styling language: the Cascaded Style Sheets v3 specifications. CSS3 is now famous for its ability to create rounded corners, but more importantly includes so-called “transforms” allowing graphical effects like moves, rotations, gradients, etc. as well as 3D graphical objects manipulations. Much effort as been put by browser vendor to support hardware acceleration for CSS3 rendering. However, the standard is not yet mature and today requires using prefixes specific to each browser.
  • Application-oriented advancements in the browser, as well as matching JavaScript APIs: the Web Workers offering background and concurrent execution capabilities; a Web Storage allowing simple local data storage and manipulation in XML; and a Web SQL Database  providing the capability to perform SQL queries on large amounts of data stored locally and replicated from a server.
  • Mobile-oriented advancements (not yet finalised in the specs) including JavaScript APIs for Geolocation, Device and File APIs
  • Miscellaneous additions catering for the Semantic Web (microdata), security (cross-domain HTTP requests), and more.

To the above set of technologies standardised by the W3C we should add a domain that has sprung out of both proprietary or open-source efforts: high-performance JavaScript runtimes within browsers and JavaScript Application Frameworks. The latter extend the capabilities of the web, turning it into a full-blown client-side application platform much in the same way that UI and application frameworks like Qt or Gtk extend the “bare” Linux OS framebuffer. Such application frameworks include complementary JavaScript APIs, and rely on CSS3 to provide extensive sets of UI controls. Some mobile-specific frameworks (like Phonegap or BONDI, an offspring of the mobile operator community) go as far as providing additional device APIs for smartphone features like messaging or camera, while others provide a rich set of UI controls mimicking the native platform look & feel (more on this later).

Why the clash with Flash ?
There’s no denying that the capabilities brought forward by the emergence of the HTML5 “family” bring browser runtimes on a par with core capabilities of the Flash Player, which if adopted widely could make Flash redundant.

In the eyes of most mobile industry observers, the delays in bringing out a fully-featured Flash Player with acceptable performance on smartphones have played in favour of HTML5. Remember that, as of today, Flash Player v10.1 is only available for high-end smartphones that run the Android version 2.2 operating system. I would estimate that these represent only 1% of the overall smartphone shipments in Q2. This is a far shot from Adobe’s self proclaimed goal of having Flash shipping on 50% of smartphones by 2012 (see my previous article on this topic).
smartphoneos_share_q2_2010

Figure: Smartphone Operating Systems – Q2 2010 Shipments share (source: Gartner, Google)

Company Browser / OS HTML5 compliance
Nokia Symbian S60 5th Ed. 7%
RIM Blackberry v5 0%
RIM Blackberry v6 (Torch)* 69%
Google Android v2.1* 50%
Google Android v2.2* 59%
Apple Safari for iPhone (iOS 4.0)* 62%
Microsoft IE Mobile (Winmob 6.5) 0%
Opera Opera Mini (on iPhone) 9%

Figure: HTML5 compliance of mobile browsers
[some notes on the methodology: HTML5 compliance was carried out using html5test.com. (*) denotes a WebKit-based browser. The Nokia Symbian S60 browser, albeit based on an old version of WebKit, scores poorly in HTML5 compliance tests. I could not test Mozilla Fennec, Palm’s WebOS browser, nor Opera Mobile.Opera Mini is a special case due to server-side rendering.]

Making things worse, Apple has stayed firm on its policy to not allow the Flash Player browser plugin on its iOS devices (iPhone, iPad and iPod Touch), preferring to rely on its in-house video streaming capabilities developed within its HTML5-capable WebKit browser core and QuickTime player. And to make things even more complicated, Steve Jobs’ “Thoughts on Flash” have played a key role in fanning the flames of the “Flash is dead, long live HTML5” fire.

Moreover, Google’s Android, Palm’s WebOS and, more recently, RIM’s Blackberry also embed web browsers based on WebKit that score very high in terms of HTML5 compliance, as can be seen in the table above.

Thanks to WebKit, half of the smartphones being shipped are poised to have the Flash-like capabilities brought by “HTML5” built into their browsers. However, let’s not rush in declaring Flash “dead” and Adobe a company in decline as a result.

Does HTML5 matter to Adobe ?
HTML5 is actually good for Adobe’s business. Indeed most of Adobe’s revenues do not come from Flash as can be seen by breaking down the Flash product portfolio::

  • The Flash Professional tool, is the authoring software for creating Flash content. It ships standalone or within the Creative Suite bundle. This is where Adobe makes its money as can be seen from the “Creative Solutions” BU share of the chart on the side (courtesy of Business Insider’s “Chart of the Day” series). Creative Suite also includes the massively popular Dreamweaver web design tool, and Illustrator, a vector graphics design tool, both of which which are now starting to incorporate HTML5/CSS3 design capabilities. Adobe has also hinted that Dreamweaver will be able to convert Flash timeline animations to Javascript/CSS3 code to render those animations in “HTML5” compliant browsers. This means that “HTML5” will not be a threat to Adobe’s main source of revenue. On the contrary, since there are few good commercial web design tools, the rise of “HTML5” will spur demand for Adobe products.
  • The Flash Player: the plug-in is free and is therefore represents  an R&D cost for Adobe. No impact there. One might argue that, if HTML5 were to totally eliminate the need for the Flash Player, it would the positively impact Adobe’s bottom line in the unlikely event the company were to lay off the entire Flash Player team 🙂
  • The Flash “Platform”: “auxiliary” products that rely on the Flash Player include the Flash Media Server and Flash Access product ranges, licensed to organisations that use Flash to deliver streamed video content (e.g. Hulu, Influxis, Brightcove). The “Platform” also includes the commercial Flash Builder IDE allowing the development of Rich Internet Applications (and the associated free and open-source Flex framework). As can be seen in the chart, these represent a minute proportion of Adobe’s revenue. As we will see further down, these products are not going to disappear overnight due to the emergence of HTML5.

However, HTML5 does put competitive pressure on the product management and engineering teams responsible for the Flash Player to out-innovate the evolutions in browser technology. Adobe points out that this is “business as usual for them” as –they say- it was never their intention to fully replace the browser altogether, but rather complement its capabilities with innovative features, and harmonise areas in which standards have been implemented in an inconsistent fashion across browser runtimes.

As an engineering-driven company, Adobe aims for Flash to stay one step ahead of HTML5 technology implementations, as it already is today in numerous areas. Indeed, an agile R&D division within a single corporate entity will always be faster than a “snail driven by a committee” as the W3C HTML5 spec bodies have been dubbed by some.

Some areas where Adobe is pushing the envelope for the Flash Player include 3D rendering with hardware acceleration, concurrency support, IP TVs and peer-to-peer media delivery. The latter is an interesting transposition of the file-sharing P2P concept; imagine tens of millions of users watching the same live video coverage of the opening ceremony of the 2012 Olympics in London. No server farm or CDN today is capable of sustaining such a peak demand. By allowing instances of the Flash Player across millions of peers to share chunks of the video stream at the edge of the network could be the answer to the problem.

Beyond innovation, another aspect to factor in is that HTML5 is still in its early stages of implementation across browsers, with Microsoft’s uber-popular Internet Explorer browser today lacking any form of HTML5 support whilst representing close to 60% of the web user base (see chart below). Even with the IE9 beta improving HTML5 support and other browsers consistently gaining market share it will still take some years before HTML5-capable desktop browsers dominate the installed base. This will justify the existence of Flash in the desktop browser space for years to come and give some leeway to Adobe’s engineering teams in designing more innovative capabilities.

Desktop browser market share

Company Browser HTML5 compliance
Microsoft Internet Explorer 9 beta 32%
Microsoft Internet Explorer 8 9%
Microsoft Internet Explorer 7 4%
Microsoft Internet Explorer 6 0%
Mozilla Firefox 4 beta 5 68%
Mozilla Firefox 3.6 46%
Mozilla Firefox 3.5 42%
Google Chrome v6 72%
Apple Safari v5 69%
Opera Opera browser v10 53%

Figure: Desktop web browsers users share and level of HTML5 compliance
(sources: wikipedia and test conducted with https://www.html5test.com)

Reality check: comparing Flash and HTML5 in key areas
So how is Flash vs HTML5 faring today? For review purposes we can single-out a few key areas of Flash and HTML5 competition, specifically display advertising, video delivery, games and application development.

Display Advertising: a slight advantage for Flash
One of the main use cases for Flash (and big source of annoyance to web users) is display advertising. “Display” adverts are animated banners that appear at the top, side or overlaid in front of the web content you. As annoying as they may be, display ads are a necessary evil for the online world since they represent 40% of the revenues that the digital content and e-commerce ecosystems live on. Even Google uses Flash in its DoubleClick Studio rich advert SDK for advertisers.

Some have said that because HTML5 will kill Flash, those annoying ads will disappear. I would rather think that they may be replaced by equivalents designed in HTML5/CSS3, with the caveat that they may look crappier in most of today’s browsers than their Flash counterparts, as can be seen from these examples.

Indeed a point often overlooked is that today’s HTML5 graphical rendering capabilities are at the level of what Flash capabilities were some years ago and CSS3 transforms allowing to design good “eye-candy” are inconsistently supported across browsers. Therefore I would argue that advertisers will hold back from using “HTML5” for display ad creation in the medium term. The lack of proper HTML5/CSS design tools will also delay this technology adoption by design agencies and creative professionals especially within  industry circles where Flash is deeply entrenched.

On mobile devices, the situation will be no different. The blue legos now seen on iPad and iPhones may soon be replaced by HTML5 counterparts; or even by iAds. However, as of today, Apple is the only company creating iAds (in the process levying a hefty ad tax) and is reported to be struggling with the demands of advertisers with its in-house HTML5-based ad creation tools and technologies.

Video Delivery: advantage for Flash
Another area in which “HTML5” has been touted a “Flash killer” is online video delivery. Let’s have a look. As far as basic video playback is concerned, Flash and HTML5’s <video> tag provide the same capabilities, so why not ditch Flash and avoid to end users the (relatively minimal) hassle of installing a plugin?

The situation is not as simple as it sounds as the various browser vendors do not yet all support the same video codecs. On one side, Apple and Microsoft are proponents of H.264; Google is pushing its opensource WebM codec (formerly the proprietary VP8 codec that it inherited through the acquisition of On2/Sorenson); and Mozilla and Opera by default supporting the free and opensource Ogg Theora.

This poses a challenge to online video publishers like YouTube since they then have to re-encode their content multiple times to support each codec.

To end users, this means that videos may not be available in the format supported by their browser. Flash on the other hand, even though it requires videos to be packaged in the FLV container format (not to be confused with encodings like H.264), is available across all desktop browsers and is used as a reliable fallback by “HTML5” web developers i.e. for the 50% or so of IE end-users whose browser can’t render the <video> tag.

Furthermore, the Flash Player supports advanced capabilities required by online publishers such as DRM protection (crucial for pay-per-view business models) and picture-in-picture overlay of multiple video sources with alpha-blending (e.g. for e-learning or overlay of contextual adverts). These capabilities may not be offered for years with the <video> tag in HTML5 browsers.

Casual Games and Visualizations
Flash is the technology that powers some massively popular “casual games” (such as Zynga‘s Farmville or Mafia Wars) played by millions of Facebook users worldwide. It also powers numerous other Facebook applications. There was earlier this year a rumor that Zynga was converting its titles to HTML5 to be able to run on the iPhone and iPad. This turned out not to be true, as it announced at Apple’s WWDC that it had ported Farmville to the iPhone as a native app; which may be interpreted as a sign that “HTML5” was not up to the task.

farmville.320x480-75 Another area in which today Flash is massively popular is that of visualizations and generative art. There is a large and enthusiastic community that has turned Flash animation into a true art form. Artists like Erik Natzke or Yugo Nakamura (of the Tha agency) are prominent examples of this community. To date, I have not seen any such artistic usage of “HTML5” technologies.

Other “HTML5” demos that have received a lot of media attention are Google’s “bubbles” doodle earlier this month, its experiment with Arcade Fire or a port of Quake to JavaScript using GWT. However, I do not yet see casual games developers or visualization artists migrating “en masse” away from Flash. This may be explained by the fact that those experiments in “HTML5” remain CPU-intensive and RAM-hungry (more than Flash in most cases), while designer-grade tools are lacking, and the fragmentation between browsers makes Flash a lot more dependable.

Applications Development: a draw
Web app development is another technology domain where the HTML5 family of technologies has been contending with Flash.

We have seen earlier that “HTML5” provides most core capabilities needed to run local applications, including code execution, storage and access to the screen. These core capabilities are now complemented by a flurry of web application frameworks that rely on JavaScript / CSS: DoJo, JQuery, MooTools and Sproutcore, to name a few. Google’s Web Toolkit (GWT) represents a particular case since it is a framework + tools package that allows to code a web application in Java and convert it to JavaScript for execution in the browsers (note how Gmail, Buzzz and other Google apps are built with GWT).

More recently, these frameworks have been forked into mobile variants: JQuery Mobile, Sproutcore Touch and Sencha Touch. Sendra is actually a case in point: the developer company raised $14 million in venture capital, a testament to the significant size of the business opportunity, and has jokingly proclaimed “The End Of Native” (see photo).

This abundance of JavaScript frameworks may be encouraging, but also represents a dizzying array of choices for the developer. This diversity limits the degree of industry-wide code reusability and fragments the pool of Javascript app developers into vertical niches.

This diversity further plays in favour of Adobe’s own web applications platform AIR (a sibling to the Flash Player) and the associated Flex framework, which uses the Actionscript programming language and allows XML-driven UI design through its MXML language.

In my own experience, seasoned developers find ActionScript and MXML a much better programming paradigm than Javascript frameworks in most developer aspects; code reuse, team productivity, tools support, debugging and ease of UI design.

In conclusion, the momentum behind web applications thanks to “HTML5”’s core capabilities and associated frameworks may seem unstopable, especially as it is driven by technology behemoths like Google and a large enthusiastic community. However this optimism is mitigated by the lack of developer productivity and the rising popularity of Adobe’s application development technologies.

What of the Future ?
Based on the earlier analysis, Flash is far from dead today. There are many cases in which Flash will continue to offer a better alternative (worst case a very useful fallback) to “HTML5” technologies due to the fragmentation in new web standards browser support.

To the question : “will HTML5 kill Flash?” there is no single answer. It all depends on which use case is considered and in what timescale.

On the desktop front, it is the lack of HTML5 capabilities in IE8/9 and their immaturity in all other browsers, that will secure the future of Flash in the medium term. At the same time, Adobe is under pressure from Microsoft, Google and Apple who are betting huge R&D budgets in the development of HTML5-capable browsers and who should be able to out-innovate Adobe in the longer term.

On mobile, the Flash Player is still in its infancy, while WebKit-based browsers are sharply rising towards ubiquity (250 million and counting as of end 2009). This gives the “HTML5 camp” an edge today, especially in the area of basic video playback and mobile web applications for which numerous JavaScript/CSS3 mobile frameworks are available. Looking forward however, Flash may still better HTML5 on mobile for use cases like casual games and animated graphics given its greater dependability and its widespread usage today in those communities.

Where would you place *your* bet?

– Guilhem

[Guilhem Ensuque is Director of Product Marketing at OpenPlug. He has more than twelve years of experience in the areas of mobile software and mobile telecoms. Guilhem was a speaker at last year’s Adobe MAX conference. His favorite pastimes (beyond mobile software strategy!) include making his baby daughter smile and sailing his Hobie Cat with his girlfriend. You should follow Guilhem on twitter @gensuque_op]

Developer Economics 2010: The Role of Networks in a Developer World

[In the final part of our series on our latest research – Mobile Developer Economics 2010 and Beyond – Telefonica’s James Parton discusses the challenges facing mobile network operators in their quest to stay relevant to mobile application developers. Full research report available for free download or see part 1, part 2 and part 3 of the blog series on mobile developer economics]
The article is also available in Chinese.

"The Role of Network Operators in a Developer World"

Historically, operators have been one of the few options available to developers when bringing new applications and services to market. Typically this has been in the form of placing applications in the operator mobile web portal or via a handset preload agreement within the operator variant software build.

However operator go-to-market channels have suffered from a lack of transparency, lengthy bureaucratic processes and the inevitable arrogance of a dominant gatekeeper.  The rapid rise of app stores has completely rewritten the rule book, and now provides independent developers with a more open and democratic way to get their product in front of potential consumers.

The Developer Economics 2010 report graphically highlights this trend, with less than 5% of the 400 developer respondents persevering with the operator channel. Clearly app stores have delivered real economic benefits to developers, with time to shelf being reduced by two thirds, and time to payment being reduced by 22 days (see part 2 of our blog series) when compared to the Operator channel.

There are some notable exceptions to the trend. Andrew Fisher, CEO of Shazam, frequently highlights the Operator channel as one of the reasons for Shazam’s wide spread success, and recommends companies to invest in developing operator partnerships. Christopher Kassulke, CEO at HandyGames confirms that major games developers also prefer to invest in selling games via operators, due to the higher per-download price points and the sustainable, predictable revenues that the operator channel offers.

Opportunity lost?
A key question for operators is “Has the app distribution opportunity been irreversibly lost?” An interesting insight from the Developer Economics report is that the app store phenomenon is perhaps not as widespread as portrayed. Beyond the iPhone and Android ecosystems dominated by native app stores, there is a significant gap in the market for operators to assist in the distribution of apps and services. This is especially significant in the growing mobile web app sector.

Of course it goes without saying; unless operators fix the legacy issues with their lengthy bureaucratic processes and ‘ivory tower’ attitude then the distribution opportunity will remain untapped. One of the interesting friction points will be the open market model vs. selective editorial cherry picking of apps favoured by many Operators.

Open market vs Cherry picking
In an open market model, there is no editorial body deciding the catalogue of applications presented to consumers. A complaint often heard from developers is “Who do they think they are, deciding if my app is good enough?” The customer is presented with unfiltered choice made available by any and all developers. The downside of this approach is the “lost in the noise” issue increasingly voiced by developers, the reduction in quality or increase in copyright-infringing apps and the over reliance on your app appearing in the “recommended” or top 10 listing of the relevant content categories to drive downloads.

Operators favouring the editorial selection model (‘cherry picking’) will argue less is more. Based on an understanding of their user base, operator content managers will work with developers to select the most appealing and appropriate apps. This directly addresses the “lost in the noise” issue as the catalogue will be much smaller vs. an open model app store. This approach should also deliver higher conversion rates if the apps are effectively matched to the needs of the audience. Cynics will argue that the operator content managers are not qualified to make the right selections, and this method heavily favours established brands like Facebook which are “safe” vs. lesser known independent developer offerings, thus stifling innovation.

Now developers need to figure out how to make their apps stand out from the crowd. Giving your app away for free just won’t cut it in the long run, as there is no emotional or financial bond between your app and the user. Pinch Media research shows that the average shelf life of a free iPhone app is less than 30 days, with only 20% of users returning to the app after the first day of installation. You don’t want to be the app equivalent of the shortlived May Fly ?

Key to ensuring your app will appeal to consumers is working directly with your intended audience at an early stage. Why waste time and effort if you don’t have an understanding of the following critical questions:

  • Which features will make a difference to people?
  • What is your addressable market?
  • How much are people prepared to pay you for your trouble, if anything?

This marketing insight gap was highlighted in “Developer Economics 2010”, showing that perhaps the app sector is not as mature as previously presumed. Worryingly the vast majority of developers do not invest in any formal market research or even user testing, outside of friends and colleagues.

Recognising that many development companies may not have specialised marketing people or the resources to conduct formal research, the operator can help fill this gap by opening up access to their customer base to encourage co-creation and testing with real end users, free of charge.

This model of match making developers with end users was championed in the UK in early 2009 when we launched O2 Litmus. This fresh approach quickly gained recognition for its innovative model. To date over 7,600 O2 UK customers have volunteered to participate in the development and testing of applications with developers. Typically engagement levels run at around 10% of the tester base actively working with developers at any one time. Approaching 100 individual apps have benefitted from customer co-creation in O2 Litmus, generating over 2,500 test installations to date.

Programming the network
I have previously written about the potential for Operator delivered network enablers (API’s). Developer Economics 2010 highlights the challenge that faces the operator community in effectively evangelising this message. Only 5% of respondents felt that it was the role of the Operator to expose network API’s.

The pace of technological innovation is not being matched by business model innovation. Increasingly developers feel constrained by the business models on offer. Pay per download dominates (two thirds of respondents), with subscription and advertising following.

This signals another significant opportunity for Operators, and an important angle to the exposure of operator network enablers. It is easy to limit the conversation around enablers to the technical feature set of each enabler. The untapped opportunity for both developers and operators alike is wrapping the exposure of enablers with new innovative business models, such as revenue share on the transactional traffic generated

If developers can plug in additional revenue streams from the usage of operator enablers, this will address both the lack of commercial monetisation options available to developers, whilst introducing richer functionality to their app experience.  If executed correctly I believe this can effectively address the developer perception issues highlighted in the report.

I will close the post with a developer quote from Developer Economics 2010 that perfectly sums up both the opportunity and challenge facing mobile Operators today:

“The first mobile company to TRULY reach out to web developers will have an edge over the competition, but right now I don’t see any candidates, except for Google. If Google became an operator our problems would be solved”

– James
Head of Telefonica Developer Communities
You should follow James on twitter at @jamesparton

[James is a Chartered Marketer specialised in Mobile. With an award winning track record of product delivery including twenty five major launches, featuring twenty first to market achievements, including MMS, mobile video, mobile music downloads, the UK DVB-H Broadcast TV trial in 2005, and the ticketing and interactive services supporting The O2 Arena in London. Recognised by Revolution Magazine as one of the “Future 50”, James is a regular industry speaker, panellist, judge, blogger, and has lectured in Marketing and New Product Development at The University of Oxford Faculty of Continuing Education and Reading University.]

Full report is available for free download, thanks to the kind sponsorship of Telefonica Developer Communities. You can follow Telefonica Developer Communities through their blog.

Are you a mobile app developer? Want to be part of VisionMobile’s next developer research and voice your own opinions? Take a moment to fill out the registration form.

Mobile Developer Economics: The Building Blocks of Mobile Applications

[In part 3 of the 4-part series on our latest research РMobile Developer Economics 2010 and Beyond Рguest author Tor Bj̦rn Minde takes a critical look at the developer sentiments on code development, debugging and support. Full research report available for free download or see part 1 and part 2 of the blog series on mobile developer economics].
The article is also available in Chinese.

Do iOS and Android enjoy a large market penetration? VisionMobile’s research suggests that developers think so even if it is not case for iOS and Android per se; iOS and Android are available in a fraction of devices compared to Symbian and Java ME. Most probably, developers view addressable market in terms of ability to reach a large audience of ‘application consumers’ rather than just a large installed base of handsets.

Developers also consider “quick to code and prototype” as a favourite platform aspect, second only in importance to making money on the platform. This reveals that the ‘fun’ aspect of mobile development co-exists with the realism of money-making in developers’ minds.

The new report Mobile Developer Economics 2010 and Beyond, contains many new insights into mobile development. In this article, I ‘ll  comment on and highlight key take-aways from chapter 3 of the report titled “the building blocks of mobile applications”.

Perceived market penetration should be interpreted as real app usage penetration
There seems to be a contradiction in terms regarding the platform aspect considered ‘best’ by developers. Developers flock onto iOS and Android due to a “perceived” large market share but still there’s a discrepancy between the installed base of the platforms and the number of available apps for each platform. The platforms that have greatest installed base (j2ME, Symbian) have the fewest applications and vice versa.

So, is there (only) a perceived market penetration by the different platforms or are there facts that support the choice?

Looking at some related data points from an Ovum report,  iPhone has 69% of all downloads while Symbian has 9% of all downloads. The report further says that 57% of all downloads in 2009 originated from North America, indicating a high usage pattern among  iOS/Android device users. Users of iPhones and Android devices are more likely to download applications.

Piecing together some more data points on  iOS and Android, specifically app stores’ ease of use, application discovery and the multi-touch experience, reveals an important point; for application developers the addressable market that matters is not just the installed base. While iOS and Android have limited deployments compared to the incumbent platforms, they are indeed ahead of the curve in terms of download share, usage share and ease of use – which explains the developer perception of large market share for iOS and Android. Hence, perceived market penetration should be interpreted as app usage and download share penetration.

It is still fun to code, but money-making rules
Looking at technical reasons that mobile developers consider important when selecting a platform, what sticks out as the favourite reason is “quick to code and prototype”. Moreover, Android, Mobile Web and Flash Lite seem to have the shortest learning curve while Android enjoys the shortest development time.

Developers still consider fun and coding speed as important even if developer mindshare is turning towards the appeal of monetization and reaching a large audience. The technical reasons for selecting a platform seem to be gradually becoming a less important selection criterion. However, developer responses are blurred by ‘soft values’ which affect the answers to the question “What is important”.

A study we did at Ericsson Labs argues that developers, these pioneers of mobile application development, can roughly be grouped into four categories. The answers to the question “What is most important” will be very different between these groups. One developer group has very strong opinions about open-source, another group are mainly focused on a good return on investment, a third group are attracted by the lowest possible barriers to entry and the last group try to keep one hand in every cookie jar.

Future building blocks of mobile applications
In general, mobile web development within an HTML5 browser or web runtime is promising when it comes to market penetration, ease-of-use and cross platform support. At the same time, the VisionMobile study shows several pain-points with mobile web technologies compared to native applications, namely issues with development environments, device API support and UI creation.

We will probably see both environments (native and web) used by developers in the future, both served by app stores and other discovery mechanisms. One could assume that the web runtime will fare better than previous cross-platform initiatives (J2ME, Flash Lite) since there is a large community developing to the web runtime (as opposed to single companies).

Untapped opportunities in developer support
VisionMobile’s study hints at the market gaps in developer support offerings. Developers are most willing to pay for access to hidden APIs – clearly a monetisation opportunity for platform vendors. Premium access to APIs can be delivered by device vendors as a point of differentiation, but it will run counter to cross-device application support of the platform. To achieve both depth of API reach and breadth of cross-device support, we need standards – which interestingly enough are not so important for developers, as VisionMobile’s study reveals.

Finally, VisionMobile suggests that developers use non-vendor sites and developer communities most often for tech support – examples being  Slashdot, Stackoverflow, Daniweb, anddev.org and the Chinese dev site csdn.net. At the same time, our study at Ericsson Labs also found that the main tool developers use for tech support is still regular search engines across tech support or developer communities.

Concluding remarks
All in all, the new VisionMobile report analyses most areas of interest for those who need to understand the developer experience. The knowledge of the developer experience using these ‘first wave’ platforms (what the report refers to as “the Renaissance period”) for mobile application development and marketing is crucial in order to guide the development of future platforms.

–  Tor Björn
follow me at @ericssonlabs.

Full report is available for free download, thanks to the kind sponsorship of Telefonica Developer Communities. You can follow Telefonica Developer Communities through their blog.

Are you a mobile app developer? Want to participate in the next mobile developer research and voice your own opinions on mobile development? Fill out the registration form & we’ll be in touch.

[Tor Björn is head of Ericsson Labs with 25 years experience in mobile multimedia & applications]

Mobile Developer Economics: Taking Applications to Market

[In part 2 of the 4-part series on our latest research – Mobile Developer Economics 2010 and Beyond – Andreas Constantinou looks at how effectively have app stores have reduced the time-to-market for applications and the five key challenges for mobile developers today in taking apps to market. Full research report available for free download or see part 1 of the blog series on the migration of developer mindshare].
The article is also available in Chinese.


If there’s a single reason for the mass-entrance of developers into the mobile market, it is app stores. We view app stores as direct developer-to-consumer channels, i.e. commercial conduits that streamline the submission, pricing, distribution and retailing of applications to consumers. For a breakdown of key ingredients in the app store recipe, see our Mobile Megatrends 2010 report. App stores have streamlined the route to market for mobile applications, a route that was previously laden with obstacles, such as lack of information, complex submission and certification processes, low revenue shares and regional fragmentation.

Despite the hype, there is sporadic use of app stores outside the Apple and Android platforms. Our survey of 400+ mobile developers found that only four percent of Java respondents used App Stores as their primary channel to market. Windows Phone and mobile web developers find app stores little more relevant, with fewer than 10 percent of such respondents using one as a primary channel for taking applications to market.

This contrasts completely with platforms that have ‘native’ app stores. Over 95 percent of iPhone respondents use the Apple App Store as their primary channel, while the percentage of Android respondents using Android Market is just below 90.

In terms of the incumbent mobile platforms, around 75 percent of Symbian respondents that use app stores, use the Nokia Ovi Store. The significant number (20-25 percent) of Symbian developers who also use iPhone and Android app stores reveals the brain-drain that is taking place towards these newer platforms. This is a particularly critical migration of developer mindshare, considering that the Symbian platform is the hardest to master. Thus, the size of developer investments on Symbian being written off is substantial.

Besides the growth of apps, app stores are the cornerstone of another major transformation that has taken place in the mobile industry: the mass-market use of mobile as the next marketing channel beyond the Internet. We would argue that it was app stores that triggered the influx of apps – not the open source nature of Android, or the consumer sex appeal of the iPhone.

App stores triggered the sheer growth in app numbers and diversity that led to the cliché, “there’s an app for that”. Another cliché, “the screen is the app,” tells the other half of the story. Combined, the app store and touchscreen were the two essential ingredients behind mobile apps as the next mass-market channel beyond the Internet. These two ingredients inspired just about every media and service company to commission companion or revenue-driven apps as extensions to their traditional online channels. In effect, this phenomenon fueled the app economy, even beyond what app store numbers alone suggest.

Speeding up time to market
App stores have revolutionised time to market for applications. To research exactly how radically the time to market for applications has changed since the introduction of app stores, we analysed two parameters:
– the time to shelf, i.e. how long it takes from submitting an application to that application being available for purchase
– the time to payment, i.e. the length of time between an application being sold and the proceeds reaching the developer’s bank account

Our findings show that app stores have reduced the average time-to-shelf by two thirds: from 68 days across traditional channels, to 22 days via an app store. These traditional channels have been suffering from long, proprietary and fragmented processes of application certification, approval, targeting and pricing, all of which need to be established via one-to-one commercial agreements. Moreover, app stores have reduced the time-to-payment by more than half; from 82 days on average in the case of traditional channels, to 36 days on average with app stores.

The bigger picture that emerges is that the developer’s choice of platform impacts the time-to-market for applications, i.e. the length of time from completing an application to getting the first revenues in. The iOS platform is fastest to go to market with, particularly thanks to Apple’s streamlined App Store process, while Java ME and Symbian are the slowest, due to the sluggishness of the traditional routes to market used by these developers (in particular via commissioned apps and own- website downloads).

Challenges with taking applications to market
Application distribution may be going through a renaissance period that began in 2008, with the direct-to-consumer model pioneered by Apple’s App Store. However, taking applications to market is still plagued with numerous teething problems, as is typical with nascent technology. There are four recurring issues reported by developers: app exposure, app submission (and certification), low revenue share and the challenges with app localisation. A fifth challenge (and untapped opportunity) is the efficient, crowd-sourced testing of mobile apps by real users.

Challenge 1. Application exposure
Our survey found the number one issue for mobile developers to be the lack of effective marketing channels to increase application exposure, discovery and therefore customer acquisition. This was an issue mostly for Flash and iPhone developers, followed by Symbian, Android and Java ME developers. Developers reported persistent challenges with getting traffic, customer visibility or in short “being seen”. One developer put it succinctly: “It’s like going to a record store with 200,000 CDs. You’ll only look at the top-10.”

The exposure bottleneck is new in mobile, but an age-old problem in fast moving consumer goods (FMCG). With such large volumes of applications in stock, app stores are taking on the role of huge supermarkets or record stores. As in any FMCG market, app developers have to invest in promoting their products above the noise, because supermarkets won’t.

Our research shows that in 2010, developers are relatively unsophisticated in marketing their applications. More than half of developers surveyed use free demos and a variety of social media, i.e. the ‘de facto’ techniques for application promotion. Other techniques cited were magazines and influencing analysts or journalists, while promotion through tradeshows was also deemed popular among a fifth of respondents. Less than 30 percent of respondents invest in traditional marketing media such as online advertising or professional PR services.

When asked about what type of marketing support they would be willing to pay for, our survey found half of respondents willing to pay for premium app store placement. This willingness varies greatly by platform, however; developers whose platform features a ‘native’ app store (iPhone, Android and to a lesser extent Symbian) are almost twice as likely to pay for premium app store placement, compared with developers whose platforms do not (Java and mobile web) as well as Windows Phone. This finding indicates that direct-to- consumer distribution channels are necessarily crowded and therefore developers will be willing to pay a premium to be able to stand out from the crowd – much like how FMCG brands pay for premium shelf space in supermarkets.

Yet with free applications being the norm, developers have to become more creative with promotion and advertising; free applications make up more than half of the Android Market catalogue and 25 percent of the Apple App Store catalogue, according to different reports by Distimo and AndroLib.

There are two types of solutions emerging to cover the market gap of application promotional services. Firstly, there are app discovery and recommendation startups (e.g. Apppopular, Appolicious, Appsfire, Apprupt, Chorus, Mplayit and Yappler), which help users discover applications based on their past preferences or on explicit recommendations from the user’s social circle. Secondly, there are white label app store providers like Ericsson that are moving to app mall (shop-in-shop) infrastructure. App malls will allow the creation of 1,000s of application mini-stores, each targeted to niche sub-segments, much like Amazon mini-stores.

However, the gap in application marketing services is widening in 2010 due to the rapid growth in application volume, which is outpacing the appearance of app discovery and recommendation solutions. We believe that application marketing and retailing services remain the biggest opportunity in mobile applications today.

Challenge 2. Application submission and certification.
Application submission and certification are two of the top four challenges for mobile developers, according to our survey. Overall, the most important issue related to certification that was raised by nearly 40 percent of respondents is its cost. In some cases, developers report that the certification cost rises to a few hundred dollars per app certification (not per app). Such economics do not work for low-cost apps, but only for mega-application productions. Java developers, for example, report that Java Signed is impractical; developers have to purchase separate certificates based on the certificate authority installed on the handset – and certificates are expensive.

Challenge 3. Dubious long-tail economics
The mobile app economy is nothing short of hyped from the successes that have come into the limelight – the $1m per month brought in by the Tap Tap Revenge social app, or the $125K in monthly ad revenues reported by BackFlip Studios on their Paper Toss app. Yet the economics for long-tail developers – i.e. the per-capita profit for the average developer – remain dubious at best.

At least 25 percent of Symbian, Flash, Windows Phone and Java ME respondents reported low revenue share as one of the key go-to-market challenges. Most app stores are still playing catch-up to Apple in terms of the revenue share they are paying out to the developer. As one developer put it, “There has been a bastardisation of the 70/30 rule which has been mis-marketed by app stores; for example with Ovi Store, where operators often get 50 percent of the retail price, so developers gets 70 percent [of the remainder]”. Unsurprisingly, the revenue share was not a major challenge for iPhone or BlackBerry respondents.

Moreover, less than 25 percent of respondents stated that revenue potential was one of the best factors of their platform; on average revenue potential ranked last among “best aspects” of each platform, showing how mobile software development is still plagued by poor monetisation in 2010.

The dubious long-tail economics are reinforced by our findings on developer revenue expectations. Only five percent of the respondents reported very good revenues, above their expectations, while 24 percent said their revenues were poor. Note that we didn’t poll for absolute revenues, because of the discrepancies across regions, different revenue models and distance of developers from revenue reporting. At the same time, there is a general consensus of optimism; 27 percent of respondents said that their revenues were as projected, while another 36 percent said they should be reaching their revenue targets.

There are two effects at play that make for poor long-tail economics. Firstly, the number of ‘garage developers’ who are creating apps for fun or peer recognition but not money; and secondly, the noise created by the ‘app crowd’ which prompts developers to drop prices in order to rise to the top of their pack.

There are also platform-specific effects: the unpredictability of revenues, in the case of the Apple’s pick-and-choose culture for featured apps; and, the limitations of paid app support for Android, where paid applications are only available to users in 13 countries out of 46 countries where Android Market is available, as of June 2010. Android has also been jokingly called a “download, buy, and return business”, referring to how you can get a refund for any paid Android application without stating a reason within 24 hours of purchase – a policy that allows many users to exploit the system. In addition, the applications that are published on Android market are not curated by Google, resulting in 100s of applications that are low quality or are infringing copyright, thereby making it harder for quality, paid apps to make money. Even in economically healthier ecosystems like Apple’s App Store, a standalone developer can hope to sell in total an average of 1,000-2,000 copies of an application at an average price of $1.99, which is barely justifying the many man- months of effort that it takes to develop a mobile application by today’s standards.

We maintain that the monetisation potential for the long tail of apps won’t be realised until effective policies are put in place to curtail the adoption of free apps – for example by enforcing a minimum $0.01 app price. Psychology experiments have proven time and time again how our perception of value is distorted when the price drops to zero. It is time for app store owners to borrow from cognitive psychology to help boost the long-tail developer economy, rather than compete on number of downloads.

Challenge 4. Localisation.
Another issue highlighted was the lack of localised apps. One developer said characteristically, “There is a big problem for developers in markets with low penetration of English as a second language. Since the platforms are poorly adjusted to localisation, the costs of development grow and thus profitability and attractiveness [drop]. It would be great to see platforms that take action towards easing the challenge of localisation.” The lack of localised apps for non-English markets is exacerbated for Android. A search on AndroLib reveals that out of the approximately 60,000 apps on Android Market, there are only about 1,400 apps localised in Spanish and only 1,800 localised in French, as of early June 2010.

The lack of localised apps on Android presents the number one opportunity for alternative app stores like SlideMe, AndAppStore and Mobihand, i.e. to attract communities of regional app developers, or to facilitate localisation of apps to different languages – in other words, to reach where Android Market doesn’t reach.

Challenge 5: Application planning and testing
Application planning and testing is a core part of taking an application to market. Our research confirms that planning techniques are near-ubiquitous for application developers. Yet, small development firms have limited means today to beta test and peer review their applications with a cross- section of representative users. Given the hundreds of thousands of mobile apps, we believe that efficient (crowd-sourced) testing of apps in a global market of users is considerably under-utilized. This presents an opportunity for the few solution providers in this segment – Mob4Hire and uTest.com, for example – but also for network operators, who can generate a channel for testing applications with end users, and provide an open feedback support system back to developers. Overall though, the need of mobile developers to have their apps tested cost-effectively by real users around the world is very much under-served.

Looking forward to your comments. Later this week, we’ll look at the next chapter in our research on the building blocks of mobile applications. Stay tuned or, better yet, subscribe to the blog.

Full report is available for free download, thanks to the kind sponsorship of Telefonica Developer Communities. You can follow Telefonica Developer Communities through their blog.

Are you a mobile app developer? Want to participate in the next mobile developer research and voice your own opinions on mobile development? Fill out the registration form & we’ll be in touch.

– Andreas
you should follow me on twitter: @andreascon

Mobile Developer Economics 2010: The migration of developer mindshare

[In part 1 of the 4-part series on our latest research – Mobile Developer Economics 2010 and Beyond – Andreas Constantinou looks at the migration of developer mindshare that is taking place in mobile software and the drivers behind that. Full research report available for free download]
The article is also available in Chinese.


Software has played a critical role in transforming the mobile industry since the beginning of the century. Since 2008, mobile software and applications have moved from the sphere of cryptic engineering lingo to part of the essential marketing playbook for mobile industry vendors.

In stock market terms, developer mindshare is one of the hottest “commodities” in the mobile business, one whose “stock price” has ballooned in the last two years. Platform vendors, handset OEMs, network operators, hardware vendors, and infrastructure providers all want to contribute to mobile apps innovation. Mobile players, from hardware vendors and handset OEMs to networks, are now vying to win software developer mindshare, in order to add value on top of their devices and networks. But how is the landscape of mobile developer mindshare looking today?

Our new report Mobile Developer Economics 2010 and Beyond, offers many new insights into mobile developer mindshare, and analysis into every touch point of the developer journey, from platform selection to monetisation. The research is based on a set of benchmarks and a survey across 400+ developers globally, segmented into 8 major platforms: iOS (iPhone), Android, Symbian, BlackBerry, Java ME, Windows Phone, Flash Lite, and mobile web.

In terms of developer mindshare, our research shows that Symbian and Java ME, which dominated the developer mindshare pool until 2008, have been superceded by the Android and iPhone platforms. Despite Symbian remaining in the pole position in terms of smartphone market penetration, ‘out-shipping’ iPhone 4 to 1 and Android many-times to 1, the signs of dissatisfaction with the way the Symbian platform has evolved have long been evident.

Indeed Android stands out as the top platform according to developer experience, with close to 60 percent of developers having recently developed on Android, assuming an equal number of developers with experience on each of eight major platforms. iOS (iPhone) follows closely as the next most popular platform, outranking both Symbian and Java ME, which until 2008 were in pole position.

In the last two years, a mindshare migration has taken place for mobile developers away from the incumbent platforms Symbian, Java ME and Windows Phone, while a substantial number of PC software developers have flocked to iPhone and Android. The large minority (20-25 percent) of Symbian respondents who sell their apps via iPhone and Android app stores reveals the brain-drain that is taking place towards these newer platforms. The vast majority of Java ME respondents have lost faith in the write-once-run-anywhere vision. Moreover, anecdotal developer testimonials suggest that half of Windows Phone MVP developers (valued for their commitment to the platform) carry an iPhone and would think twice before re-investing in Windows Phone. We should also point out the exodus of some influential developers from the Symbian camp, as is the case with the closing of Symbian-Guru.com, one of the leading community sites related to the platform, whose founder moved to adopt Android.

The disparity between devices and applications

One of the most telling clues about the speed of evolution of the new vs old platforms is the great disparity between the device installed base and the number of available apps for each platform. While Windows Phone, Symbian, Java and Flash have many times the market penetration of Android, iPhone and BlackBerry, the number of apps available tells a very different story.

The two platforms that best illustrate the above point are Java ME and iOS (iPhone). Java ME boasts an installed base of a staggering 3 billion, while the actual number of apps is very low by comparison. The iOS platform on the other hand is available in just over 60 million devices (not including iPods/iPads) but its app store contains more than 250K apps at this time, a number that will climb even higher in the foreseeable future.

The disparity is also pronounced in cross-platform runtimes i.e. Java ME and Flash Lite. This flies in the face the traditional common sense, i.e. that cross-platform runtimes are the way forward, when the number of apps available for those platforms are tiny in comparison. The recent Apple vs Adobe rift and the subsequent banning of Flash from all iProducts has only weakened Adobe’s position. In parallel Sun has launched half-hearted attempts at reducing fragmentation, the number one Java ME pain point, while the Oracle take over is only worsening the problem.

Choosing a mobile platform – facts and perceptions

Most developers work on multiple platforms, on average 2.8 platforms per developer, based on our sample of 400 respondents (although note that 60% of respondents had more than 3 years of experience). Moreover, one in five iPhone and Android respondents release apps in both the Apple App Store and Android Market.

The question is: in a market crowded with software platforms, how do developers choose between iOS, Android, Symbian, Java ME, BlackBerry, Flash, Windows Phone, mobile web, WebOS or Samsung Bada? For today’s mobile developer, market penetration and revenue potential are hands down the two most important reasons for selecting a platform.

Large market penetration was chosen by 75 percent of respondents across each of the eight major platforms we surveyed. Revenue potential was the second most important reason, chosen by over half of respondents. In fact, market penetration and revenue potential were more important than any single technical reason for selecting a platform, revealing how mobile developers today are savvy about the economic implications of mobile development.

The preference of marketing over technical reasons signifies a turn in the developer mindset. Developers no longer see programming fun as a sufficient reward in itself, but consider monetisation opportunities as a primary priority. It seems that, mobile developers now have a sense of commercial pragmatism. As commented by one of our developer respondents, “Technical considerations are irrelevant. The choice of platform is always marketing-driven”.

Looking forward to your comments. Next week, we’ll look at the next chapter in our research on taking apps to market. Stay tuned or ,better yet, subscribe to the blog.

Full report is available for free download, thanks to the kind sponsorship of Telefonica Developer Communities. You can follow Telefonica Developer Communities through their blog.

Are you a mobile app developer? Want to participate in the next mobile developer research and voice your own opinions on mobile development? Fill out the registration form & we’ll be in touch.

– Andreas
you should follow me on twitter: @andreascon

Adobe defends its mobile strategy

[Is Adobe’s mobile strategy doomed? Mark Doherty guest author and Platform Evangelist for Mobile and Devices at Adobe responds to the recent criticism and argues that the best is yet to come]

The Big Picture
Adobe’s vision – to revolutionize how the world engages with ideas and information – is as old as Adobe itself, in fact 28 years ago the company was founded on technologies like PostScript and later PDF that enabled the birth of desktop publishing across platforms.

Today Flash is used for the 70% of online gaming and 75% of video; driving innovation on the web for over a decade. Flash Player’s decade long growth can be attributed to three factors:

  1. Adobe customers such as BBC, Disney, EPIX, NBC, SAP and Morgan Stanley can create the most expressive web and desktop applications using industry leading tools.
  2. The Flash Player enables unparalleled cross platform consistency, distribution and media delivery for consumers on the desktop (and increasingly on mobile)
  3. A huge creative community of designers, developers, illustrators are involved in defining Flash, and hence driving the web forward.

Now, as consumers diversify their access to the web they are demanding the same experiences irrespective of the device.  Content providers and OEMs across industries recognize this trend and are delivering Flash Player and AIR as complimentary web technologies to extend their vertical propositions.  The process of actually delivering this is not trivial, and was made more complex by a failing global economy, but we are on schedule and the customer always wins.

Where we ‘ve been
The success of Flash on mobile phones has been second to only Java in terms of market penetration, but second to none in terms of consistency.  According to Strategy Analytics, Flash has been shipped on over 1.2 Billion devices, making it the most consistent platform available on any device.

Adobe announced in 2008 a new strategy for reseeding the market with a standardised Flash single runtime, creating the Open Screen Project, an alliance of mobile industry partners to help push this new vision.  So why the change of plan?

In the historically closed, or “wild west” that is the mobile ecosystem, web content providers and developers have found it too difficult to reach mobile devices. In practical terms, it was too difficult for the global Flash community to reach consumers, and to do that in a manner consistent with the consumer reach of desktop content.  Japan has been the most successful region because of deep involvement from NTT DoCoMo and Softbank, and by enabling the use of consistent web distribution.

That said, agencies such as Smashing Ideas, ustwo and CELL (sorry to those I’m missing out) have established valuable businesses in this space by building strong partnerships with OEMs.

On the top end of this success scale, Forbes recently announced Yoshikazu Tanaka has become the first Flash Billionaire with the incredibly successful Flash Lite games portal Gree in Japan.  (Gree is a “web service”, not desktop or mobile, and is indicative of what can be achieved using Flash as a purely horizontal technology across devices)

In all, our distribution and scaling plans worked very well for Adobe, but outside Japan the mobile “walled gardens”, and the web on devices today, didn’t work for our customers.  The cost of doing business with multiple carriers in North America and Europe and the lack of web distribution to a common runtime left our customers with few choices. It was time for a new plan.

Open Screen Project
Delivering on the Open Screen Project vision at global scale with 70 partners is a huge task; it was always going to take about two years.  We are very much on schedule with Flash Player 10.1 and AIR, although eager to see it rollout.

However, describing the goals of the Open Screen Project in terms of dates, forecast market share, Apple’s phone or their upcoming tablet, specific chipsets or Nokia hardware is to miss the whole point.  The Open Screen Project is not a “mobile” solution; it’s about the global content ecosystem.

In summary – connecting millions of our developers and designers with consumers via a mix of marketplaces and the open web.

Google and Microsoft are great examples of companies that have competitive technologies and services, but both companies still use Flash today to reach consumers.  Google use Flash for Maps, Finance and youtube, and Microsoft for MSN Video and advertising.  So indeed we have a co-opetition between Silverlight and Flash, or Omniture and Google Analytics, but together our goal is to enable consumers to browse more of the web on Android, Windows Phone and other devices in the future.

Today, over 170 major content providers (including Google) are working with us right now to optimize their HTML and Flash applications for these mobile devices.  In the coming months we’ll begin the long roll out process, updating firmware, enabling Flash Player downloads on OEM marketplaces.  We’re projecting that by 2012, 53% of smartphones will have Flash Player installed.

It’s really exciting to see it coming together and so many big names involved, why not have a peek behind the curtain?

Flex Mobile Framework
To enable the creation of cross-platform applications even simpler Adobe is working on the Flex Mobile Framework. Essentially we have taken all the best elements of the open source Flex 4 framework and optimized it for mobile phones.

Using the framework and components you will be able to create applications that can automatically adapt to orientation and layout correctly on different screens. The most important addition is that the Flex Mobile Framework “understands” different UI paradigms across platforms. For example, the iPhone doesn’t have a hard back button and so the Navigation bar component will present a soft back button on that platform.

In terms of developer workflow we expect that all background logic of applications will run unchanged.  User interfaces and high-bitrate video will need some adjustments for some hardware, though most changes will be basic changes like bigger buttons, higher compression videos and to adapt HTML for mobile browsers.

Over time with the Flex Mobile Framework, our goal is to enable our customers to create their applications within a single code base, applying some tweaks for each platform for things like Lists, Buttons or transitions.  In this sense we can expect to enable the creation of applications and experiences that are mobile centric, and yet cost effective by avoiding fragmented solutions where appropriate.

We are aiming to show the Flex Mobile Framework later in the year, and I’d love to see it supported in Catalyst in the future.

The Year Ahead
Throughout 2010 we will see Flash Player 10.1 on Palm’s WebOS, Android 2.x, with Symbian OS and Windows Phone 7 coming in the future. In addition to that we also have plans to bring Flash Player 10.1 to Blackberry devices, netbooks, tablets and of course the desktop. For less powerful feature phones we’ve got Flash Lite, and all of these platforms will demonstrate Flash living happily with HTML5 where it’s available.

Adobe AIR 2 is also in beta right now, enabling users to create cross-platform applications that live outside the browser on Windows, Mac and Linux computers. AIR is of course mobile ready, and later in the year we’ll be bringing AIR to Android phones, netbooks and tablets. On top of that, you will also be able to repackage your AIR applications for the iPhone with Flash Professional CS5 very soon.

The rollout and scale of Flash Player and AIR distribution over time are now inevitable, and largely committed over a year ago.

There are risks of course; these ecosystems are moving targets just like they have always been.  However, I’m extremely confident that we can build upon our previous successes, learn from our mistakes and innovate faster than any of our competitors.

– Mark Doherty
Platform Evangelist for Mobile and Devices at Adobe