HTML5 and the Rise of Hybrid Apps

Today we announced the general commercial availability of App Cloud, our second major product. You can learn all about it here. This post is the back story for why we built it.

Let’s begin with a few somewhat controversial assertions:

1. Native apps are not a fad. They are just getting started. That is a good thing.
2. HTML5 is fundamentally transforming how apps are created, though not in the way that the zealots predict. That is also a good thing.
3. Apps and HTML5 are the future of the digital universe. That is awesome.
4. Apps are a journey, not a destination, and a life cycle mindset is required.

A Quick Quiz

To explore why these assertions are true, here’s a quick quiz. What do all of the apps below have in common?

The answer is that these are all hybrid apps developed with cross-platform HTML5 wrapped in a native container. They were not built from scratch in platform-specific languages like Objective-C or Java. Pure HTML5 web apps cannot appear in app markets like the iTunes App Store or Google Android Market, but these apps can because they have that native wrapper. This wrapper also gives these apps access to native capabilities like the camera, microphone, contact list, or notification system that are off limits to the browser.

All The Cool Kids are Doing It

Facebook created a 100% native app for the iPhone back in 2007, but did not release an iPad version until October 2011. The iPad version coincided with the re-release of the iPhone version and a new Android version, all of which were based on this new hybrid app approach where the bulk of the app is HTML5.

So why did they go this route? David Fetterman, Mobile Engineering Manager at Facebook, summed it up in his speech at F8 last month.

“All of our developers are good at HTML. Only a few of them are really good at Objective-C and Android. We are able to make our web developers the same as our client-side developers in some respects.”

It is instructive that Facebook, a company with virtually unlimited resources, is strategically shifting the way that they build apps because of a shortage of skilled native developers. If Facebook can’t find enough Objective-C and Java developers, why would any company with smaller resources think it can do so?

Netflix has been on this same path, having made their shift to HTML5 for creating native app UI well over a year ago. They have shipped HTML5-based hybrid apps across many mobile device platforms, smart TVs, gaming devices, and other consumer electronics platforms. They have also been evangelizing this new approach with real conviction, giving speeches and posting detailed documents that describe the theory and implementation of their approach and the problems it solves.

Microsoft is also adopting the hybrid app approach. They recently shipped new versions of their Bing for Mobile app that is built with HTML5 in a native container. They also managed to create intense anxiety among their developer community when they mentioned that Windows 8 will support creation of native apps in HTML5. It’s unclear how this HTML5 goodness (err, badness if you are a nervous XAML ninja) will appear in the Windows Phone environment, but it seems likely that it will.

Follow the Money

A couple of recent acquisitions illustrate the strategic importance of the hybrid app approach. Nothing shows commitment like an open checkbook.

Our friends at Adobe recently bought Nitobi, creators of PhoneGap. Adobe is doing a pivot away from Flash in the mobile browser to refit the company for the new app-centric world. PhoneGap was an early-mover in hybrid apps, allowing web developers to combine their HTML5 code with native containers. Adobe is probably hoping that ownership of PhoneGap will solidify its natural position as dominant tools vendor in the decade ahead.

Adobe didn’t need to do an acquisition to equip itself to build tools for plain vanilla HTML5 websites in the browser. They are fully capable of doing that on their own. But hybrid web apps require that native container piece that connects apps to the operating system capabilities. PhoneGap fills that void and fuses HTML5 to the native app economy. By acquiring Nitobi, Adobe just bought itself some relevance insurance for the new era of digital media, and got a good deal on it.

Facebook’s recent talent acquisition of Strobe is further proof of the importance of this new approach. Strobe was the company formed to build a business around Charles Jolley’s Sproutcore, an open source JavaScript framework for creating touch web apps that could be combined with a native container to make a hybrid app. Before the acquisition, Strobe had started building out commercial cloud services surrounding the free framework.

Now that they are part of Facebook, the fate of the core technology and those cloud services is in limbo. But one thing is crystal clear: Facebook is putting Charles and team to work on its app strategy and that strategy is all about hybrid app experiences.

A Funny Thing Happened on the Way to the App Store

The crazy thing about this new hybrid app approach is that the app economy wasn’t supposed to be this way. Apple’s original vision for apps drew a bright line between web apps and native apps, apparently under the belief that native code was going to yield the best end user experiences and monetization opportunities.

It is important to remember that when the original iPhone launched, there was no iTunes App Store and bookmarked web sites were the only way to extend the device. Also remember that this limited, browser-centric approach widely was dismissed as insufficient and the Apple developer community was extremely vocal in demanding tools for building native apps.

