Going Native

One of the most important debates in mobile app development has been the trajectory of the mobile web compared to native apps. The question has been whether mobile web apps can gain enough support on iOS, Android and other mobile operating systems to provide a good user experience and ultimately compete with proprietary apps.

We have now witnessed the plans of all the major mobile companies, and one thing is clear: We are going native.

In a world where users are demanding more integration and consistency across their apps and services, it was only inevitable that the open nature of the Internet would come under fire. The centralizing power of a Google, Apple, Amazon, Microsoft or Facebook allows these companies to develop experiences that are nearly impossible for a team of developers to emulate using open technologies.

To accommodate the demands of users, platform companies are providing new proprietary layers over the web, not just in burgeoning areas like home automation and health-tech, but even in areas once considered sacrosanct like email.

That leaves developers with a hard choice. They can aim for the center of all of these competing platforms by taking advantage of the mobile web’s interoperability, or they can position their products to fully embrace a native platform (or more than one if the engineering resources exist).

Take email, the coffee of Internet technologies that keeps the world moving. Despite the incredible transformation of the Internet over the past four decades, email has remained more or less the same, seemingly timeless in its simplicity and openness. Its main protocols like SMTP and IMAP were first designed in the 1980s, and although they have been modified over the years, they remain the bedrock behind global communications.

Now, Google has offered something entirely new for developers – an API for Gmail. During an announcement this week coinciding with Google I/O, the owner of the most popular email service on the web announced that it was making public this new API alongside email’s traditional IMAP and POP protocols in order to offer features like more granular access controls, as well as greater speed and efficiency.

The company is clearly responding to the surfeit of startups that are working to make email more productive, but which often hit a wall in terms of what the existing protocols allow them to do. Google is likely the only consumer mail provider in the world with the scale required to get developers to write proprietary code on top of its own email platform (of course, enterprise mail services like Exchange ActiveSync are their own beast).

This sort of change to email is a perfect example of the kind of proprietary makeover happening across the web’s technologies. Unlike a complete teardown, these makeovers assume a certain level of continuation from the past. Core technologies like HTTP and JSON remain key to the functionality of this new, more proprietary world.

Partly for that reason, mobile web would seem to have a chance. Take Google’s announcement yesterday that Android L will split out Chrome tabs into separate tiles within the app switcher. As our own Romain Dillet noted, this approach means that native and mobile web apps can co-exist in harmony, perhaps to the point that a user doesn’t even know the difference between the two. Finally, mobile web apps will be considered equal citizens and can compete fairly.

Even so, the hope for mobile web apps on Android is likely to be short-lived. Ironically, Google announced this mingling of native and web apps during the same keynote in which it showed off its “material design” approach to Android, its next-generation set of libraries and guidelines for building beautiful apps on all form-factors for the operating system. Users may not know a native app from the task switcher anymore, but they certainly will from the user interface itself.

After all the keynotes this year, it is clear that we are not converging on one set of protocols, or one look-and-feel for mobile apps, but instead multiple interpretations of the same products. While deep fragmentation would probably have been good for the mobile web (if no platform is dominant, interoperability is a must), we are instead witnessing a concentrated fragmentation behind a handful of platforms, decreasing the incentives for companies to build interoperability. That forces developers to choose to go native and compete on a platform, or hope for the best by targeting the center.

In this context, I am increasingly reminded of Swing, Java’s attempt to create a user interface library that could translate design elements across platforms and live up to Java’s goal of “write once, run anywhere.” Despite Sun’s best intentions, the pluggable look and feel that Swing offered never felt native on any platform, one reason among many for Java’s lack of success among consumer desktop users.

It isn’t just user interfaces that are getting more fragmented, but also the integration of products as well. Apple’s Swift language and cloud sync services will allow developers to create a seamless experience across its desktop and mobile devices, but only for those who play entirely within its walls. Amazon’s Fire OS is a mostly incompatible derivative of Android that happens to offer free unlimited cloud storage for photos. Now, Google is creating the APIs needed to integrate your life across wearables, televisions, and automobiles.

For an example of what going native means for a developer, take Facebook’s recent post about making its app and pages load faster on data-limited Android feature phones. The company moved its networking stack to SPDY, which optimizes HTTP requests for faster processing and loading. Perhaps most notably, the company moved from downloading images in the web’s classic JPEG and PNG file formats to Google’s open-source WebP format, which Facebook feels is well-supported on Android. And using particular features of the Google Play store, it now offers multiple versions of its app custom-tailored to delete unusable features and thus save on application file size.

These moves toward proprietary technologies also remind me a bit of the browser wars of the 1990s, in which Microsoft’s Internet Explorer continually added new, incompatible features demanded by developers but weren’t standardized across the community. Unlike Microsoft though, no mobile operating system currently has a monopoly on the market. This time, developers have to actually place their bets on different platforms and live with the consequences. You can’t just write for IE and ignore that last smidgen of the browser market.

For the sake of the open web, I think the key question here is whether some organizing force will move these proprietary layers back into the open. Can a company like Dropbox or Box move the cloud services business to a more interoperable system? Will companies in the home automation space like General Electric or Philips work together to develop common standards, since they would likely be the biggest beneficiaries? Will medical technology companies work with Apple and Google to develop non-proprietary APIs on behalf of patients? Finally, can startups come in here and offer interface layers to make cross-platform development easier?

Because going native might create a more delightful experience for users, but at a heavy cost to the open foundations of the Internet.