Native, React-native or PWA, what should I choose?!

When you start a project, you are usually confronted with this problem: what should I use? A funny guy might come up with the crazy idea of using Xamarin (and you won’t be able to find anyone to take over the project afterwards) or with a framework maintained by only one guy and that is not even open source. Let’s be serious and look at real alternatives used by more than 2 people in Paris (yeah, I’m working there).

The actual state of the art (for me at least) are the following:

• Native implementation, with Swift (or objective C) for iOS and Kotlin (or Java) for Android.
• React-Native, with Javascript (obviously) and a bunch of open source libraries that you can find online.
• Progressive Web Applications, with web standard technologies like Javascript, HTML and CSS.

Pros and cons

We’ll first take a look at the pros and cons, in order to have a clear view of the options.

The native way

In the world of smartphones, creating native applications was initially the only way to install an application on a smartphone. Android and iOS (yes, windows phone is dead!) have evolved in such a way that developing a native app makes it easy to interact with all the built-in features offered by the hardware (limited for iPhones, but you’ll see later why 😉). Which leads us to our first point.

• It’s easy to interact with the hardware. 👍

Considering that you are talking the language of the hardware, it’s quite obvious that you’ll be able to do whatever the OS allows you to do. And if you talk the language of the hardware…

• It’ll probably have a better performance 👍

But when we talk about those advantages, it implies that…

• You have to learn a language for each platform 👎
• You need to develop the application for each platform 👎

The “hybrid” way

After the appearance of single page applications, some people had the wacky idea to put a browser engine and a web application in a binary. It’s how Apache Cordova was born. It has some advantages.

• You only have to develop it once and it runs everywhere 👍
• You can access the hardware through interfaces 👍

But this method had the inconvenient of being quite slow. And an urban legend says that the app store refuses them for obscure reasons.

So instead of fighting with the devil, some developer kept the idea of “develop once and run it everywhere” and started a framework (or an abstraction) where, like a marionette, you manipulate, using Javascript, basic elements like View, Buttons, Text, style, etc, that are interfacing native elements.

This way, you keep the above mentioned advantages and, once compiled, you end up using native elements.

• You have the aspect of a Native Application 👍

But if you develop once and use it everywhere, you might end up with some differences between iOS and Android. For example, Android has been giving you access to the NFC or other cool stuff, while iOS is still not allowing you to share a song by Bluetooth. Those differences might seem insignificant, but, at some point, it might overload your code logic.

• More complex logic when you use non generic apis 👎

Also, in long term projects, this kind of logic might tend to make the application complex and harder to maintain.

Progressive Web Applications

Considering that PWA are “quite new”, I should probably start with an explanation. From a high level point of view, a progressive web app is an application where all the assets (HTML, CSS, Javascript, Images, etc) are kept in the browser, using web workers, which allow you to use them offline and to add a shortcut on your home screen. And because Google (funny thing, Microsoft also) realized that this technology was a good opportunity to invest in. You even have some extra features on Android, like creating a WebAPK, that end up looking native.

To start with the advantages, considering that we’re talking about a web application:

• It runs everywhere (mobile, tablet, desktop, fridge, windows phone) 👍
• You have a web version (almost) for free! 👍

Considering that it works everywhere, if you make it simple, your app will look the same everywhere. But because it’s web, you can customize the look depending on where it’s running. If you detect that it’s on an iPhone, you put the “create” button on the top right. If it’s an Android, you put a round floating button on the bottom right. Easy, right?

• In terms of style, you can do whatever you want 👍

But the problems of web applications are that the browser is encapsulating your app, and because of that, you could think that you won’t be able to access any hardware. This is not entirely true (or not entirely wrong). To make things simple, everything your browser can access (Geolocation, mic, cameras, some sensors, etc), your app can also. It depends only of your browser (bye bye Safari) and the OS. Which is more than enough for most of the apps.

• I can (almost) use the hardware 👍 / 👎

And because of the way a web application works, when you close a tab in your browser (or kill the progressive web app) the application is killed.

• Not possible (yet) to have a background process 👎

So, the features like geofencing… you can forget it.

Well, let’s consider that you don’t need hardware features and you decided to make a PWA. You finished it. It’s ready. Let’s put it in production. And that’s it! No need to pass by any store!

You forgot something? As a good developer, you write your tests, you code your feature, and then you deploy. And that’s it!

• You don’t have to put it in the store 👍
• You can deploy a new version in a few seconds 👍
• You can do whatever you want with your app 👍 / 👎

Wait a bit… It has the advantage that you don’t have to satisfy the crazy rules given by Apple (my fanboy colleagues won’t agree with that) and that nobody will give you a bad review. But on the other side, users cannot find your app on the store… Not yet…

• Your app cannot be found in the store 👎

Small exception for the Windows App store, where you can add your progressive web application and install it on your phone or on your desktop. Well played Microsoft (ouch, it’s hard to say it)! Probably to finally have some applications in their store…

Let’s recap

Native: It’s quite expensive (1 app by platform), it’s efficient (native language) and has full features (depends on the phone).

Hybrid: Normal price (when you don’t need device specific stuff), quite efficient (if you need something more efficient, you can use the native language) and has full features (use the native language if you really need to).

PWA: Quite cheap (considering the target audience range), quite efficient and has restricted features (depending on the browser, but it’s on the way).

Time to fight

To avoid any usual battle (that I’m probably famous for) like “This is the best option because I say so”, we’ll look at a few questions that will help you (or your client) choose between these 3 alternatives.

Do you have a big budget?

To be clear, native is more expensive. You have to develop it twice. It doesn’t mean that the others will split the budget in 2. Doing something multi-platform has a cost, most of the time, 1.5 times the cost of an single app.

Do you really need to be visible in the store?

This is a business question. If you are satisfied enough that going on get-myapp.io will open your app, then all the solutions are good enough. If not, just say goodbye to the PWA.

Do you need to do something with the hardware?

This is more like a question for a techy person. If you want an application with a list, a chat, a map, or even a video call, well, the PWA would work. If you need to use more of the hardware, then forget it. And if you want something really efficient, you should probably go native.

Conclusion

To sum this up, the native implementation gives you access to more features with probably a better quality at a higher cost, while the PWA will give you the essential features at a lower cost. And the hybrid app is somewhere in between.