In March of 2008, fourteen months after the original iPhone hit the market, Apple introduced their app SDK and the iTunes App Store. The rest is history.

Given its incredible success and momentum, the native app concept is not going away anytime soon. However, as the native app concept has aged, a few stress fractures are starting to appear.

Unfortunately for everyone, platform-specific native app development has turned out to be relatively expensive. You can see this in the relative pay scales of native app developers who are paid an average of 28% more than web developers according to searches of job postings from technology job site Indeed.com. This is part of the pain that is causing Facebook to get excited about hybrid apps.

 
Chart Note: The bar titles are Indeed.com search syntax, so "HTML -Cocoa" means "mentions HTML but does not mention Cocoa."

Native app developers not only cost more and are harder to find, but they are highly specialized. You can’t take a team of skilled iOS developers rolling off an iPad app project and immediately redeploy them on an upcoming Android project. The skills are platform-specific and the workflow and pacing doesn't look at all like web development.

This is a big problem because smart phone, tablet, and consumer electronics platforms are proliferating quickly. Currently relevant app platforms include iOS, Android, Blackberry, Windows Phone, Nokia QT, Samsung Smart TV, LG Smart TV, Panasonic Viera Connect, and others. Platforms may come and go, but the one platform to rule them all is unlikely to emerge. In mobile, and consumer electronics in general, fragmentation is forever.

Imagine if you had to fund totally separate development teams for IE, Chrome, and Firefox. Crazy, right? Unfortunately, that’s exactly what the current landscape looks like to the digital media execs and CMOs who pay the bills for app creation. They are compelled to reach the largest audience possible, but to do that they have to support many app platforms, not just one. They are staring down a ridiculously expensive backlog of projects spread across a menagerie of platforms, but may only be able to afford to reach a single platform. Something has to give.

The Force is Strong With This One

Many have looked at this situation and said, “Wait. I’ve seen this movie before! The open web will save the day!” They think that native apps are a passing fad, a sort of bad trip flashback to the days of encyclopedias on CD-ROMs, Compuserve, and Microsoft Blackbird. They zealously profess the “The End of Native” and nostalgically hope for a happy browser renaissance where pure HTML5 apps obliterate the native app Death Star.

You can forgive them for believing this. It’s not a bad story. We have seen movies like this before. And HTML5 is awesome. Check out this chart from Indeed.com which shows appearances of HTML5 in technology job listings in the U.S.

 

So clearly, the Force is strong with this HTML5 thing. By definition, HTML5 is the future of the web, and it would be crazy to bet against it. But that doesn’t necessarily mean that native apps must fail in order for HTML5 to succeed. Nor does it mean that HTML5 can or should do everything.

An Inconvenient Stalemate

HTML5 is eloquently described as a pain machine for developers who force it into areas like gaming, where the technology is still immature. And even when it is applied to more modest content consumption apps, HTML5 on its own simply cannot do all the things that native apps can do. Here is my current scorecard.

A somewhat ridiculous Native App versus Open Web debate has been raging across the web for a few years now. A sample of relatively recent perspectives on this are here and here. As I’ve previously written, I think it is false choice because a) consumers are spending equal time in both the browser and native apps and b) mobile web experiences and native apps are best-suited to very different and yet complementary stages of a consumer relationship: mobile web for discovery and awareness and native apps for loyalty and nurture. It’s not either/or. It’s both/and. Peace wins.

It’s also important to remember that regardless of what the world wishes would happen, the platform owners like Apple, Google, Microsoft, Nokia, Samsung, and others are firmly in control. They currently limit what browser-hosted HTML5 web apps can do for both technical reasons (mostly security-related) and for business reasons.

Over time, the technical/security reasons may be addressed by new standards, though it will take years for these changes to grind through the W3C bureaucracy. And then it will take even longer for the new standards to find their way into the browser in your pocket or living room.

Unfortunately, the business reasons restraining HTML5 are structural and purposeful. In today’s world, shareholders require platform owners to cultivate vibrant and profitable native app economies. It’s foolish to expect the incumbents to act against their own self-interest and let their platforms be fully commoditized by the open web. That’s a sucker’s bet. The platform owners are allowing hybrid apps into their ecosystems because they can still control them. That is unlikely to change.

What About Performance?

