Facebook’s HTML5 Mobile Platform Strategy Has Risks, But It Has No Other Choice

Facebook’s plan to build a rich HTML5 version of its site complete with apps from its biggest third-party developers should be no surprise. We’ve written about this strategy several times here, here with more detail and analysis and here, when the company’s chief technology officer Bret Taylor alluded to the importance of HTML5 in January.

Basically, Facebook has become so large and powerful that its interests no longer really align with those of the two companies managing the two emerging and dominant smartphone platforms — Google and Apple. All three companies want a 30 percent revenue share from their developer ecosystems, whether that’s just to cover platform operating costs, drive value for their core product (hardware, search, advertising, etc.) or become a significant stream of future income. Apple also chose Twitter over Facebook as the social layer for iOS after the relationship between the two companies faltered.

At the same time, developers that once saw the Facebook canvas as rife with opportunity are moving to iOS and Android. However, fragmentation between devices and operating systems has made the creation of mobile apps challenging for them.

So Facebook sees an opportunity through HTML5 to create a way in which a developer can reach all consumers with a single app — provided that it can help solve the distribution, performance and monetization problems that have made the mobile web less attractive compared to native apps.

TechCrunch found additional confirmation of this strategy this week (see right) after the blog received a leaked set of documents outlining the company’s mobile plans. The new details the site uncovered include:

  • Eighty or so third-party developers are working with Facebook to create applications for this platform, including Zynga and The Huffington Post
  • The initial approach is to use mobile Safari on iOS devices
  • Essentially, it works like this: Load the Facebook mobile web site and users will be able to access a drop-down menu for apps. A Facebook wrapper will deliver the user to the app, providing some basic functionality as well as the ability to use Credits.

Facebook responded, stressing that it isn’t building a competitive platform to iOS. “We don’t expect developers to choose between HTML5 and native apps,” the company says. “We expect they will choose both, just as we did. We view HTML5 as a technology, not a platform.”

Yet by lacing this HTML5 version of the site with Credits, Facebook is in effect creating an alternative monetization scheme for mobile developers.

Taking a step back, there are definitely opportunities for Facebook to provide an attractive mobile platform. However, even though the company has long prided itself on being younger and more agile than competitors, this is a case where being too young has its costs. Facebook’s options are limited by the fact that it doesn’t have ownership of lower levels in the technology stack like the OS or hardware. Google laid the groundwork for Android when it bought Andy Rubin’s company in 2005 and Apple was working on the iPhone years before its launch in 2007 — when Facebook had just 50 million users.

That said, here are some of the ways Facebook could offer more to mobile developers, and then some of the ways where it might fall short:


Facebook could finally be a decent distribution solution for the long-tail of mobile apps that don’t have a top 100 ranking: Navigating the iOS store is strangely anachronistic. It’s almost like the human-curated, directory-based approach Yahoo pioneered in the 1990s. Developers at the top of the charts get a disproportionate amount of downloads — sometimes more than 1 million a day at this point — and then the number of installs drops dramatically the farther down the list an app falls.

Because of this winner-take-all effect, developers with capital do anything they can — cross-promotion, spending on burst campaigns on mobile ad networks, paying for a slot on Free App A Day, etc. — just so they can break into the top of the charts. That’s why incentivized installs through offer walls became a widespread practice over the past year until Apple cracked down on them in April. To run a sizable business, developers need to predictably be able to get their products in front of consumers.

A meaningful alternative for distribution has yet to emerge. The Twitter-iOS integration is promising, but the Twitter platform has not proven itself to be decent viral channel for games, the biggest and most lucrative category of mobile apps.

At the same time, Google, the premier search company in the world, hasn’t really fixed Android Market search and because there is no review process, many spammy or cheaply-produced copycat apps can crop up for every bonafide hit.

There are also a number of third-party solutions that have emerged over the past few years like apps from Appsfire, Heyzap, Explor and Apptitude and mobile-social gaming networks like OpenFeint and Scoreloop. Most have not gained widespread traction because these products suffer from the very same discovery problems they are trying to solve. That, and it’s hard for these companies to monetize on iOS because Apple monopolizes in-app payments. (On Android, it’s too early to tell.)

Facebook could make it cheaper and more reliable for mobile developers to acquire users as people share apps with friends. Developers will have an alternative to rolling dice in the dark, hoping and praying that they can crack the top 100 apps so their months of effort won’t be in vain. For better and for worse, social game developers who have refined the art of optimizing viral channels can finally put these skills to use on mobile.

Facebook is probably one of the only entities big enough to drive real traffic to third-party mobile web apps: There are few, if any other companies, in the world who have a sticky enough product and a substantial user base at roughly 700 million users that could compel tens of millions of consumers to try out mobile web apps through them.


Developers burned by the first couple of years on the platform want to diversify: It was a sign of the times yesterday when Crowdstar, one of the biggest developers on the Facebook platform, brought an iOS app to market without a Facebook integration. At this point, most mobile developers should be wary of being too dependent on any single platform — whether it’s iOS, Facebook or Twitter. Many Facebook developers learned this the hard way after becoming complacent with cheap virality from 2007 to 2009, then being stung when the company effectively introduced a 30 percent tax on developers through Credits.

Performance still lags behind native applications: Native apps still run faster and more smoothly. They can access hardware like the phone’s camera, GPS or NFC. Facebook has been working on projects to prove to third-party developers that HTML5 can support high-performance games. Cory Ondrejka and Bruce Rogers, who came to Facebook through the Walletin acquisition last fall, have been building JSGameBench to test how quickly browsers can render moving objects. Still, this is an experiment and HTML5 is far away from offering comparable performance to native apps.

Can Facebook get enough credit cards accounts to compete with Apple’s 225 million? It’s hard to compete with what is probably one of the biggest repositories of credit card information in the world. Apple has 225 million iTunes accounts with credit cards and a seamless payment system iOS device owners are comfortable and familiar with. We don’t have an accurate estimate on the number of credit card accounts Facebook has. However, presuming that half of the company’s users play games and then a single-digit percentage of those actually pay, it’s hard to imagine the company having more than 30 million cards on file — especially considering that Credits won’t even be mandatory for canvas games until two weeks from now on July 1. Both Google’s Android platform and Facebook are coming from behind here.

It could backfire. Developers could use the virality of Facebook’s HTML5 platform just to drive downloads of their native apps: Some developers might make a web app that’s decent enough to hook a consumer, only to tell them to go download the appropriate native app to play more of the game. Then Facebook won’t get their 30 percent revenue share. Presumably, the company might add a clause into their developer policy to prevent this.

Other Questions

Can the 30 percent margin stand? If Apple is asking for the same revenue split, but has an order of magnitude more credit cards accounts, a more frictionless purchasing flow and a better experience for users through native apps, why should developers give up the same share to Facebook?

Like we’ve argued for Google, Facebook might consider dropping its margin for mobile apps to attract developers. Already, Apple has kind of budged on the 30 percent margin for the media industry and intermediaries like Netflix and Amazon by allowing them offer content in their apps that’s sold outside the store.

Let’s hope that as these platforms compete for the mindshare of developers, developers win.