Differences between hybrid, native and webview apps.
A native app is written for a specific operating system. A hybrid app fits any system. How do you choose the type of application?
I was recently interviewing a studio specializing in mobile apps and found myself opening my eyes wide with surprise when I learned that all their apps are made as hybrids. I quickly considered two scenarios in my mind:
- either hybrid apps have already grown to the point where they should be offered to customers as the only solution,
Many people who use or order mobile applications will not notice the difference between the same application written in different technologies, but for a specialist the difference is noticeable at a glance – primarily in the speed of operation, in the ability to develop the application, and to a small extent the UX for the user. Below I compile the arguments for and against responsive websites (running on webview), native, and hybrid applications.
A webview application is nothing more than a responsive web page (RWD), usually with an added top menu and very basic functions, such as login, language change, application information, etc. Apps of this type are made with a minimal budget, for example, for user habituation. Customers of popular brands are often looking for a mobile app. An example is the Diki English dictionary. The app displays passwords from a website. Nearly a million Poles have downloaded it so that they don't have to go to a web browser each time to use the dictionary. The overall reception of the app, despite its poor features, is positive, as it allows users to look up a password, listen to the pronunciation, etc.
A native app is written for mobile devices from the beginning. It is written in Swift for iOS (formerly Objective-C) and Java for Android. Recently, Kotlin, which has a similar syntax to Swift, is also gaining popularity). It is easiest to get consistency with the operating system, because it is based on native components from Xcode or Android Studio, and will therefore offer the best interface design and UX. When downloading a native application, we also download a data package, such as labels, translations, etc. Only some elements are downloaded over the Internet.
This makes the application load data much faster than a web application, it needs less data. In addition, the native application contains only code specific to the operating system, so the device processes it faster. Importantly, without additional plug-ins, it is possible to use the phone's built-in functions. This includes sensors – camera, microphone, GPS, fingerprint sensor, etc. But also system built-in calendar, contacts etc. Using these will require permissions, but programming this module is the fastest and easiest with a native application. Is this the best example of how to choose the type of application?
In simple terms, this type of application translates code into native languages for Android and iOS. Despite the great progress in all such libraries, it will still involve the need to install plug-ins, for the use of system elements or program elements like on a native application.
So if the application is relatively simple and presents data pulled from a database, it does not take advantage of the built-in functions of the device. In that case, hybrid applications can be used.
Will hybrids replace native apps?
Currently, both web-based, hybrid, and native applications are available. There are no statistics available at this time as to what the ratio in the Google or iOS stores is between hybrids and native apps, because hybrids are "translated" into the language of a given operating system before being added to a given store. The native approach prevails where speed, stability, and the use of the phones' sensors (camera, microphone, location) matter. The popularity of hybrids in my opinion is due to the ease of updating them, as well as writing them. By writing one program, we get two products. The ease and cost of maintenance is also not insignificant. When modifying a native application, we must remember to make changes for both platforms.
The common denominator of all apps
Most mobile apps present information from a database, that is, through an API (usually REST). In other words, they pull information from other sources. So regardless of which approach prevails, it's very important that the data source (e.g. CRM, ERP) from which you pull data presents the data in an accessible and secure form.
Experience teaches that it takes the most work to create good points of contact that the application - whether hybrid or native - will use. In the case of a web application, the situation is clear, because the source of the data is the website.
Which approach to choose – native or hybrid?
The Solomon solution is to create an application for only one operating system. Which is an approach often used to test games or apps in the early stages of development. iPhone owners, although in the minority, account for most of the money spent on apps. Developers know this, sometimes deciding only on this system. The type of app matters; if you care about broad reach and a free app, it makes sense to start with Android. This approach is used, for example, by cab companies for drivers. Why not test your idea by starting only for one operating system?
A mobile app is not worth creating if users will not return to it - for example, if they only enter once or twice to read an article or sign up for a newsletter, for example. Use the web approach if you don't plan to develop an app, but nevertheless want to make a presence in the Google and Apple stores. If your app does not use sensors on the phone, but you want to reduce costs, think about a hybrid app. Finally, if you think you can offer added value to users through a mobile app, it's a good idea to start by developing it for one operating system. Once you test and refine it, you can prepare it for a second operating system as well. Keep in mind, however, that the most important thing is a highly refined data source and API from which the app (whether hybrid or native) will retrieve data.
I hope I've managed to help you, and I'll end with a brief summary of the theses from the article.
|App type||price||UX/UI Possibilities||Device functions (GPS, camera, mic)||Working speed||App development||Stability and security|
|Webview or PWA||$||Very limited. Usually a bar at the top and only a few features that are web pages||Limited - based on the browser||Depends on website||Limited to website capabilities||Depends on the website|
|Hybrid||$$||Matching Google and Apple's designations, requires some extra work, but is possible||Most features are available, but require installing plug-ins or additional work by developers||Depends on the quality of the application code and the complexity of the application||Possible, up to a certain level of application complexity||Moderate, depending on the quality of the code and functionality used|
|Native||$$$||Complies with Apple and Google's UX/UI designators||All native functions are available||Fastest. Some of the features available when you download the app||Unlimited. Requires work effort for two platforms.||Highest|