HTML5 Isn’t Magic

Ludo Collin is the CEO of EachScape, a drag and drop platform for mobile apps.

Many think HTML5 is the perfect pain reliever to the painful native app development. It sounds like the perfect magical solution: write once; run everywhere. The claim is that HTML5 adapts to the 7,000-plus different phones that 600 manufacturers bring to market, supporting 30-plus different mobile browsers and hundreds of different screen sizes, with little or no effort at a nominal cost. It’s like magic.

The reality is very different. The HTML5 standard itself isn’t finalized, so manufacturers compete to implement in ways that enable them to stand out from the crowd. Mobile content publishers bear the brunt of that burden and increased costs, as no standards mean multiple different implementations must run in parallel.

Mark Zuckerberg made waves when he announced that Facebook lost two years trying HTML5. This confirmed that when you build a core service and need the mobile experience to reflect the quality of your brand, HTML5 is not the answer. You will get more usage, more quality and more polish with a native app, given the current fragmented landscape.

Mobile publishers need magic to overcome that immense level of fragmentation, and they need more resources to make the magic. That’s also why, contrary to common belief, HTML5 ends up being more expensive than native apps in the long run as publishers try to support multiple devices, browsers and configurations.

HTML5 is not necessarily more expensive to build initially. Using the right tools, costs are comparable for building a solid HTML5 site and a native app. However, HTML5 gets more expensive because the ROI varies due to a number of factors that arise in the ongoing management.

First and foremost, many consumers prefer native apps due to the better experience. Native apps look beautiful and function smoothly. But think about it. If you have to choose between an app and a mobile site built in HTML5 on your phone, which one will you choose? Four out of 5 will choose the app, according to Nielsen Smartphone Analytics.

The mobile Web cannot be as polished as a native app because of the number of different devices, each with different screen sizes and unique features. New devices come out each quarter, and many of those devices possess new flavors of browsers, a slightly different size or some other sort of differentiating feature that requires more augmentation for services that have been built. Ultimately, the mobile Web is reliant on the network, which is not always there when we need it.

If users are concentrated on apps, monetization can be a bigger challenge in the HTML5 world. Additionally, in terms of cost and ROI, there is no standard ad platform for monetization.

Despite the challenges of the HTML5 landscape, HTML5 has great potential, and we can use it in multiple places starting with rich media ads. While apps can serve a role in the marketing mix, apps are not substitutes for high-quality rich media ads. For that use, HTML5 is a great candidate. From a technical standpoint, ads have standardized sizes. That means that whatever the device, in most cases, you can define a box of a specific size and play the ad. If you use that common denominator, HTML5 is a perfect candidate. Because of the very nature of media placements, you can effectively serve ads across multiple devices without the need to install anything.

Given the complexity of the landscape, HTML5 might not be the trick brands were seeking for effective cross-platform deployment reach. Do it right by using an environment that will help you not only build but also manage your app. This is why Facebook moved from HTML5 to native; it couldn’t deliver the level of quality it was aiming for, and without an app, it couldn’t overcome fragmentation. Delivering a great experience often drives the ROI, because at the end of the day, cost is relative depending on the return.

Image via Shutterstock 

https://digiday.com/?p=23222

More in Media

News publishers hesitate to commit to investing more into Threads next year despite growing engagement

News publishers are cautious to pour more resources into Threads, as limited available data makes it difficult to determine whether investing more into the platform is worth it.

privacy sandbox

WTF is Google’s Protected Audience?

FLEDGE stands for ‘First Locally-Executed Decision over Groups Experiment’ and makes ad auction decisions in the browser, rather than at ad server level.

Digiday’s History of Ad Tech: In the beginning …

A look at the genesis of ad tech, from the first online display ad in 1994 to the dotcom crash.