Should You Go Hybrid?

Over the past week, since we released the first beta of Icenium, I’ve been talking with lots of web and mobile web developers who are either starting to develop apps for mobile devices, or who are going to be starting soon. These folks, who are new to building apps that run on devices, have lots of questions about the options available to them, and lots of confusion over native-vs-mobile web-vs-hybrid.

For the purposes of this conversation, I’ll use the following definitions:

  • Native apps are built for a specific platform with the platform SDK, tools and languages, typically provided by the platform vendor (e.g. xCode/Objective-C for iOS, Eclipse/Java for Android, Visual Studio/C# for Widnows Phone).
  • Mobile Web apps are server-side apps, built with any server-side technology (PHP, Node.js, ASP.NET) that render HTML that has been styled so that it renders well on a device form factor.
  • Hybrid apps, like native apps, run on the device, and are written with web technologies (HTML5, CSS and JavaScript). Hybrid apps run inside a native container, and leverage the device’s browser engine (but not the browser) to render the HTML and process the JavaScript locally. A web-to-native abstraction layer enables access to device capabilities that are not accessible in Mobile Web applications, such as the accelerometer, camera and local storage.

What Should I Choose?

One of the most common concerns for web developers new to the mobile app world is the learning curve required to build native apps, or the lack of education on what a hybrid app is. My advice is, before committing down a single path, consider the user experience and what each option provides you. Native apps will always provide the fastest performance, at the cost of being more complex to code when compared to a hybrid app, while a hybrid app will be easier to build, using HTML5 and JavaScript, at the cost of giving up a little bit of speed. If the user experience you want to create is a Need for Speed style game, chances are you’ll want to use native technology to implement the app for each mobile platform you’re targeting in order to get the best graphics performance. If you want to build the next Foursquare, using geolocation and providing a means for displaying data and updating data, a hybrid app is a perfect solution and enables you to build it once, publish it through app stores, and have it work on several platforms.

Like any other technology choice, deciding between native and hybrid requires you to look at the user experience and decide on the level of investment you need to make to achieve the goal. Native apps will always require more investment because they are written with more complex languages, designs and structures. They also need to be written/rewritten for each mobile platform you are targeting. Hybrid apps will always enable you to build for more platforms faster, if you are willing to sacrifice small amounts of performance (e.g. game-level responsiveness).

What is a Hybrid App?

Hybrid, by definition is anything derived from heterogeneous sources, or composed of elements of different or incongruous kinds. A hybrid app is one that is written with the same technology used for websites and mobile web implementations, and that is hosted or runs inside a native container on a mobile device. It is the marriage of web technology and native execution.

Hybrid apps use a web view control (UIWebView on iOS, WebView on Android and others) to present the HTML and JavaScript files in a full-screen format, using the native browser rendering engine (not the browser itself). WebKit is the browser rendering engine that is used on iOS, Android, Blackberry and others. That means that the HTML and JavaScript used to construct a hybrid app is rendered/processed by the WebKit rendering engine (for you Windows 8 folks, this is what the IE10 engine does for Metro style apps that use WinJS) and displayed to the user in a full-screen web view control, not in a browser. No longer are you constrained to using HTML and JavaScript for only in-browser implementations on mobile devices.

The real secret sauce of hybrid apps is the implementation of an abstraction layer that exposes the device capabilities (read: native APIs) to the hybrid app as a JavaScript API. This is something not possible with Mobile Web implementations because of the security boundary between the browser and the device APIs. Apache Cordova (formerly PhoneGap) is an example of a JavaScript abstraction layer over native APIs (for you Windows 8 folks, WinJS is another example of a JavaScript abstraction layer on top of native APIs). Through this abstraction layer a common set of APIs is exposed in JavaScript, and these JavaScript APIs work on any device supported by the framework (for WinJS that’s only Windows 8, but for Cordova that is seven mobile platforms including iOS, Android, Blackberry and Windows Phone 7). When the native wrapper is compiled around the HTML, CSS and JavaScript resources, there is an interop layer added that connects the JavaScript APIs with the platform specific APIs.

What this really means is that, for example if I build a mobile app with Apache Cordova, I can use JavaScript to access a native API, like the camera, using a single API call regardless of what platform the app will run on.

navigator.camera.getPicture (onCameraSuccess, onCameraError, { quality: 50,
    destinationType: Camera.DestinationType.DATA_URL
});

function onCameraSuccess (imageData) {
    var image = document.getElementById('myImage');
    image.src = "data:image/jpeg;base64," + imageData;
}

function onCameraError (message) {
    alert('Failed because: ' + message);
}

Under the covers the JavaScript is making an interop call that access the native API for the camera. That means that on an iOS device this JavaScript is calling into the native layer to instantiate a  UIImagePickerController and on Android it creates an Intent to use MediaStore.ACTION_IMAGE_CAPTURE to take a picture. When developing a hybrid app you don’t need to worry about this level of detail. All you need to do is call the JavaScript function (navigator.camera.getPicture() in this case), and respond to the outcome (the imageData passed to the onCameraSuccess call back function in this case).

Summary

Hybrid apps are a great option for you if you:

  1. Want to target multiple mobile platforms
  2. Want to take advantage of device capabilities like geolocation, accelerometer or the camera
  3. Want the app to be useable when the device is offline
  4. Don’t need the advanced graphics performance that you can only get from a native app.

Hybrid apps are built with web technologies which means there are millions of web developers who already have the base skill set to build mobile apps.

Here is a graph that highlights the differences in native, hybrid and mobile web applications.

We Need Developer Tools, Not Platform Development Tools

It’s been almost a year since I left my role at Microsoft as Director of Product Management for Visual Studio. Ever since I left, I’ve had lots of people asking what I am working on now, and I’ve been pretty quiet about it (the running joke is that I am the VP of Black Ops). The truth is that my team and I have been very busy solving what we believe to be one of the biggest challenges facing developers today and building a new product that I believe will dramatically reduce the barrier to entry for developers wanting to build applications that run natively on mobile devices.

I firmly believe that mobile devices are the single biggest opportunity today for developers. Cell phones are ubiquitous, and smartphones are becoming so common place, it’s surprising when someone doesn’t have one. According to the March 2012 U.S. Mobile Subscriber Market Share from comScore 234 million Americans age 13 and older used mobile devices, and more than 106 million people in the U.S. owned smartphones. That’s roughly one-third of the US population, and if you are anything like me, your smartphone is the only computing device you have with you at all times, from the time you wake up, to the time you go to bed. While a smartphone (or tablet) may not be your primary productivity device, it is arguably your primary device –the only one you always have within reach.

From a developer’s perspective, this represents a huge opportunity. While lots of developers have already entered the mobile device development arena, only a fraction of the entire developer population is actively doing development for mobile platforms. As businesses embrace mobile devices and start to extend their line-of-business applications, business-to-business applications and direct to consumer applications, more and more developers will have to transition into mobile platform developers.

While mobile platforms are one of the biggest opportunities for developers, they are also one of the biggest challenges for developers. Like the browser-wars of the 90’s, the mobile platform arena is hugely challenging. Every mobile platform provider has their own SDKs, uses a different programming language, and different tools. In fact, if you want to target all of the mobile platforms out there, you need multiple development machines—one for Mac OS X and one for Windows (at the very least you need a Mac and a BootCamp image of Windows). To build one app that runs natively on all platforms requires significant duplication of effort—essentially building and rebuilding the same app on different platforms. None of the platform providers are eager to solve this problem for you—they don’t make developer tools, they make platform development tools.

When I was at Microsoft, my job was to ensure Microsoft built the best platform development tools possible As a result we created awesome tools for development on the various Windows platforms (client, server and phone). What we didn’t do was build great developer tools—tools that made developing applications easier and more enjoyable regardless of what platform was being targeted. The only way to do that in the Developer Division would be to secede from Microsoft and become an independent software vendor (ISV)…and DevDiv would be a big one. Since that wasn’t going to happen I decided that it was time to find an ISV that had the ability to create great development tools regardless of platform. That quest led me to Telerik, where my team and I have been doing just that.

I’d like to invite you to join the Icenium private beta. Icenium is a work in progress (hence the private beta) and steadily becoming the product that I envisioned—a development tool that makes building applications easier and more enjoyable regardless of platform. With Icenium, we intent to build the worlds first Integrated Cloud Environment (ICE) that combines the power and flexibility of the cloud with the convenience of a local coding environment to massively eliminate the complexity of building cross-platform mobile applications. In its current beta state Icenium enables you to build applications for Apple iOS and Google Android, and more platforms will follow. My team and I are very excited about this beta, and we are looking forward to getting your feedback.

D7

There are Only Two Kinds of Device Apps

Just the other day a colleague and I were having an interesting discussion. After a while we realized we were talking about the same things but we each used different vocabulary to describe the things we were referring to. I hate when that happens.

I thought it would be useful to provide a common definition for the types of device (aka mobile) apps we see in the market to help establish a common vocabulary.

As I see it, device applications can be categorized as being either consumer applications or business applications (my colleague likes the term “corporate applications”). These are then also sub-divided, but I’ll get to that soon.

Consumer Applications

IMG_0057Consumer applications are exactly what the name implies – applications used by consumers. These are typically purchased through an app store or market place by the consumer directly. I tend to sub-divide these into five types: data snacking, social/mash-up, content/media, casual games and graphical games.

The key attribute here is that these are acquired directly by the user for a specific non-business purpose. Facebook, Angry Birds, etc. are examples of these types. There is some easy confusion here when we start to think about business (or “corporate”) applications, specifically those intended to connect the user to the business. Is Facebook a B2C app? Not really. It is the product of a company, but primarily a consumer app.

Business Applications

Business applications are built for only a couple reasons – B2C or internal line-of-business (LOB), and it can be easy to blur the line (or at least see the line with blurry vision) if you’re not careful. Some may argue that B2B is another type, but my position is that there is no such thing as a B2B device applications. They are B2C applications where the “C” is simply a user from a client “B”.

B2C

Business to Consumer (B2C) apps are the apps most easily confused with “direct” consumer apps. Is Facebook a consumer app or a B2C app? I think I could argue this one successfully in either direction, but I prefer to think of it as a consumer app (Facebook’s primary business is Facebook, even though IMG_0058their revenue comes from sources other than the user). For B2C I like to think about the company’s primary business. Is the app their primary business, or are they in the business of something else, and the app helps them provide a better experience for their customer?

Alaska Airlines is a company I do a lot of business with. They have a great B2C app. As the consumer, I got the app from the Apple AppStore, even though it’s not a consumer app (see, I told you it could get blurry). This app is a great example of a company that is primarily in a different business (moving people and stuff through the air),who has a great app for their customers. I can use the app to check my upcoming trips, check in for flights, and—for those of you who aspire to be truly paperless—even use it as my boarding pass.

My colleague likes to refer to these B2C apps as “Corporate Consumer Apps.”

LOB Apps

Line-of-Business apps are built by companies (or vendors) for use within the confines of their business. Examples include expense tracking apps, conference room schedulers, and lunchroom debit apps (at Microsoft we even had a game app that the food services division put out enabling you to win a discount on lunch using your Windows Phone). Typically these are developed in house for a specific need, and distributed through some form of internal or enterprise app store.

These are what my colleague refers to as “Corporate Enterprise Apps.”

What Do You Think?

Do you agree with me? When thinking about the different app types for mobile devices, do we agree on the following terms:

  • Consumer apps
    • Data Snacking
    • Social/Mash-up
    • Content/Media
    • Casual Games
    • Graphical Games
  • Business Apps
    • Business to Consumer (B2C)
    • Line-of-Business (LOB)

D7