Pawel Zdralewicz

Native, Hybrid, PWA - mobile apps of the 21st century

TheoryWeb DevelopmentMobile DevelopmentPWA
Post image

Mobile applications have become our everyday life. We start the day by turning off the alarm on the phone, then we browse social media, communicate using them, and in free moments we watch funny cats in an app with funny cats.

Not so long ago, the only option to make an application was to learn the native language of the chosen platform and write the application in it. If we wanted to have an application on both platforms, it involved double the amount of work (and knowledge).

Today, mobile applications can be created in several ways. In today's article, I will describe the differences between them and show that the golden mean (unfortunately) does not exist. Therefore, it is worth knowing the possibilities that technology gives us in order to possibly best adapt the solution to your problem.

Let's start with the primal approach...

Native applications

The classic approach to creating mobile applications consists of writing native code for each platform separately. In the case of Android, it is Java or Kotlin, for iOS it will be Swift or Objective-C. As I mentioned earlier - if we wanted to have an application on both platforms, it would involve writing an application for each system.

Native applications are the precursor of the other approaches described in this article. In terms of performance and technological capabilities, they stand at the forefront. Hybrid applications add an extra layer of abstraction, which means from the start that they will be slightly less efficient than native ones.

Native also leads in terms of technological possibilities. Theoretically, hybrid applications can stand on par with it, because we can write native modules that we connect to the application, but it must be borne in mind that this involves additional work. regarding PWA - they do not yet support all native modules and depending on the browser possessed on the phone, they are more or less limited.

An important issue is also the User eXperience of the application. Creating a solution natively, we do not have to worry specifically about compatibility with the rest of the system - it is imposed by the development environment and somehow happens naturally. As a result, users get an application compatible with the UX of the system they use.

Gathering the above conclusions - it is worth considering creating a native application when:

  • We create complex applications requiring performance (heavy calculations, games),
  • We plan to base the logic on native modules / hardware or integrate with physical devices,
  • We want to maintain native UX.

A new era - React Native and Flutter

This section will be based on my experiences with React-Native (hereinafter RN). I have only dealt with it in the context of writing JS applications translated into native code. I am not sure what the ecosystem of other frameworks used to create this type of application looks like.

Using React Native / Flutter, the issue of writing code changes slightly - we have to write it only once and it should work on all platforms. This fact makes this type of approach definitely cheaper than the classic one. We write only one application, which we adapt to individual platforms, instead of creating a separate product for each of them. In terms of UX, you have to put in a little more effort to maintain native UX consistent with the system, but if the application itself is intuitive, it is usually not a problem.

The React Native ecosystem gives many possibilities. It is worth remembering that most packages are community-driven. Whenever delving deeper into the topic, it turns out that less popular packages often cease to be maintained. You may find yourself in a situation where the only sensible way to use the library will be to create a fork and adapt it to your solution or write something of your own from scratch. Remember that this problem mainly concerns less popular libraries, the more popular ones do not have such a problem and are constantly maintained / developed.

Creating interfaces is simple and pleasant. Most needs are covered by component libraries, of which there is a substantial amount. Using them looks similar to the approach known from web-dev. In the case of RN, there is even a library providing components imitating those from native platforms (NativeBase)

Support for native modules in RN is in most cases provided by libraries constituting a bridge between the RN application and the native module API. Despite this, before using any library, I recommend paying attention to its popularity, whether it is maintained and whether it satisfies all our needs. A good rule of thumb is to check if new commits or solutions to issues created by users have appeared on the repository recently. It happens that popular libraries provide a minimal API, which for some solutions may not be enough or do not keep up with updates to RN versions / platforms.

More complex applications can be a challenge. If it turns out that none of the libraries satisfy our needs, it may mean the necessity to "dirty" your hands with native code. Including native code in sources can certainly be found in the framework documentation (for RN here). It is worth being aware that when writing applications using RN, in places the code may require adapting it to individual platforms. This involves writing conditions checking on which system the application works and writing support dedicated to the platform. This is not a very common phenomenon, as the RN team tries to minimize them.

