Web Development

Tired of a customer asking for something specific without thinking? Do you need a mobile app or a PWA? Let’s see what is that about.

So many people ask me about progressive web apps and how to build one…

They tell me that they want a mobile app even if they just started their business and have no website…

They also ask me if it’s cheaper, if it’s easier…

Some are stubborn and absolutely want one PWA, some on the other side wants a mobile app…

The first thing you need to understand is that a P.W.A is not a special kind of application on its own. You can take any website, even your Wordpress blog, and turn it into a PWA by simply providing few things.

One other question I always ask is: Why do you want a PWA? Why do you want a mobile app?

Before developing something, it’s essential to understand why your customer wants something specific and question it about. Ask him for its needs, which platform he wants to target, what is his problematic.

Otherwise, you end up wasting time and money and your customer (or just you) won’t get satisfied, which is bad… bad things

This article aims to answers some of the questions you could ask your customer and will allow you to direct him to a specific solution that fills the need and is cost-efficient.

Ready? Let’s start with the PWA.

Progressive Web Apps in a nutshell

A website that fulfills some requirements like a web manifest file and is optimized for offline usage. It tends to be a mobile app but it’s not.

Specificities

• Built with HTML, CSS, and Javascript.
• Relies on browser implementation, which can be different depending on the version, platform, and rendering engine of the browser.
• Can leverage all web library ecosystem and easy implementation.
• Accessed by an URL directly in the browser, can be wrapped in some kind of app container to appear as a “kind of app”.
• Almost invulnerable to cross-platform specificities in terms of UI rendering and behaviors, despite and thanks to the browser engine differences/similarities.
• It can use some nice features such as web notifications and it’s getting better over time with various enhancements.

For your website to be considered as a PWA you need to

• Have an App Manifest file, which describes the application name, gives some configuration and other rules, and register an SW file.
• Register a service worker (SW), which is a small script that acts as a middleware between your network layer and your server. Thus, you can return a cached response from the frontend to improve the offline experience. Think of it as the reverse proxy on the frontend side.

What should I think about before going to a PWA?

1. You need to have a desktop version of your app and also a nice responsive website. You can do it easily leveraging CSS media queries and with minor to zero code changes.
2. You don’t need blazing fast performances and you don’t care about the feel of the navigation. As it’s generally like a website, and because it’s rendered with a browser engine which is a bit slower.
3. Your app is not relying on specific API that might not be supported by the browser, such as Bluetooth, which is not supported by all browsers currently in 2020.
4. You want to leverage a lot of libraries that are built and battle-proven for the web.
5. You want a rich ecosystem with tons of developers that are performant building web apps. It’s easier to find maintainers and developers for the web than for cross-platform mobile development.
6. You have a good Continuous Integration (CI) / Continuous Delivery (CD) platform for web projects, where a mobile one is a bit more complicated to put in place.
7. You need to use awesome test frameworks for the web such as the wonderful Cypress to write tests for all platforms.
8. You’re (mostly) using HTTP and REST for exchanging with the server, otherwise, you’ll have some issues caching the results using a service worker. You’ll need to implement your own offline caching logic or use a specific library for that. (there are many in fact, so not a big deal).
9. You want to maintain one version of your app at the time and be able to deploy hotfixes as soon as possible in short terms.

That last point is really important because using a web application you have more control over the application, as each time the app is started and if the internet is available, your user will download the latest version of the files directly from the web service. We will see that it can be a bit more complicated with mobile.

About IOS support today in 2020, it’s true that not all features are supported. But making your app PWA compliant is already a good enhancement and value proposal for your customer. In reality, in developed countries, most of the time you have some kind of internet connection (I know about some USA’s states or some countries that have some issues). It means that the user won’t experience the lack of offline capabilities IOS have.

Mobile app, the good old one

Fully autonomous application package, knows as a heavy client. It’s built for speed and to reduce network exchanges with a good user experience.

Specificities

• Build with natively compiled code with Java / Objective-C.
• It can be cross-platform easily with some framework such as Flutter or React native.
• Blazing fast performances
• Best offline capabilities
• All native API such as Bluetooth, localization, NFC also the best configuration in terms of notifications.
• Design and navigation might vary a bit in terms of components depending on the platform (except for Flutter, which render a canvas)
• Lives on app stores or elsewhere but do not expect to skip Google Play or Apple… As we saw with the Fortnite app.
• Very long inertia from the development to the production due to the store validation process and the moment when the user downloads an update.
• In-app purchase policies are insane (from 15% to 30% on each sale) taken by store.

What should I think about before going to a Mobile App?

• Do you want to enlarge your audience and appear in app stores or are you starting a business without any presence on the web?
• Do you really care about performances and UI?
• Do you have a lot of money to fund both a web app and at least one cross-platform mobile app?
• Do you need quick hotfixes with your app? Do you have “military-grade” tests before submitting?

Generally speaking, a mobile app is a good thing especially with the new cross-platform frameworks, but always asks the customer about its need. If he is just starting its business he might be better for him to have a website first and start ranking on the search engines.

Mobile app (except in some cases) is nice when you want to reach a new audience, provide new services, and a better user experience on mobile, as you’ll design everything to fill in a small screen and only for that.

But a mobile without the usage of things like CodePush will force you to manage your release differently and you could end up managing many different versions at the same time, which can be complicated.

You also have no guarantees that people will update your app and you won’t be able to hotfix easily due to the store submission process.

The last thing but no least… if your app is crashing like hell: You have no easy way to hotfix that one or show a warning message indicating you’re working on it. And the user will probably uninstall and leave forever.

In short.

Your customer is starting its business, he needs to rank on search engine and he is doing growth hacking.

You need all three platform supports and need SEO indexation. You want cross-platform out-of-the-box.

You don’t specifically need to appear in the app stores.

You want a simple way to manage version of your app, without worrying about multiple versions, hotfixes pain, and very long inertia of deployment.

You want to sell in-app products in your app and don’t want to pay 15 to 30% margin to Apple and Google.

Mobile app

You want a fully autonomous built app with specific capabilities such as Bluetooth, best offline support.

You want to enlarge your audience, provide new services to your customers, and have the best possible experience on mobile.

You want to appears in the applications store such as the Apple app store or Google play.

You have a good budget and you can build both web version and mobile version as a separate project.

You’ll have a better user experience, at the cost to be ready to battle test your app before submission. As the deployment inertia can be a matter of days, where, on the web, it can be a matter of minutes and it’s kind of “fire and forget” on the mobile.