Mobile applications : NativeApp, HybridApp or WebApp?
When you are ready to launch your platform into the mobile world, you will surely hear about native application, WebApp or hybrid application. Choosing the type of application to use is an important decision, and depends on your strategy in terms of content and functionalities.
But how do these types of applications differ from each other?
- Native applications are directly accessible from an icon on a mobile phone home screen and are installed from the different AppStores. They are developed for a platform in a specific way and allow use of all the functionalities of a phone, whether it is the camera, the GPS or the accelerometer. They are touch-enabled and respond as you move your finger on the screen. Finally, native applications can use the phone notification system and they can function offline.
- WebApps aren’t, strictly speaking, applications. They correspond to websites reproducing native aplication functionalities, feeling and design. They are interpreted by a browser and most of the time they are produced in HTML5. To access the content, the user needs to type a URL into a browser and can “install” them by creating a bookmark for this webpage. WebApps have grown more important with the arrival of HTML5, which enables to mimic native application functionalities. Websites increasingly incorporate this operating mode and the line between WebApps and classic websites has become a thin one.
- Hybrid applications are half-native, half-WebApp. Similar to native applications, they are uploaded onto an AppStore and enable access to the phone functionalities. Similar to WebApps, they use a webpage to display content, this web page being integrated in a traditional application framework. Most of the time, hybrid applications constitute packaging for webpages; they offer a presence on the AppStore without requiring the complete development of an application. They are also popular due to the fact that they can cross platforms, since the same HTML code can be used on all of the mobile OS.
Let’s examine in detail the elements that allow comparing these different solutions to each other.
Generally speaking, it costs less to develop a hybrid application or a WebApp, since technical knowledge is shared with the web field. The development of a native application is often perceived as much more expensive because it requires the involvement of specialists in the field.
It’s also important to consider that these costs can be multiplied if your application needs to be available on various platforms. However, the cost of a mobile application also depends on other factors and a native application won’t always be the solution requiring the most funds.
First, although it shares the same technical basis with the web, HTML5 is still relatively new and a good knowledge of its application in WebApps or hybrid apps is also an advanced skill. Producing a quality application will always require highly skilled developers, whatever the application type. Quality will always be costly.
At the end of the day, two factors will impact the cost.
- Plateform number (iOS, Android, WindowsPhone, …)
- Device type (tablet, smartphone, …)
As soon as you made the decision to support more than 2 platforms and more than one device type, the cost of a native application becomes higher than that of a WebApp or hybrid application. However, even if you choose one of the latter two, you shouldn’t underestimate the optimization cost for different browser versions and the cost associated to the device and the manufacturer.
A major weakness of native applications is without a doubt the lack of portability to the other platforms: a native application is developed for a given operating system. WebApps and hybrid apps have taken full advantage of this door left open to them: WebApps use a single code base and can operate on any major mobile platform, and hybrid apps reuse most of the code on each platform and only require modifying whatever may function differently.
However, WebApps aren’t 100% reusable. With the evolution of web standards and the various developments made over time, browsers may not support certain functionalities on all devices. Hence the compatibility issue isn’t specific to native application. Likewise, webviews present in native applications are a particular case and shouldn’t be treated as browsers, which also raises other issues of fragmentation.
Native applications, as well as the native components of a hybrid application, are fully compatible with the device hardware. Consequently, they can have access to the device functionalities such as the accelerometer, the camera, the GPS or the notification system. WebApps, on the other hand, can only have access to a limited number of these functionalities.
Indeed, WebApps can only use the most basic APIs, for example the GPS for geolocalization purposes. Other than that, they remain very limited in their access to the device hardware. For example, it’s impossible for a WebApp to run in background mode or to create a secured storage space within the phone.
However, new standards are being elaborated by the W3C in order to provide more access options to APIs. For now, native and hybrid applications remain the only ones with a privileged access to APIs. In the case of hybrid apps, depending on the framework they use, not all of them have access to all APIs. But since framework evolution has already started, access to basic functionalities such as the gyroscope or the accelerometer is already possible.
In short, although web technologies are catching up quickly, native applications will always stay ahead. Certain functionalities that only operate with specific browsers are also a major issue. Only one thing will remain the same: when a new functionality is available through a native app, it will only be available much later through a browser.
From the user point of view, most WebApps and native applications look alike and operate in the same way, with few differences. However, if you want to provide a service consistent with the operating system, and have an application with a design resembling that of leading applications, it’s much simpler to produce it through a native application.
But that doesn’t mean you should put aside WebApps. They can provide as good a user experience as native or hybrid applications. But you need to take into account that there will be differences in their graphic presentation and that they won’t fully match the setting a user is familiar with.
WebApp and hybrid app design frameworks strive to create components that are close to the spirit of those of native applications. However, these frameworks need to be constantly updated since new Android ou iOS versions are often associated with an important graphic redesign. Hence it is not uncommon to see WebApps keeping an iOs 6 style.
An application developed with an operating system native language will always be the fastest and surest way to reach a certain performance level. Facebook or Wikipedia fully understood this and converted their hybrid applications into native ones. In 2012, Mark Zuckerberg even admitted that Facebook had made a big mistake by betting on the mobile web instead of taking the native route.
However, hybrid applications and WebApps aren’t just another labyrinthine system unable to provide a seamless user experience. Facebook and Wikipedia are special cases if you consider the volume of data they process on their servers during a single day.
You may think that publishing a native or a hybrid application on an AppStore is an easy process and gives you better visibility than a simple WebApp. This isn’t completely true: actually, referencing an application is as big a problem as referencing a webpage.
An application displayed on a store is also going to face user ratings and visible comments directly on the download page. This is both a strength and a weakness, since an application receiving a bad score from the beginning will be unlikely to take off later. The publication of an application also needs to follow a process whose strictness depends on the platform, which slows down its immediate availability. (The publication of an application on the Apple AppStore can take several weeks).
A WebApp consequently cannot benefit from the full marketing effect generated by an AppStore. You should also keep in mind that unlike an application installed on a phone, the user has to take the initiative to create a bookmark on his/her phone to quickly come back to the WebApp.
At the end of the day, the most important thing is your marketing strategy and how you plan to make people discover your application. Whether you choose paid ads or an advertising campaign through the social networks, it is definitely the most important piece of the puzzle for applications that aim at attracting users. Consequently, your marketing strategy will often dictate which route to take.
A WebApp will always be more dynamic than an application in terms of content updating and flexibility. This is simply due to the fact that application updates aren’t necessarily automatic, whereas a WebApp can be rolled back or modified just as any website. However, hybrid applications can be modified on specific points wihouth having to undergo an update through the store, but generally speaking native and hybrid applications always need to go through the store publication system.
Updating an application also means that its users need to download it, so it’s always possible that some users decide to ignore the update and you will then end up with different versions of your application at the same time.
Finally, last but not least, monetization of your application / WebApp. Just as a website, you can put ads or a subscription mode on your WebApp, however this means setting up your own payment or subscription system.
Native and hybrid applications operate within a specific model. Methods are defined by the AppStores themselves, generally with the possibility to buy things within the application, to manage the integrated ads or to purchase the application itself. However, a percentage (generally around 30%) must be paid to the platform on each sale made. Also worth knowing, you need to pay a license in order to launch your application on the store.
The decision to create a native app, a hybrid app or a WebApp depends on many factors, including (but not limited to) economic goals, technical specificities and target audience.
If your goals are mostly marketing-oriented, or if you aim at setting up content and establishing a presence in the mobile world that can easily be shared between users and referenced on search engines, the rational choice is a WebApp.
If, however, you aim at offering an interactive experience with your users, as well as producing an application that operates more like a computer software than a internet website, then a native or a hybrid application is probably the right option.
However nothing stops you from doing both: native application and WebApp. Some companies, such as Facebook, have this choice, so they can attract as many users as possible. However, for the majority, resources and budget constraints will make it necessary to choose one option or to prioritize the solution to develop first.