In summary - using this approach may be a good idea when:

  • We care about high performance,
  • We want to maintain one codebase instead of two (cheaper, easier to maintain solution),
  • PWA capabilities are not enough for us (security issues or API availability),
  • We know JS (RN) / Dart (Flutter) and want to use our skills to write a mobile application.

Remember that to build an application for a given platform you must have a device or emulator using that system.

Hybrid applications

These are web applications wrapped by a native WebView component. This approach allows creating a solution using HTML, CSS and JavaScript. This translates into relatively low development cost, because we use basic web technologies, and also we do not have to create a solution for each platform. In short, this means that relatively quickly we are able to create a ready-made solution that will be available on all platforms.

The issue of introducing changes and developing this type of application looks similar. It is much easier to acquire a person who will be able to work based on HTML / CSS / JS, than developers of individual platforms. Thanks to this, rapid application creation is much more accessible.

Unfortunately, hybrid applications are not an ideal approach, they carry their backpack of limitations. Their biggest pain is that in the end, they are a website. This causes them to load longer than native applications and very often require a network connection to work properly.

Hybrid applications also struggle with performance problems. The intermediate layer in the form of WebView significantly affects the capabilities of this type of application. Performing heavy operations and animating views may cause it to reflect on the UX of the application or even make it unusable.

In the era of RN / Flutter and progressive applications I would advise against entering hybrid applications. However, if you still want to consider this approach, read the next paragraph, because I would place hybrid applications in exactly the same place where progressive applications currently are.

Progressive Web Application (PWA)

PWA is a relatively fresh approach in the programming world. For the first time it appeared in 2015, and has been popularized over the last three years. It is nothing but a web application built in accordance with PWA standards defined by Google engineers. PWA applications are based on the capabilities of today's browsers and very often operate based on native modules, such as Bluetooth or geolocation. It is recommended that such an application be written in the spirit of mobile-first or at least that its appearance and operation resemble mobile applications.

PWA is focused on imitating the native approach. Moreover, applications compliant with PWA standards can be installed on any device. It came to the rescue to fill the gap between native applications and websites. You have probably come across sites that propose adding to the home screen. That is exactly what PWAs are. After approving such a message, the PWA application will be added to your phone, just like it was a regular mobile application. Moreover, if we go a step further and make a TWA (Trusted Web Activity) from our PWA, we will be able to exhibit it in the Play Store.

To meet the requirements for Progressive Web Application, it is worth using a tool provided by Google - Lighthouse. This tool allows you to examine any website in terms of performance, best practices, accessibility, SEO, or just compliance with PWA standards.

The heart of PWA are Service Workers. Their use gives a range of progressive possibilities. From handling push notifications, through data synchronization in the background, to caching static and dynamic data. All these benefits add up to a very high level of UX. By adopting appropriate caching strategies, we can provide users with instant application loading (storing in memory basic elements needed to display it). Going a step further - let's assume that our application relies on communication with the server. Received data can also be cached. Such a procedure allows providing users with the possibility of using the application in offline mode. Even the jumping dinosaur from Chrome hides at this ;). More to read about Service Workers here.

In summary - a progressive web application will work great when:

  • We do not need to perform complex calculations,
  • A security level equal to web applications is sufficient for us,
  • We want to have a modern website supporting native APIs, which will also serve as a mobile application.

A few popular examples being PWA: Uber, Spotify.

Modern front-end frameworks significantly facilitate building PWA applications. Despite this, they are not necessary - practically every web application we are able to make progressive.

It is worth bearing in mind that Apple is not very favorable to the PWA approach and using its benefits itself is severely limited. Most likely this is caused by the company's policy, in which PWA does not fit.

Summary

Planning to build a mobile application, it is worth verifying your needs and selecting the appropriate solution for them. It is not always profitable to invest in native applications. The lion's share of business needs can be solved by a much cheaper, more universal solution. I hope that today's article will provide you with basic knowledge about current possibilities in the mobile world and approaching the creation of a mobile application you will know where you stand.

Useful links

Native applications:

Hybrid Applications:

Progressive Web Applications: