I am discussing mobile application development with the IT manager of a provider of online content and services to millions of users, when the conversation touches on HTML5. He tells me:

“On September 11, 2012, Mack Zuckerberg stated that the biggest mistake made by Facebook was betting too much on HTML5 as opposed to native. The very next day I got a call from my boss asking me if I was sure our company was not making the same mistake.”

Since that day, I've heard similar stories over and over again as the “Facebook dumps HTML5” headline spread through the web and reached even a non-technical audience. Many IT directors and software architects that had been pushing HTML5 as the future of mobile within their organization began to see their strategy questioned by upper management.

“We provide customers with native applications for iPhone, iPad, and Android to access our online content and services. Each application was launched at a different time and outsourced to a different supplier. Eventually the apps became misaligned to the point that managing updates and adding new features has become a painful process. HTML5 looked like the ideal solution to overcome that, but now I am no longer sure.”

Indeed, HTML5 was hyped as the ultimate write-once-run-anywhere solution for mobile, solving all the problems of cross platform development and device fragmentation. This has been proven to be plainly wrong. Not surprisingly, the old saying “no silver bullet” also applies to mobile applications. On the other hand, HTML5 remains a powerful technology for mobile development, a fact that is demonstrated by well-crafted executions like the LinkedIn app. When it comes to choosing HTML5 over native or vice versa there is, of course, no universal answer. There are, however, key decision criteria.

Let's Take A Step Back 

The first question to ask is, do you actually need a mobile application? No matter the selected technology platform, development and maintenance of a mobile application can be costly, and a mobile website might be preferable. By leveraging responsive design techniques, the browser can be instructed on how to best render the web page content depending on device display and input capabilities, such screen size and orientation, as well as touch-based interactions (a well-known example is the Boston Globe website.)

From the user perspective, this solution provides a traditional client-server web experience, with page-to-page navigation implying page reloads and redraws (completed in a possibly short but unavoidably noticeable time.) Also on the downside, network connectivity is always required (no offline modality), no device features are available, and discovery and monetization cannot happen in the native platform application store.

The browser is also an app.

From Web to Native: The Steps In Between 

After a business case for a mobile app has been established, the question arises as to which platform to support. Unless the app is targeting a niche vertical or geographical market, chances are that it should support multiple platforms, namely iOS and Android (and its fragmented device base) to say the least. Viable approaches span web and pure native technology, with various intermediate degrees—single page applications, hybrid applications, cross-compiling frameworks and multiple native apps.

A web app is implemented with modern web technologies and unlike a mobile site it is constructed as a single, self-modifying web page (such as Google Gmail), with application and presentation logic moved to client-side. HTML5, CSS3, and JavaScript provide plenty of opportunities to deliver advanced user interfaces that convey the feeling of an application. Bleeding-edge browser APIs, such as user media, geo-localization and local storage (on their way to standardization), can be leveraged, depending on the level of support by the mobile browser. A single page application can be typically added to the device home screen as web app, which is essentially a bookmark that launches the browser. Updates are transparent to the user, as they happen server-side. A notable example of this approach is the Financial Times app (seen at the top of this post), which leverages the distribution in the open web as opposed to proprietary application stores.

The hybrid approach is based on software frameworks that package HTML5, CSS3 and JavaScript code into a container that embeds a webview (leveraging the native HTML rendering engine) and an integration layer to the mobile operating system. The webview is used to display a single page application. Thusly wrapped, the application is seen by the mobile operating system as truly native. Discovery, purchase, installation and updates happen via the application store. A popular framework of this kind is Adobe Phonegap (based on the Apache Cordova project), which powers the Wikipedia mobile app. Its integration layer enables JavaScript code to access software and hardware features such as contacts, notifications, local storage, as well as GPS, compass and camera.

The hybrid approach is taken a step further by cross-compiling SDKs such as Appcelerator Titanium, which provide a complete mobile OS abstraction platform, and translate JavaScript source code into actual native code (as opposed to rendering it in a web view). Such cross-compiled applications are not really web applications, as the JavaScript-based API is in fact used to create native UI components, with no HTML and CSS. Even more, other SDKs exist that adopt different languages as source code (e.g. MoSync also allows C and C++).

And finally we have native apps, built on the specific APIs of the target mobile operating system. Unfortunately each platform requires its own development language and tools (e.g. Objective-C on iOS, and Java on Android) and corresponding developers skills. As code reuse across different platforms is not possible, an app has to be developed for each individual system, at the cost of increased effort and harder manageability.

Understanding decision criteria 

