Mobile app client architecture: The difference between native vs. hybrid vs. web apps

Of all considerations when developing a mobile app - by far the most important would be which architecture to choose for the client application. Should you build a native app or a mobile web app? Should you try to build a single application that works across all mobile platforms? Tough questions - and there is no one right answer or one best option for mobile app development.  There a number of factors to consider including:

• Target audience - who will be using the app?

• Target platforms - what devices will be targeted?

• App features and functionality - what features will be in the app? What hardware features (mic, camera, compass, gps, etc.) will be used

• Timeline and budget - how fast do you need an app and how much are you willing to pay?

• Developer skills - what languages and platforms do your developers already know how to use?

The client architecture options can be broken down into a couple different areas...

Native apps

Native apps are binary executable applications that are stored on and run locally on the device.  Native apps usually work just like any other built-in app (mail or web browser, for example) and have full access to the device APIs and features, as provided by the vendor.  Native apps are usually obtained via an app store (i.e. the iOS App Store or Android Marketplace), though can also be obtained via enterprise or ad-hoc deployment depending upon the platform.

Native apps are also usually updated via an app store (or similar) and there can be a lead time and approval process involved before updates can be deployed to end users. Native apps are usually developed in the default language of their respective mobile platform, for example - Objective-C on iOS, Java on Android, and C# on Windows Phone 7. As native apps are usually written using a programming language, framework, and tools specific to a single mobile platform - they cannot be used on other mobile platforms. So, perhaps an obvious example - but Android apps can't run on iOS and vice-versa.

Mobile web apps

Mobile web applications run inside and are (usually) accessed via visiting a URL in the web browser on a mobile device.  Depending on the platform, mobile web apps can also usually be launched via an icon from the home screen if the user chooses to "install" or bookmark the web app, similar to how a native app is launched. Mobile web apps are built using HTML, JavaScript, and CSS - and they may or may not make use of HTML5 (for advanced interactions) or a javascript framework that eases mobile web development, such as jQuery Mobile or Sencha Touch. Mobile web apps can usually mimic the look and feel of a native app, though they have less access to device features and APIs than a native app, as the app is constrained by running within the web browser.  As the code for a mobile web app is run on a web server and not distributed via any app store, the code can be freely updated and redeployed without any submission process or approval from an app store vendor.

Hybrid mobile apps

"Hybrid" mobile apps cover a couple different, similar architecture options - the common thread between them is that they are largely based on web technology (i.e. HTML/CSS/JavaScript) running within a native app, mimicking the look and feel of a native app. 

Deciding on the best framework for hybrid mobile app development

All native app frameworks include capabilities for displaying web-based content within an app (i.e. the UIWebView in iOS), and hybrid apps make use of this functionality to display web content within a native app wrapper. The web content (images, HTML, JavaScript, etc.) making up the app can either be packaged up and stored locally within the app, or it can be accessed from a web server. The native part of the application is able to fully access device-specific APIs and hardware features that a web application doesn't normally have access to. The most common way to build a hybrid app is to put web content within a native "wrapper" app - app screens can then either be completely web-based or a combination of both web and native screens.  As hybrid apps are written within a native app shell - they can also be distributed via the app stores.  The Facebook app on most platforms is a good example of a hybrid app - combining web views with native views in order to display dynamic content, like the news feed.

Now that we've defined our three client architecture options, we can get into the detailed strengths and weaknesses of each platform. We'll look at a couple different areas including performance, distribution, deployment, access to hardware features, offline functionality, cost, and the portability of code between mobile platforms.

Performance

The JavaScript code used in a mobile web or hybrid app is being interpreted by the web browser on the device, and thus runs slower than compiled, native code used in a native app in most cases - though JavaScript performance has seen massive gains in recent years, and will probably continue to improve. Processing done with native code in a native app will execute faster than the same processing in JavaScript in a mobile web or hybrid app. Though, hybrid apps have an advantage here in that they can make use of both native and web-based code - processing can be offloaded to native code if required.

One key performance topic to keep in mind is UI performance. Few mobile web apps can fully replicate the smoothness and responsiveness of a native app UI without some minor jitteriness, lag, and inconsistencies. Some can get very close (usually on iOS), but then the UI works poorly or not at all on other platforms. UI performance should be a major factor in the consideration of which architecture option to use. If the absolute best UI performance and user experience are required, or the app is a highly visible "marquee" application, go with a native app. If the app requires performance-intensive client side processing, go with a native or hybrid app. Otherwise, a mobile web app may work well if the app will be built on multiple platforms and doesn't require the top-quality UX.

While mobile web app performance isn't currently on par with native app performance, web app performance as well as tools and libraries for building cross-platform apps have both improved greatly even within the past year. These areas will see advancements as mobile hardware is upgraded, platform vendors enhance their web browsers, and commercial and open source developer tools are improved eventually bringing mobile web app performance up to par.

Deployment

Native and hybrid apps can be downloaded and installed directly from an "app store" on most modern platforms, which provides a potential marketing boost and an easy way for potential users to discover and download apps. The vendor's app store is then also responsible for alerting users and deploying updates to apps. However, one issue with app stores is the inevitable lead time involved in waiting for approval of new apps and app updates, which can take a week or more depending on the time of year. If delayed updates or approvals would be an issue for your app, you may want to consider a mobile web app instead.

Native and hybrid apps can also be deployed to internal corporate users via "enterprise deployment", by a mobile device management (MDM) solution or an internal "app store". Being limited to internal corporate users, enterprise deployment of apps requires no vendor approval for updates, etc. - putting control in the hands of the IT department.

Mobile web apps also require no approval from a vendor for deployment, as they're usually accessed by the user entering a URL into the web browser. Most mobile platforms usually offer some way to "install" or bookmark a mobile web app so that it will appear on the user's home screen and can be launched by clicking an icon, similar to a native app. Updates to a mobile web app can be deployed by simply updating the server-side code. If there is a need to iterate quickly on updates, a mobile web app may be a good choice. Mobile web apps have an additional benefit of being discoverable and directly accessible via search engines.

Another item to consider about vendor app stores, most vendors (Google, Apple, and Microsoft) take a 30% cut of any purchases (of functionality, subscriptions, services, upgrades, or content) completed within an app. If in-app purchases are core to the app and revenue - consider building a mobile web app. To note, an app submitted to the Apple App Store that uses any alternative, non-Apple in-app payment system would be rejected - so a hybrid app would not be able to circumvent these rules by routing purchases through a web view.

Access to hardware

Native apps generally have full access to the hardware features of a mobile device, i.e. the camera, accelerometer, GPS, compass, file system, storage cards, microphone, etc. While mobile web apps are improving in this area with HTML5, they still have more limited access to the hardware features in most cases. Furthermore, it's unlikely that the same web code will be fully supported and usable across all platforms (i.e. iOS, Android, and Windows Phone 7) as they all currently differ in their level of support for HTML5 and hardware device access. For example, GPS is currently well-supported by web apps on most platforms - but accessing the camera or uploading photos is poorly supported by most mobile web browsers.

A hybrid app built with a mix of native and web code is one way to enable access to hardware features while still using web-based views. Most mobile platforms offer a way to bridge between the web views and native code, allowing web views within hybrid apps to access device features via native code. A common solution is to use a framework like PhoneGap, which provides a common JavaScript API for hardware device access that works across nearly all platforms, as long as the mobile web app is wrapped in the native PhoneGap wrapper app, effectively creating a hybrid app. One thing to keep in mind though is performance again - while an app may be able to pull pictures from the camera using PhoneGap, more performance-intensive tasks like streaming video or augmented reality may not be possible without using native code.

Offline functionality

Native apps generally have the most capable offline functionality, as they usually have some ability to run background processes and it's easier to gracefully handle offline scenarios in a native app. Mobile web apps traditionally require internet access in order to use. However, this is an area where web apps are rapidly improving - but support is still not uniform across platforms, and a user can always blow away an offline web app by clearing their browser cache. Mobile web apps also currently have limited capabilities to run background processes (when the app is closed) or worker threads (while the app is still open) - for example, it would be impossible currently to build a mobile web app that plays music in the background while other apps are running.

Hybrid apps again build a bridge here between mobile web and native apps, allowing background processes to run within native code while still using web code for the bulk of application functionality. However, if the HTML, CSS, and JavaScript used in a hybrid app are not cached locally within the native app and require internet access to view - then offline capabilities would be hobbled, similar to a mobile web app. A basic hybrid wrapper app with a web view that simply points to the URL of a mobile website would not gain any offline capabilities, though it may be easier to detect the offline condition and alert the user. If your app requires store-and-forward type processing for offline updates or background processes, consider building a native or hybrid app.

Code portability

