“You got your chocolate in my peanut butter!” “You got your peanut butter on my chocolate!” The lines, taken from a “vintage” Reese’s Peanut Butter Cup commercial, can teach us a lot, like “Don’t walk down the sidewalk with a jar of peanut butter or a huge chocolate bar” or “Wow, the 80s really were a weird time…” But the main message is that sometimes an object is more than the sum of its parts.
Unlike Reese’s confectionary treat, however, apps that combine Web and native technologies aren’t better for the pairing. Often, they’re worse.
The most recent unfortunate attempt to get Gestalt-y with it is Gmail for iPhone, which was updated to version 2.0 this week. Though this release sports a new interface, allows users to sign into multiple accounts, and fixes many of the issues that plagued the 1.0 version, small errors abound. From The Verge’s review of the app:
While there’s no doubt this app is an improvement over past iterations, things start to fall apart a bit once you compare Gmail for iOS to other mail clients — or Gmail for Android. While the app is much more visually pleasing than older versions, we still can’t shake the feeling that this is a glorified web app, both in style and functionality. Things lag and stutter a bit more than you’d expect in a native app, and text entry just doesn’t feel as smooth as it should.
So while Google improved on its original app, its insistence on using Web technologies instead of supporting native functions creates a frustrating experience. Is it unusable? No. Is it frustrating, especially given Google’s acquisition of Sparrow and its fully-native iPhone application? Absolutely.
Apple doesn’t get a free pass here, either. One would think that the company could embrace its own platform, but its on-device app stores are an amalgamation of Web and native code, just like Gmail’s new version. This helps contribute to the App Store’s lack of responsiveness, weird glitches, and, well, failure to actually work as intended.
There’s something poetic about a service-slash-app built by Apple, offering apps written specifically for Apple devices, eschewing the technologies powering those very same apps and devices.
Facebook used to combine Web and native tech in its iOS apps as well. Where before getting a Facebook notification meant having to slog through a barely usable application, resulting in a mental juggling act every time something rolled in. Do I really want to thank my cousin for wishing me a happy birthday? Ugh, someone tagged me in another photo. Is it worth seeing what it is?
Eventually someone at Facebook recognized this as a problem, and the company has gone fully-native. In a blog post explaining the switch, Facebook said:
So while utilizing web technology has allowed us to support more than 500 million people using Facebook on more than 7000 supported devices, we realized that when it comes to platforms like iOS, people expect a fast, reliable experience and our iOS app was falling short. Now that our mobile services had breadth, we wanted depth. So, we rewrote Facebook for iOS from the ground up (I really did open up Xcode and click “New Project”) with a focus on quality and leveraging the advances that have been made in iOS development.
That quote summarizes one of the main reasons companies use HTML5 and other Web technologies instead of coding specifically for iOS (or any other platform, for that matter): Convenience. HTML5-based apps can ostensibly be run anywhere, promoting the kind of device agnosticism that companies like Facebook and Google have to worry about. “Write once, run everywhere” is one of the main promises of open Web technologies, and, for some purposes, that’s fine.
The reality is that HTML5 apps don’t facilitate an enjoyable user experience – yet. Both Facebook and Google, as well as other companies like Mozilla, Apple, and Microsoft, are working to make Web technologies indistinguishable or superior to native apps. (The irony of Microsoft building one of the most touch-friendly and advanced browsers with IE10 when its IE6 browser couldn’t be any thicker.)
For now, native trumps Web. So rather than shoe-horning Web technologies into apps and trying to force something that isn’t quite ready, why not embrace the platform you’re building for? Trumpeting open technologies and saving engineers from having to write for each platform’s idiosyncrasies would be fine and dandy, if the users didn’t have to pay for the convenience in frustration and bitterness.