When facing choices for multiplatform mobile development you should not decide which is the best technology per se, as there is no general answer to that. Focus instead on understanding the peculiarities of your app and establish a mobile development strategy that satisfies multiple criteria in terms of functionality, business model and context. Which device software and hardware capabilities does your app need to access? What are the non-functional requirements (performance in particular)? How often do you plan to release updates? What is the monetization model (free, ads-supported, one-time-purchase, subscription etc.) and does it require the app to be in the app store? Also consider the context of your organization: what are your mobile development team skills? Are you willing to outsource development in case you cannot manage it internally? Answering those questions (and several more) will lead you to the selection of the most appropriate technology options for your needs.

Native apps maintain the edge as far as functionality and sheer power are concerned. They offer the fastest performance, familiar look and feel, full integration with the platform ecosystem, complete access to device software, and hardware features. Especially when it comes to highly interactive and animated user interfaces, they deliver a more effective user experience. HTML5 apps on the other hand are more limited in terms of functionality but they are a more cost effective approach to multiple platforms. Als,o HTML5 yields higher flexibility when it comes to distribution and monetization. Want to be in the official application store? Then package your app with the hybrid approach. Want to escape the official application store (and its rules and barriers and due royalties) instead? Then go for your own application provision strategy in the open web.

When going for multiplatform solutions bear in mind that while the idea of a common codebase is desirable the “write-once-run-anywhere” paradigm is ultimately an illusion, as your app will still need platform-dependent tweaks, and a broad QA effort. This is a design as well technical matter: each mobile OS comes with its peculiar interaction model (e.g. think of how the “back” action is presented differently in iOS and Android), and your application should be consistent with that in order to meet users’ expectations, unless its brand is so powerful as to allow the superimposition of a completely custom interaction model.

Last but not least, consider the time horizon. Native platforms come and go with turbulences in the mobile device market, whereas HTML (an open, vendor-independent technology) has been there for over 20 years and is here to stay for another long while. HTML5 is now enjoying widespread support on desktop, mobile and smart TV platforms; its specification is expected to reach W3C recommendation level by 2014, yielding even broader stability and interoperability. A new generation of mobile devices will come with increased computational and graphical power: Faster and more compatible mobile browsers will thus reduce the performance gap with native and provide stronger support to HTML5. And strong support will come from the software engineers community too, as HTML5 has enabled a whole generation of web developers to transfer their skills into the mobile world. 

Alex Conconi is a software architect at frog's Milan studio.

[Image]

There are tools, and there are platforms. Tools tend to be simple things. They help you get some particular task done — they lend you their power when you need it — but they otherwise pretty much stay out of your life. They’re like little amplifiers of the self. Platforms are more complicated. They may help you do some of the same things that tools help you do, but, in granting that assistance, they demand that you become entangled in a bigger scheme, a scheme of someone else’s devising. Rarely do you know fully what the scheme consists of, what its ends are, or how it will develop in the future. A tool holds no secrets; a platform holds many. You use a tool; a platform uses you.

RSS is a good tool. It gives you a simple way to shape and filter the web’s content to suit your own needs. It lends you its power when you need it without requiring any broader entanglement. Its developers, to their credit, made its simplicity central. They were acting as tool-makers, which is how software programmers and web developers tended to act a decade ago. That was before the platform-builders arrived, with their schemes.

Google was once a tool-maker. Now, it’s a platform-builder. Like Facebook. Like Apple. Like Microsoft. Like Twitter. Like all the rest. And so Google is officially killing off its popular RSS tool Google Reader. The move was in the cards ever since the creation of the Google+ platform. Tools are threats to platforms because they give their owners ways to bypass platforms. If you have a good set of tools, you don’t need a stinking platform. If you’re happy with RSS, you’re a little less likely to sign up for Google+, or Twitter, or Facebook. At the very least, the tool gives you the choice. It grants you self-determination.

RSS, like other web tools and even other personal-computer tools, is doomed—not doomed, necessarily, to disappear, but doomed to be on the periphery, largely out of sight. “We’re living in a new kind of computing environment,” said Google engineer Urs Hölzle in announcing the “closure” of Google Reader. He’s right. The tool environment is gone. The platform environment is here. Consider yourself entangled.

Photo by Julia Manzerova.

Web site redesigns originate for unique reasons, but fundamentally they fall into two distinct categories: the right and the wrong.

Working early in my career for the joint venture of CNN and Sports Illustrated, cnnsi.com, I was on a team that led several redesigns. Why several? The executive leadership changed frequently, to the point that we could set our watches to the timing of a new redesign starting upon arrival of the next President or Managing Editor. A classic example of redesigning for the wrong reasons -- because some executive needed to put their stamp on the site like a dog marking its front yard.