The basics of creating a mobile application

In the small world of mobile applications, several technologies exist: there are PWAs (Progressive Web Apps), hybrid applications and native applications. In fact, there's one more, but I'll save that one for last, as it's the icing on the cake.
In this article, we're going to take the time to explain the ins and outs of the different technologies, why choose one over another? What are the costs?

PWA (Progressive Web App)

PWAs are the evolution of traditional websites. They're interesting because, in this case, you don't have to go through the App Store or Google Play store.The installation notification is automatic on Android, whereas on iOS you still have to do it by hand. If you'd like to see a PWA in action, the best known in my opinion is Starbucks'.

(source of this image)

As you can see on the image above, when the user arrives on the "site", at the bottom of the screen he's offered to add it to the home screen, if he clicks on it the application will be accessible from the home screen.When the application is launched from the home screen, it will be in full screen mode, giving the user an experience very similar to that of applications in application stores. It is also increasingly possible to use what are known as the phone's "native" functionalities, such as GPS, camera and Bluetooth. A PWA can also work when there is no network, if it has been installed beforehand, and it is also possible to publish updates that will install on the phone very quickly.

Advantages of Progressive Web Apps:

• Fastest development time
• 100% of code is reusable on all platforms (Android, iOS, macOS, Windows, Linux), JavaScript code for functionality, CSS for design (basically web code).
• Lowest development costs compared to other methods.
• No dependence on app stores (App Store, Google Play Store, Windows Store).
• No need for in-depth knowledge of target platforms - the Web is standard.
• A wide range of tools for building these kinds of applications.

Disadvantages of PWAs :

• Not suitable for applications requiring very low-level functions, e.g. where the terminal's graphics chip is heavily used (high 3D).
• Apple is dragging its feet when it comes to integrating PWAs into iOS, as they can't take a commission on this type of application, preferring that applications go through the App Store, in order to retain control (and commission).
• Even for an app that works entirely offline, it's necessary to have a server (or service) to host this type of application.
• Being a recent technology, it's preferable for the target market to be in possession of fairly recent smartphones (I'd say 2017 and newer).
• An informed user will immediately detect that the "feel" is not as good as a true native application.

Hybrid applications

First and foremost, it's important to know that a hybrid application can also be a "Progressive Web App" and vice versa. Before PWAs, hybrid applications were the way to use the web on mobile (outside the browser).
A hybrid application uses mostly web technologies for its interface, like a PWA, the difference is that this web code is packaged in a so-called "native" application, an .ipa for the App Store (iOS) and an .apk for the Google Play Store (Android), so they are distributed via the application stores of each platform.
the code isn't 100% identical from one platform to the next: to "package" the code in a native application, we use tools like Capacitor (formerly Cordova, which has been abandoned), and this tool gives us the ability to "package" the code in a native application.This tool gives access to a set of plug-ins, which enable access to the native functions of the target platform (Camera, background music playback).
The first example of a hybrid application that comes to mind is Spotify.
Mind you, they don't use "Capacitor" or "Cordova" to package their apps, but a technology all their own, BUT if you look at the Spotify app interface on iOS and Android you'll see that it's the same. This allows them to have a common code base for both platforms, while still being able to work on things specific to each platform (e.g. listening to music in the background, decoding OGG, the format chosen by the company for music storage). Also, when you launch their applications (on iOS in my case), you realize that sometimes when you're offline, the animations aren't "very iOS" (with experience, you can tell right away when an application is not "very iOS").Nevertheless, their choice of technology is justified by the fact that it saves an enormous amount of time in terms of interface code. As a heavy daily user of Spotify, I really like their applications.

Advantages of hybrid applications :

• Fast development time
• Between 70% and 90% of code is reusable from one platform to another.
• It's easy to turn them into PWAs later on (with a bit of work, though).
• Knowledge of target platforms is required, but you don't have to be an "expert".
• With tools like Microsoft Codepush, it's possible to put "bug fixes" into production without having to go through the App Store verification process (which is long and tedious).

Disadvantages of hybrid applications :

• It doesn't have the same feel as a native application.
• On some versions of Android "modified" by the manufacturer, there are unexpected bugs (hello, Samsung, how are you?).
• If the terminal is too old and doesn't support certain web technologies, the experience will be mediocre.
• Implementing certain native functionalities is sometimes more complex than it seems.

The native application

Ah, here we are: the native application. Why do we call it native in the first place? Well, quite simply, because it's designed for a single platform, the iOS version and the Android version have nothing in common, their code is completely different.For Android, you'll find Java or, more recently, Kotlin; for iOS, it was Objective-C in the past, and Apple is now promoting Swift as the native programming language for its platforms (iOS, tvOS, macOS and watchOS).
A user is used to his platform, in my case I've been on iOS for a few years now, this platform is far from flawless, but I've become comfortable with it, I'm used to certain gestures, certain interface reactions. A native application using the programming language and graphics tools that the platform itself uses is very close to the system, so the feel is excellent, fast and when it's really well done, you get the impression that it was the platform developers themselves who designed the application (Apollo for Reddit is a good example).
These applications cannot be launched at all on a platform for which they have not been designed.

Advantages of native applications :

• A top-notch, user-friendly experience.
• Users find themselves in an environment they know and love (yes, they've chosen Android or iOS).
• Extensive documentation is provided by the platform owners (yes, if you use the platform's programming language, you'll get used to it and come back to it).
• Being very close to the system, it's easy to use native functionalities (GPS, Bluetooth, etc.).

Disadvantages of the native application :

• You have to go through the application stores, and you can't go back (transformation into a PWA).
• Much slower and more costly development time: you need to know both platforms.

The icing on the cake: React Native

How about taking the advantages of the hybrid application, but with the graphics tools of the target platforms? To reduce development time and deliver a superb user experience? That's the challenge (and, in my opinion, the success) of React Native.
Foreword: we're going to dwell here on Facebook's React technology, but you should be aware that Google has recently started working on Flutter, which does more or less the same thing. The programming language is different (React is JavaScript and Flutter is Dart), but the substance is the same.
The idea here is, as with a hybrid application, to reuse as much code as possible between the different platforms, but the interface is designed using the platform's tools. React Native bridges the gap between JavaScript and native code, calling it "the bridge".
The result is an excellent feel with reduced development time, a plethora of plug-ins to facilitate access to native functions from JavaScript code, and the ability to update JavaScript code without going through App Store validation via tools like Microsoft CodePush (as with hybrid applications).
I told you that this technology was pushed by Facebook, didn't I? And yes, part (not all) of the Facebook application works with this tool. For an application that has been entirely built using this tool, turn to Discord for iOS.

Advantages of React Native :

• Reduced development time and costs.
• An almost identical experience (even identical in certain situations) to a real native application.
• The ability to easily correct bugs without going back to the App Store via technologies like Microsoft CodePush.
• When it's not possible to code things "very close to the system", it's perfectly possible to take control of the native code (and sometimes no choice).

Disadvantages of React Native:

• Sometimes it's compulsory to stick your nose into the platform's code to fix blocking bugs or access "low-level" functionalities
• You have to go through the application stores, and you can't turn it into a PWA (at the time of writing).

Conclusion

That concludes this article, I've tried to be as clear as possible, knowing that there are several technologies is fine, but what's interesting is using the right technology for the right project (costs, target audience, features ... etc.).