The State of Native vs. Web vs. Hybrid
See an extensive comparison chart below to understand which type of mobile app is the right one to build in your organization. This article was originally published in DZone's 2014 Guide to Mobile Development.
A continuing question in mobile development is whether it’s more beneficial to build applications that are written directly for a native platform or to build applications on web languages and technologies. When tools like PhoneGap emerged, a third “hybrid” option became available that could use native code in conjunction with web languages to gain a set of attributes that no native or web apps have. Today, there are also Mobile Application Development Platforms (MADPs) that can generate largely native apps from a single original codebase, which does not have to be written in web languages.
MADPs are compared on a tool-by-tool basis on DZone’s mobile research portal. For native, hybrid, and web applications, this article will serve as a comparison between the three mobile app types. In addition to the comparison information, you’ll also get a snapshot of the industry use cases and current trends around native, web, and hybrid apps.
Native apps often cost more to develop and distribute because of the distinct language and tooling ecosystems, which require more investment in developer skills if you need to develop for more than one platform. However, cost is dependent on many other factors as well, so native apps won’t be the most expensive option in every case. Building an excellent mobile web app also requires a high degree of developer expertise, so no matter which type of app you build, quality will always be expensive.
Perhaps the biggest weakness of native apps is their lack of portability to other platforms. The appeal of web apps is that you can have one codebase and run it on any major mobile platform. The appeal of hybrid apps is similar, because you are able to reuse a large amount of code for each platform. However, web apps aren’t 100% portable. Newer web standards aren’t always supported by the browsers on every device, so even web developers have to worry about compatibility issues. It should also be noted that native app webviews are not the same as device browsers, and therefore have their own fragmentation issues.
Although web apps can access some basic mobile device APIs, like the GPS for geolocation apps, they still have very limited hardware access. They don’t have support for Digital Rights Management (DRM), which is needed for many multimedia services, they can’t harness background processing, and they can’t use secure storage outside of applications. There are some new standards currently being drafted by the W3C that will give web apps a few more capabilities for accessing device APIs, but for the next few years, hybrid apps and native apps will provide significantly more access to device APIs. Hybrid app frameworks have made a lot of progress getting access to most of the low level features, like the gyroscope and accelerometer.
This may not be the fairest criterion for native applications, but if you want the textual and semantic content of your app to be found and ranked by search engines, your app has to have a web component. A web component is required because apps are closed environments, and search engines cannot access that information.
With app stores, native and hybrid apps are able to harness marketing tools such as rankings and featured placement all in a well-maintained system. Web apps, by contrast, don’t have to fulfill any app store requirements, and they are accessible through any compatible browser. The disadvantages for native and hybrid apps are the app store requirements and content restrictions. For web apps, the downsides are that you don’t get the marketing benefits of an app store. Web apps also have to be manually bookmarked if the user wants a shortcut on their homescreen.
If app updates aren’t automatic, they can be a real annoyance to the user. A huge advantage for web apps is that you can deploy them like any other desktop website. Hybrid apps can make some updates through the web without app store approval, but hybrid apps and native apps still have to jump through the hoops of app store approval, and they need to download any updates from the app store.
For web apps, you can make money through advertisements, subscriptions, or an app store for web apps, though the vast majority of app downloads still happen in the native platform stores. Native and hybrid apps have more options for monetization, including in-app purchases, platform-native ads, and the app purchase itself. However, to be in the high-profile native app stores, you need to hand over a percentage of your app download revenue to the company that owns the store (usually around 30%). There is also an initial fee to develop for the platform and deploy on the app store.
Native vs. Web vs. Hybrid: The Trends
When looking at the trends in the native vs. web vs. hybrid conversation, it can’t be denied that native apps are heavily favored by consumers. A recent survey by Flurry, a mobile analytics company, found that mobile users in the US spend 86% of their time using native or hybrid apps. That number is still 54% even if you filter out gaming apps. Comparatively, 14% of their time is spent in the browser using mobile websites. This is a pretty good indication that an app-like experience, whether it’s through native or hybrid code, is the preferred mode of consumer interaction.
If that’s not enough evidence, you just need to look at the most popular mobile apps right now and you’ll find that most of them are native. Facebook and LinkedIn both tried to build hybrid apps for accessing their websites, but they found that the experience and performance weren’t up to their standards, so they built native apps for all of the major platforms. However, those companies can certainly afford to have many developers with the skillsets to build on those platforms.
An area where web and hybrid app development is becoming more common is in the enterprise. The need for business-to-employee apps (B2E) is expected to grow exponentially over the next few years, and most companies will not want to build and maintain two or more codebases for every app. Another option for these enterprises is using MADPs, which were described in the introduction. The expected growth of B2E apps has led some analysts to recommend choosing hybrid apps or MADPs for large scale internal app development, while building native apps for external customers with high performance expectations. Web apps tend to be recommended if the organization needs to circumvent app stores, build an e-commerce storefront that is searchable on the web, or create a marketing site that is also easily searchable and accessible through the web.
The point of this exploration is not to pick a winner, but to know the strengths and weakness of each application type. The choice between native, web, or hybrid is dependent on a number of factors, including business needs, app requirements, developer skill, and development timelines. All potential types should be explored and evaluated before implementing a mobile strategy.
Want to read more articles like this? Download the free guide today!