Choosing between a web and native experience

Статья
10/15/2012

On this page:	Download:
Platform options \| Influencing factors \| Native solutions \| Web solutions \| Hybrid solutions \| Using third-party frameworks \| Summary \| Further reading

Before developing a mobile experience for your content or app, you first need to choose which platform to use. You can build a native app that is written in the language specific to a device's platform. You can build a web solution using standards-based technologies such as HTML, CSS, and JavaScript. Or, you can take a hybrid approach, using both native components and web technologies. It is not always obvious which platform is appropriate for your app.

There's more to choosing an approach than simply considering the technical advantages and disadvantages. You should also bear in mind how the choice will impact your users, whether it will limit the features your app needs, and whether it will impact your ability to deliver on time and on budget.

Platform options

Let's begin by defining what we mean by native, web, and hybrid.

When you build a native app, you must use APIs specific to the device's operating system. It also generally means working with a language and SDK specific to the platform. For example, in the case of Windows Phone, you use XAML and either C# or Visual Basic. For iOS devices, you use Cocoa Touch and Objective-C.

A web app is an**app written using HTML, CSS, and JavaScript which are sent from a web server over the Internet and rendered in the web browser on the device. In most cases, the browser comes preinstalled on the device, but many devices also allow users to install alternate browsers. This guide is focused on building mobile apps using web technologies.