There is a meme out there in some technical circles that says that apps based on an HTML5 WebView wrapped in a native container are always going to suffer poorer performance than a pure native app. I don’t buy it. The fact that the largest companies in the industry are using the hybrid app approach should be enough to put this to bed. Sure, there are going to be specific scenarios and types of apps where HTML5 is not going to work well (remember the pain machine), but for a very wide variety of content-centric app experiences, well-optimized HTML5, augmented by native APIs, is performing great.

We are the 99%

It’s clear that the industry giants like Facebook, LinkedIn, Microsoft, and Netflix have shifted to the new hybrid app approach to building apps. But these companies are the 1% with massive resources who live at the bleeding edge and can hack their own way to success. What about the 99% of organizations that want and need apps on all kinds of platforms, but have no idea how to get there?


At this point, many of the 99% have dabbled in apps by creating a 1.0 version for a single device type (e.g. iPhone) on a single platform (e.g. iOS). The customers I speak with are wondering how they are going to take the next step. They are feeling pressure to get their apps on many new platforms because that is where consumers’ attention is shifting. Ditto for advertising dollars. Organizations who are serious about their digital strategy need to be there. The question is how.

The hybrid app approach is absolutely part of the solution. It applies the formidable efficiency and agility of web development to the app problem, and is yielding promising results. But there is more to apps than just a pretty face derived from HTML5.

Apps Are a Journey, Not a Destination

One of the additional complicating factors with apps is that many organizations seem to think about them as discrete, experimental, one-off development projects, often outsourced to contractors with specialized skills. They focus on the UI and put relatively little thought into the back-end administration and content optimization. The operational workflow for non-technical business users and content producers is ill-conceived. They fail to plan ahead for analytics and monetization. They do little or no usability testing or even distributed real-world beta testing. Maintenance and release management and end-of-life strategy go unmanaged.


The problem is that this approach is short-sighted and unlikely to bring success. It is high time that we start treating apps as valuable digital properties that deserve careful planning and investment. Successful apps are not destinations, they are journeys through a life cycle that touches many different roles in an organization, not just developers. Even disposable campaign-specific apps need to be actively managed if they are to be effective during their short lives.

Designers and architects of valuable app properties need think about creating branded templates and scaffolding that make it easy to produce new apps quickly. Websites have that - so why would we tolerate less for apps? App operations staff need to optimize back end content sources to improve performance over high latency mobile networks, just as websites have all kinds of data optimization and caching schemes.

App business owners and ad ops pros need to plan for analytics, reporting, and ad targeting and delivery, just like they do for websites. Developers need to make continuous testing part of their process. And whole team needs to establish efficient methods of rolling out new versions, tweaking content presentation, and tuning ad campaigns.

Putting the Web Team Back in Charge

Apps clearly need to enter the mainstream, proactively-managed, realm in order to make them more sustainable and efficient. But you can hardly blame early adopters of apps for taking shortcuts. When every app project is based on a bleeding edge technology on an unfamiliar platform, compromises have to be made. These projects are often outsourced beyond the domain of the traditional web team. The normal rules and processes and accountability often go out the window.

As hybrid apps become the new de facto standard, app ownership is moving back into the realm of the the web team. The designers, information architects, producers, architects, front end developers, back end developers, DBAs, sysadmins, and project managers who build and operate traditional website are squarely back in the picture. All of their skills and processes are supremely relevant in a hybrid app world.

What We’re Doing About It

At Brightcove, we’ve been tracking all of the trends discussed in this post for a few years. And we’ve been doing something about it. We’ve been re-tooling our Video Cloud product to make sure that video can be a first class citizen on all the new platforms and devices, and we’ve been doing it both in HTML5 and native environments including connected TVs. Today we’re announcing the general commercial availability of Brightcove App Cloud, a new content app platform that is designed to support the entire life cycle of content-centric hybrid apps.  It's our second major product and continuation of our mission to publish and distribute the world's professional digital media.


App Cloud combines native containers with HTML5 to make building custom apps a fast and natural process for web developers. It allows non-technical people to visually create apps without writing any code, and modify their apps even after they have been published and without requiring consumers to do an upgrade. Once an app is published, App Cloud continuously manages and mobile-optimizes content feeds and images to accelerate the end user experience. And it also includes built-in real-time analytics and monetization tools. It’s designed to be an end-to-end app platform that puts the spirit of the web in a native app body.

The AMC Mobile app that appeared at the top of this post is running on App Cloud and is available today for iPhones, Android smart phones, and Android tablets. So is the US Department of State - State Reader iPhone app. We hope you like these apps and others on the way.