One benefit to hybrid and mobile web apps is that the code (the web-based parts written with HTML, CSS, and JavaScript) can generally be re-used across mobile platforms, usually with some small tweaks to ensure everything works right in each mobile web browser. Web-based apps may be skinned to mimic the default native look and feel of a specific mobile platform, or they might use the same generic interface across all platforms. A common downfall with this approach is that cross-platform mobile web apps are usually reduced to the lowest common denominator UI when using the same code and layouts between multiple platforms, because each mobile platform has its own native user interface and navigation paradigms. For example, the Windows Phone Panorama control has no exact equivalent on iOS or Android - so trying to replicate the Panorama paradigm within a mobile web app would require some major code, layout, and navigation changes for an iOS or Android mobile web app... and if you're making major code changes between platforms, then why not just build a native app in the first place?

Native apps, on the other hand, must be completely re-written between platforms - Objective-C code won't run on Android, and Java code won't run on iOS. For a hybrid app using a mix of native and web code, only the web-based portions would be portable between platforms and the native portions would need to be re-written.

Cost and timeline

Cost and timeline are usually the most important factors in most software projects. Native applications have to be completely re-written between platforms and thus have the highest cost if you plan on building an app on multiple platforms. In a perfect world where mobile web app code works perfectly across all platforms, mobile web apps would theoretically be the lowest cost option for cross-platform development. Unfortunately, a significant amount of time is often spent at the end of a mobile web app project ironing out inconsistencies and performance across different platforms usually increasing the cost beyond that of building a native app on a single platform. Nonetheless, developing a single codebase will always be less costly than developing three separate codebases. For hybrid apps, only the native portion of the app must be re-written between platforms, placing the cost of building cross-platform hybrid apps somewhere in the middle between native apps (highest cost) and mobile web apps (lowest cost).

Other options

There are some other mobile architecture options that fall outside of the definitions laid out in the beginning of this article. There is a set of tools currently available that allow you to build native apps using non-native code which is then compiled to native code on the target platform, rather than mimicking the native user interface via web technologies. These tools include Xamarin MonoTouch and Mono for Android (C# for iOS / Android), Appcelerator Titanium (JavaScript for iOS / Android / BlackBerry), and CodeNameOne (Java for iOS / BlackBerry). These products allow you to write a single set of client back end code (things like business logic, service and database access, domain classes, etc.) using one language that can then be re-used across platforms. Because the UI conventions differ between mobile platforms, the UI-related code must usually be re-written for each platform.

For example, Xamarin MonoTouch and Mono for Android allow you to write native apps for iOS and Android using C# and re-use all non-UI code. That code can then also be re-used for Windows Phone 7, which uses C# and .NET APIs by default. UI code usually makes up about 40-60% of a mobile codebase (depending on the UI complexity), which allows a significant amount of code to be re-used between platforms. Xamarin also provides a set of agnostic APIs that allows for a unified cross-platform method of accessing features like GPS, contacts, camera, media, etc., which makes code sharing across platforms easier. These native cross platform products are a viable option (especially MonoTouch, from personal experience) for building true native applications, while still retaining some level of code portability between platforms.

Architecture selection

Each architecture option works best for different kinds of applications. Native applications currently work best for:

• Performance-intensive apps

• Apps with offline or disconnected requirements

• Games or apps with rich visuals

• Apps that require background processing

• Apps requiring heavy interaction with local data or device hardware

Native apps also work well for marquee applications that can't compromise on user experience or performance, where cost savings and productivity gains from cross-platform code sharing is not a goal. Native apps also make sense if only a single platform or device is being targeted, where there is no reason to re-use code on other platforms.

Hybrid and Mobile Web applications work well for business and content applications, and apps with more basic user interface and functionality requirements. They both also work well for apps targeting multiple platforms. Hybrid apps work well for adding native functionality to existing mobile web apps, or simply creating a native wrapper around a mobile web site. Mobile web apps also work well for creating a simple mobile-optimized version of an existing web site.

Keep in mind that these technologies and decision points will continue to rapidly evolve - browser compatibility and performance will improve, HTML5 standards will be solidified, and products like MonoTouch will be developed further. While there is no one best client architecture option, the best option for your app can be determined by weighing your requirements and goals against the capabilities, advantages, and disadvantages of each architectural option.

A short deck summarizing the options and their strengths and weaknesses is available here.

Our consulting professionals are experienced in developing enterprise and consumer mobile applications on the Apple iOS, Android, and Windows Phone platforms. Read more about West Monroe Partners' Mobile Application Solutions.