When we speak of hybrid apps, we are referring to apps that are built using both native code and web technologies. In general, these are native apps that use an embedded web browser. (For example, in the case of Windows Phone it's the WebBrowser control.) The HTML, CSS, and JavaScript for such an app may live on a web server or be embedded in the native app itself.

There is great variation in hybrid implementations. Certain apps will primarily use native platform controls and APIs, and the embedded browser will play a very small role. In other instances you may only use the native platform as a shim, and build the majority of the app with web technologies. In many cases, hybrid apps use frameworks that wrap some of the common native functionality in JavaScript, making it available to the web layer.

Influencing factors

In order to choose the most appropriate technique, you should consider your app's requirements (and how they will evolve in the future), the impact of the chosen method on your users, and the experience and culture of the team developing the app. In general, these and other factors can be evaluated in terms of investment, reach, and features:

Investment. Both the time and money required to build, deploy, and maintain the app must be considered. This includes team salaries, hosting, and maintenance costs.
Features. The features your app needs will play an important role in your decision.
Reach. The number of users you can reach will influence which approach you take.

The following table illustrates how these factors compare across native, web, and hybrid solutions at a high level.

	Investment	Reach	Features
Native
Web
Hybrid

Because the real value of this comparison is in the details, let's explore the specific advantages and disadvantages of each option and how they stack up with respect to these factors.

Native solutions

There are good reasons to build a native mobile experience. Access to device-specific features and APIs is often at the top of list. Using native code you can, for instance:

Integrate with the user's calendar or contact list
Enable the capture and storage of photos and video via the device's camera
Use sensor data from the gyroscope or compass, for example
Access device diagnostics such as the battery or network status

Using such device-specific features is often unreliable or impossible in a purely web-based approach. There are exciting initiatives underway, but it will likely be a while before these standards are ratified, implemented, and widely available.

Note

When building native, you must prioritize the platforms you plan to target. This requires understanding which platforms your target users have, which is not always intuitive.

If your app is graphics-intensive, requires high performance in the user interface, or must function without network connectivity, it will likely benefit from being built in native code.

For users to acquire native apps, most mobile devices today require users to access platform-specific stores such as Microsoft’s Windows Phone Marketplace, Apple's App Store, and Google's Android Market. In addition to making it easy for users to find and install apps, these stores or marketplaces often provide features that facilitate revenue generation (see the official documentation for each store for details about services provided).

Another benefit of native apps is that app update notifications can be delivered directly to the device, allowing you to stay in touch with users who don't use the app frequently.

While the aforementioned benefits of native apps represent a strong argument in their favor, there are also drawbacks. For example, deploying an app to the stores for distribution can be time consuming and often includes a review process that can further delay publication.

In addition, if your app needs to target multiple native platforms, you may have to employ a larger development team (or even multiple development teams) with expertise in each specific platform. This can increase the investment of time and money. If you don't target more than one, you limit your reach.

Web solutions

Web solutions all share a similar runtime environment: the browser. Web browsers come pre-installed on all modern smartphones, tablets, e-book readers, and some game consoles and music players. If the ability to reach a large number of users is your highest priority, then the ubiquity of the web and the multitude of ways users may access your app are of great value.

There are additional advantages of web-based mobile solutions as well. For instance, many developers are already familiar with HTML, CSS, and JavaScript, but if your team doesn't have web experience, becoming competent can be relatively quick and inexpensive. Plus, if you already have a web presence, you may be able to save time by reusing some of your existing web assets and deployment processes. The ability to deploy new features or bug fixes as often as you like is another time saver. Your users will benefit from the time savings as well, because they won't have to install your app or manage updates.

Another advantage (if you have an existing web presence) is that you will already have metrics on the devices your visitors use. Understanding your existing audience makes prioritizing the experience more straightforward.

However, developing web apps for mobile browsers can be less forgiving than developing for desktop browsers. There are issues of screen size, the availability of specific feature support, and other differences between mobile browsers that will impact how you develop your apps. In addition, there are various levels of support for the emerging standards of HTML5 and CSS3, and standards for some features, such as touch, are just beginning to take shape. All of these factors suggest that it is best to keep your HTML, CSS, and JavaScript as simple as you can in order to ensure compatibility with as many devices as possible.

Although you can reach a broad audience quickly and inexpensively, certain features are either not available or will require extra effort to implement. For example, the ability to run apps offline is poorly supported on most mobile browsers.

Hybrid solutions

Using web technologies inside of a native app can give you the best of both worlds. You can mitigate certain disadvantages of the native approach, while gaining a considerable level of flexibility.

Consider a natively built and deployed app whose sole interface is a web view control that takes up the entire screen of the device. All of the user interface and interactions can be built using traditional web development practices. The device-specific features that are not normally available to web apps, such as the microphone or the notification center can be made available to JavaScript. This is possible because many devices allow the JavaScript executing in a web view control to communicate with the native host app. In addition, there are a number of third-party frameworks that provide ways to interact with native APIs using JavaScript. See Using third-party frameworks later in this topic for more information.

Some of the flexibility of this approach relates to where your web assets are stored. That is, they may be embedded in the native app itself, or they may be retrieved from the web. Images, markup, style sheets, and scripts that aren't likely to change can often be bundled with the app to improve load times. Other assets (those that will likely change) can be downloaded as needed from remote servers.

Hybrid apps reap the benefits of deployment in an app storefront while often requiring a smaller investment than native solutions. However, they aren't perfect for all scenarios. Because they share the same deployment constraints as native solutions, it's more time consuming to publish new features or fixes compared to web-only solutions. And while the reach is broader than it is for a native app because the codebase remains more consistent across the targeted platforms, its reach is not as great as that of a web app.

Using third-party frameworks

There are a number of third-party frameworks available to facilitate the development of mobile web and hybrid apps. The list that follows is by no means exhaustive, and is only included here to give you a sense of the types of frameworks available at the time of this writing.

jQuery Mobile is a framework for building mobile web apps. It is a JavaScript UI library that depends upon the jQuery Core and jQuery UI libraries. Its themeable design allows for a customized look that matches the mobile OS design patterns. However, given the various levels of HTML5 support among mobile browsers, not all elements or animations appear consistently across the major platforms. Its main advantage perhaps is that websites built with jQuery Core can detect the mobile browser and reformat the site layout to be consistent with the device's screen size.

Apache Cordova, distributed by Adobe under the name PhoneGap, is a framework that wraps the most common device capabilities when building hybrid apps as described above. It provides an app shell that exposes some native functionality to the embedded web browser. Frameworks such as PhoneGap aim to make cross-platform development easier while enabling developers to use device features that are not commonly available to web platforms. Hybrid frameworks like PhoneGap may also be used in conjunction with other web-only frameworks such as Sencha Touch or jQuery Mobile.

Summary

It’s important to understand the advantages and disadvantages when choosing a platform. The choice is determined largely by the way your app will be used by your target audience. Third-party frameworks can be very useful, but are not always required. The choice to use a framework should be made by weighing the advantages and disadvantages.

Поделиться через