Native apps, hybrid apps, webview? What is the preferred approach?
Quite recently, I spoke with a studio specializing in mobile apps and I opened my eyes really wide when I was surprised with a tidbit: “all our apps are coded as hybrids”. In my head, two possible scenarios emerged quickly:
- Hybrid apps are mature enough to have them offered as the only solution.
- The company used to have high competences building websites (JavaScript) and is making relatively simple mobile projects, so that they can solve their customers’ needs with hybrids.
Many people using or ordering mobile apps will see no difference between the same app written in different technology solutions but a specialist will tell the differences at first glance. The telling aspects are running speed, expandability of the app, and to some degree UX. Below you will find the arguments in favor of and against responsive websites ran as webviews, native apps, and hybrid apps.
A webview app
A webview app is nothing more than a responsive website, usually with an added top menu bar and basic functions, such as logging in, language change, app info, etc. Such apps are coded with minimal budgets, in order to e.g. make users accustomed to a product. Customers of popular brands often search for a mobile app. Diki, the English dictionary, is a good example here. The app displays entries from the website. Almost a million Polish users downloaded it so that they did not need to load the website each time they need to check an entry in the dictionary. The reception of the app, despite its small range of features, is positive, as it allows to check a word, listen to its pronunciation, etc.
Example: Diki dictionary, a webview app: Langmedia
Native app
A native app is, from its birth, coded for mobile devices, either in Swift for iOS (previously Objective-C) or Java for Android-based devices. Recently, Kotlin, with the syntax similar to that of Swift, has been on the rise in its popularity. Integration with the operating system is easiest to achieve, as such apps are based on native Xcode or Android Studio components, thus offering the best interface visuals and UX. When downloading a native app, the user also downloads a data package, such as labels, locale, etc., with only some components downloaded on the fly. This makes the app present its data faster than a webview app and require less data. Also, a native app contains just the code which is native to the operating system, thus making it quicker to process. There is also the added value of being able to use the phone’s functions without dedicated plug-ins — this is true for the phone’s sensors, such as camera, microphone, GPS, fingerprint scanner but also the system functions — calendar, contact list, etc. Using these features will, naturally, require granting some permissions to the app but programming a module is the fastest and easiest in case of a native app.
Below you will find an example — an app called Zdrojek Woli Wodę from Grupa Żywiec. The app uses the camera and microphone to interact with the user and contains added animations. Coding such an app is easiest if you follow the native angle.
Hybrid app
To make things simple, hybrid apps translate a code to a language native to iOS or Android operating systems. Despite major developments in all the libraries, such apps still require plugins to be installed in order to make use of system elements or to program the elements as if they belonged to a native app. Thus, if an app is relatively simple and presents database contents, it does not utilize the phone’s core functions. In such cases, hybrid apps do the job.
Example: Nauka w Polsce app, PAP, coded with Ionic
Will hybrids replace native apps?
Currently, the market is split between web apps, hybrids, and native apps. There are, so far, no statistics on the market share of each type of app on Google and iOS webapp stores, as hybrids are “translated” into the operating system’s language before they are added to the selection. Native approach prevails where the expected outcome is either the speed of the app, its stability, or the use of the phone’s functions (microphone, camera, location). Popularity of hybrids, to my understanding, is the result of the ease with which they can be coded and updated. Upon writing a piece of code, we get two products. Maintenance ease and cost also play a part here. When modifying a native app, we need to remember to release the modification on both platforms.
Many programmers are skilled in JavaScript, a language used to present interactive website components. This is the language of choice for the most popular frameworks for hybrid apps — Ionic and React. The latter was released by Facebook programmers to allow for better development of mobile apps. Still, the dominant approach of the Facebook app itself is a native app — most likely because of the running speed and the functions served. Currently, the Facebook app is the world’s third most popular web browser! At the same time, some of its components are coded in React.
Common denominator
Most mobile apps present information stored in databases, i.e. through an API, most likely REST-based. In other words, they use external data sources. Regardless of the approach taken, it is important that the data source, e.g. a CRM or ERP system which provides the data, presents it in a clear and safe way. Experience shows that the hardest task lies in setting up touching points to be used by the app, be it native or hybrid. In case of a webview app, the situation is clear, as the source of the data is a website.
So, which one? Native or hybrid?
It is a truly Solomon dilemma to release an app to just one operating system, although this is often an approach of choice when testing games or apps at the early stages of development. iPhone users, even if they form the minority of mobile phone owners, make the majority in app spendings. Developers are well aware of this, making iOS their system of choice on occasion. At the same time, if you aim for a wide reach and want to offer a free app, Android is the first way to go. This choice is made by e.g. taxi companies, offering their driver apps. Maybe it is worth testing out an idea with just one operating system?
A mobile app is a throwaway if users will not return to it — when they e.g. use it once or twice to read an article or sign up for a newsletter. A webview approach is a good choice if you do not plan to invest in the development of the app but still want it to be available on Google Store and Apple Store. If your app does not make use of the phone’s sensors, and at the same time you are thinking of cost reduction, consider a hybrid app. Finally, if you think you can offer added value to the users with the mobile app, it is worth to develop it initially for one operating system. Once tested and improved, it can be migrated to the other operating system. Just remember that the most important thing is to have a well-working data source and API for the app to acquire data from — regardless whether it is a hybrid or a native one.
Hopefully, I was able to provide some insights. In the table below you will find a quick reference overview.
Author: Dr Krzysztof Wojewodzic, CEO of a software house https://escolasoft.com
