Choosing between a web and native experience
|On this page:||Download:|
|Platform options | Influencing factors | Native solutions | Web solutions | Hybrid solutions | Using third-party frameworks | Summary | Further reading|
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
- Hybrid mobile apps take off as HTML5 vs. native debate continues. By Ron Perry at http://venturebeat.com/2011/07/08/hybrid-mobile-apps-take-off-as-html5-vs-native-debate-continues
- Device APIs Working Group: http://www.w3.org/2009/dap
- PhoneGap from Adobe: http://phonegap.com
- jQuery Mobile: http://jquerymobile.com/
- Which Cross-Platform Framework is Right for Me? By Daniel Pfeiffer at http://floatlearning.com/2011/07/which-cross-platform-framework-is-right-for-me
- Comparison: App Inventor, DroidDraw, Rhomobile, PhoneGap, Appcelerator, WebView, and AML. By Jeff Rowberg at http://www.amlcode.com/2010/07/16/comparison-appinventor-rhomobile-phonegap-appcelerator-webview-and-aml
- HTML5 Offline Web Applications: http://www.w3.org/TR/html5/offline.html
Last built: June 5, 2012