A few short years ago, most mobile devices were, for want of a better word, “dumb.” Sure, there were some early smartphones, but they were either entirely email focused or lacked sophisticated touch screens that could be used without a stylus. Even fewer shipped with a decent mobile browser capable of displaying anything more than simple text, links, and maybe an image. This meant if you had one of these devices, you were either a businessperson addicted to email or an alpha geek hoping that this would be the year of the smartphone. Then Apple changed everything with the release of the iPhone, and our expectations for mobile experiences were completely reset.
The original plan for third-party iPhone apps was to use open Web technology. Apple even released tooling for this in its Dashcode project.4 Fast-forward three years and native apps are all the rage, and—usually for performance reasons—the mobile Web is being unfavorably compared.
There are two problems with this line of thinking. First, building a different app for each platform is very expensive if written in each native language. An indie game developer or startup may be able to support just one device, likely the iPhone, but an IT department will have to support the devices that its users have that may not always be the latest and greatest. Second, the performance argument that native apps are faster may apply to 3D games or image-processing apps, but there is a negligible or unnoticeable performance penalty in a well-built business application using Web technology.
For its part, Google is betting on Web technology to solve the platform fragmentation. Vic Gundotra, VP of engineering at Google, claimed that “even Google was not rich enough to support all of the different mobile platforms from Apple’s App Store to those of the BlackBerry, Windows Mobile, Android, and the many variations of the Nokia platform,”6 and this was before HP webOS, MeeGo, and other platforms emerged.
In this article we discuss some of the strengths and weaknesses of both Web and native approaches, with special attention to areas where the gap is closing between Web technologies and their native counterparts.
Native Code vs. Web Code
Implementing a software app begins with code. In the case of native code, most often these days the developer typically writes in a C dialect, as in the case of the iPhone. In our work at Nitobi (http://nitobi.com/) and on PhoneGap (http://www.phonegap.com/), we have had plenty of experience wrestling with the various mobile platforms from a native development perspective.
Of course, for various market or organizational reasons most developers or teams must support apps on multiple smart platforms. Want to write an app in native code and hit every single mobile operating system? No problem if your team has the skill sets shown in the accompanying table.
What makes things even more complicated are the differences among the actual platform SDKs (software development kits). There are different tools, build systems, APIs, and devices with different capabilities for each platform. In fact, the only thing these operating systems have in common is that they all ship with a mobile browser that is accessible programmatically from the native code.
User Interface Code
Things aren’t as pretty when it comes to the user interface. Most native platforms have wonderful abstractions for common user-interface controls and experiences. No two platforms have the same, or even similar, user-interface paradigms, let alone APIs to instantiate and access them. The Web platform is consistent, for the most part, but the number of built-in or SDK-included controls is limited. You have to roll your own. Sometimes the differences among browsers can cause pain, but—at least in the modern smart-phone world—most devices sport the very capable WebKit rendering engine, and only small differences prevail.
Unfortunately for the Web, those small differences are becoming a big deal. For example, on iOS, the CSS position property does not properly support a value of “fixed.” (This was a problem in Android, but has been corrected in the latest Android 2.2 code.) BlackBerry operating systems earlier than version 6.0 sport a completely arcane browser for which there has been much suffering and toil at unfathomable cost to Web developer sanity. Fortunately, RIM has addressed a lot of this in 6.0, and in general, things are getting better.
Some operating systems include something called hardware acceleration. The iOS stack famously supports this concept in CSS transforms, which is how some Web frameworks achieve silky smooth transitions between view states. It’s a technique first uncovered in Dashcode. It was painstakingly reverse engineered by David Kaneda, pioneered in jQTouch (http://jqtouch.com/), and released later in Sencha Touch (http://www.sencha.com/). Both are incredible Web projects and examples of what can be done when developers push the boundaries.
When we first started tapping into these next-generation mobile browsers, no framework worked properly across devices. Today there are more than 20 mobile frameworks, and support is being rapidly added to existing DOM (Document Object Model) libraries—not the least of which is John Resig’s jQuery (http://jquery.com/) and jQuery Mobile (http://jquerymobile.com/); that code is improving and adding support for more devices every day. With tools like these, it’s getting easier and easier to support multiple targets from a single Web-oriented code base.
Rapid execution and beautiful user interfaces aren’t the whole story when contrasting the Web technology stack to native code. Web technology lives in a sandbox, which is also a jail from lower-level APIs that native code can access—APIs that can access device storage, sensors, and data. But this gap is being bridged, too. Most mobile browsers support geolocation today, for example, and iOS recently added Accelerometer and a slew of other HTML5 APIs. Given that the W3C has a Device API Working Group (http://www.w3.org/2009/dap/), it’s likely we will be seeing many more APIs reach the browser in the near future. If the near future isn’t soon enough, you can use PhoneGap (http://docs.phonegap.com/) to access these APIs today.
Of course, the Web technology stack (HTML/CSS/JS) is itself implemented in native code. The distance between the native layer and the browser is just one compile away. In other words, if you want to add a native capability to a browser, then you can either bridge it or recompile the browser to achieve that capability. If a browser does not support a native capability, it’s not because it can’t or that it won’t; it just means it hasn’t been done yet.
User Experience: Context vs. Implementation
Another area that has a big effect on both native and Web mobile application development is user experience, the term we use for the overall experience a user has with a software application. User experience can even extend outside the app. For example, we can use push notifications to wake up an application under certain conditions, such as a location change, or to spawn a new purpose-built application to handle different application aspects. Obviously, a successful user experience is crucial for successful application adoption.
Generally speaking, a mobile software project user experience can be divided into two primary categories:
- The context—elements that must be understood but cannot be changed or controlled. These include hardware affordances, platform capabilities and UI conventions, and the environment in which your application is used.
- The implementation—elements that can be controlled in an application, such as performance, design, and integration with platform features such as accelerometer data or notifications.
The context in which your application will be used affects users’ expectations. The context for a single application may be radically different from one user to the next, even on a single platform. We’re not really talking about a context; we’re actually talking about multiple contexts. Let’s look at the things that define the contexts to which a successful mobile application must adapt.
Hardware. The Android device ecosystem (Figure 2) is a fantastic example of this variety of contexts, with devices varying significantly in terms of display (physical size, color depth, screen resolution, pixel density, aspect ratio); input (trackball, touchscreen, physical keyboard, microphone, camera); and capability (processing power, storage, antennae, and so on.).
The combination of these properties greatly impacts how your application will appear, and the range of possible ways the user might choose to interact with it. If a particular combination doesn’t exist today, it very well could tomorrow. A successful application must account for the habits associated with all of these hardware devices.
Platform conventions. Each platform has its own user-interface conventions, typically described in a human interface guideline doc and evidenced in the operating-system interface. The variety of mobile Web browsers provides a prime example of how different these conventions can be:
A common user expectation is the ability to “go back” in the browser. iOS satisfies this with a virtual button; Android and BlackBerry devices rely on a physical hardware back button; webOS uses a back button and a back gesture. Whatever the method, users expect that they will be able to “go back” in your application.
Users also expect context menus. In the default Android and BlackBerry browser, the context menu is accessed through a physical button found at the bottom of the screen, close to the natural position of the thumbs. On iOS and webOS the context menu is accessed through a persistent virtual tab bar positioned close to the thumb at the bottom of the screen. The persistent tab bar at the bottom of the screen on devices other than iOS and webOs often produces a poor experience because users can easily accidentally hit their context menu or back buttons, causing an app to close unexpectedly. These are limitations with which both native and Web apps must contend.
Developers must consider approaches that make good sense for both data and users. HTML5 does support the concept of a menu element so a common abstraction is possible here, but the work has yet to be done.
Environment is the greatest wild card of all! Is it daytime or nighttime?
Is the user standing or sitting? Standing still or in motion? One or two hands free? In a busy place? The variables are endless.
Where does that leave us? Expectations borne out of the context are not inherently cross platform. Both native and Web implementations must provide designs and code that support these expectations. The good news for Web developers is that they can fall back on a familiar paradigm in the Web technology stack to satisfy user expectations.
Implementation. To produce the best possible user experience, implementations must deliver designs and code that support expectations set out by a user’s particular context.
Performance: The Hobgoblin of Software Development
Without a doubt, performance is a cornerstone of a great user experience. Like security, it is the most misunderstood and oft-used scapegoat of the software developer. It’s not uncommon to hear developers reject ideas with a flippant, “We can’t do that, it will negatively impact performance.” Rarely quantified and frequently cited, performance is the hobgoblin of software development. How do we quantify performance? Latency is a form of performance. Execution, the time an operation takes to perform, is another. We’ll address these separately.
Latency is a huge consideration in the mobile world. Be it a native or a Web application, there is a performance penalty to downloading an app and the data it consumes or publishes through the network. Obviously, the smaller the payload, the faster the app.
Another latency issue can be the initialization of code. Once we actually get the code into memory, it still needs to be parsed. There can be a noticeable performance penalty in this process. We can fake it and enhance the perception of performance with determinate or indeterminate progress indicators.
That said, the benefit of less code doesn’t matter to the end user, who expects a responsive interface. The developer tradeoff is a larger code base—often vastly larger, considering support for multiple native platforms. In the world of native code, the main challenge is reimplementing to multiple targets. In the world of the Web, the main challenge is limiting your footprint as much as possible to produce a responsive user experience. That’s not to say that one user interface can suffice in all environments, rather that the majority of the application logic is in one code base and then specific device-specific UI idioms can be implemented with conditional code. You therefore might want to implement slightly different functionality and user experiences appropriate to the expectations of the users of a particular device. For example, Android and BlackBerry devices have physical back and menu buttons, whereas an iOS device does not.
Another key point to remember is that even though the mobile industry is quickly converging on WebKit as the de facto standard for HTML rendering engines, every device and operating system has a slightly different flavor of WebKit. This means you should expect development to be similar to cross-browser Web development today. Thankfully, there are many libraries such as jQuery Mobile, Sencha Touch, and SproutCore that seek to address this.
All of this discussion of latency and execution of code means taking a tough look at the business goals of your application development initiative. Favoring data over decor is the most pragmatic approach. Gradients, drop shadows, bevels, embossing, highlights, rounded corners, and Perlin noise do not make an application useful or usable—they don’t fulfill a business requirement—but they do impact performance. CSS gradients, in particular, are real devils for performance in the mobile world. You need to decide what your objective is: looking neat or providing a useful interface for data publishing and acquisition. You win some of these capabilities on some platforms with optimized (often hardware-accelerated) pixel painting with native code. It’s not that these effects are impossible to achieve, but they should be used judiciously and only when they enhance and do not distract from the user experience. It is possible to deliver a great user experience that succeeds in the market; it just requires proper mobile Web development techniques and good user-experience skills that take into account the constraints of the environment.
Lovely Bounces and Beautiful Design
Of course, beautiful design matters. From aesthetics to intangibles such as the structure of a good program, software designers must commit to great design and to building on solid practices already in place. Scrolling via kinetic physics, lovely bounces, easing, and so forth create reactive interfaces that feel real and are a delight to use. This is an area where native controls are particularly good.
We have yet to solve the problem of native scrolling satisfactorily with Web technology.1 There have been many attempts: iScroll (http://cubiq.org/iscroll), TouchScroll (http://uxebu.com/blog/2010/04/27/touchscroll-a-scrolling-layer-for-webkit-mobile/), GloveBox (https://github.com/purple-cabbage/GloveBox), Sencha (http://www.sencha.com/), and jQuery Mobile (http://jquerymobile.com/). All of these address the scrolling issue but do not solve it as well as a native device. Even the Google mobile team is working on releasing a solution for this problem.3 Without a doubt, this is the most common complaint the PhoneGap team hears, but we’re one bug fix in WebKit away from it being a nonissue. The Google Mobile team has recently released its solution and code for Web-Kit-based browsers and platforms.2
Here’s the rundown. The Web technology stack has not achieved the level of performance we can attain with native code, but it’s getting close. We’re confident that Web technologies will become indistinguishable from native experiences. In the meantime, Web developers must focus on delivering data while working diligently on improving the decor.
Looking to the Future
As much as native and Web are pitted against one another in this debate, the likely outcome is a hybrid solution. Perhaps we’ll see computing as inherently networked and (this is my sincere hope) free for anyone to access. We already see signs of a native Web: WebGL recently proved that in-browser 3D gaming is possible, even running Quake III (http://media.tojicode.com/q3bsp/)!
In the meantime, software makers must balance the Web-vs.-native debate based on an application’s primary objectives, development and business realities, and the opportunities the Web will provide in the not-so-distant future. The good news is that until all of this technology makes it into the browser, hacks such as PhoneGap can help bridge the divide. I encourage developers not simply to identify software development trends but to implement them! If the Web doesn’t fulfill a capability your particular application requires, you’re presented with an exciting opportunity to contribute and close the Web/native chasm in the process.
Case Study: UX Design and Agile: A Natural Fit?
Bruce Zenel and Andrew Toy
Energy Management on Handheld Devices
Marc A Viredaz, Lawrence S. Brakmo, William R. Hamburgen