DEV Community

ITMAGINATION
ITMAGINATION

Posted on • Originally published at itmagination.com on

Creating Cross-Platform Mobile Apps. Part 1: PWAs

A phone with its home screen displayed
With Mobile Phones increasingly speeding up over the years, we have long ago reached the point when they can run regular versions of websites without a hiccup. There is, however, a clear advantage of having your clients install your apps on their phones. For one, they are always one tap away.

There are so many solutions to the problem of developing mobile apps, that we decided to go ahead and walk you through all of them one by one. The problem we will be solving is — your business wants to develop a cross-platform mobile app. What should you do?

Progressive Web Apps (PWAs)

We know, we know. They are technically not mobile apps. We will count them as such, however, because an increasing number of native APIs are available for web apps, they are installable, and run offline. We are not the only ones to think that, too. Little do people know that PWAs is what Steve Jobs envisioned for iPhone apps during his presentation in 2007. Fourteen years ago, Apple’s CEO foresaw the future.

Of course, we know how everything turned out — Apple did release an iOS SDK to develop “native” apps, with the App Store launching in 2008. The decision to initially double down on web technologies for apps was deemed a “blunder” by Forbes. Steve Jobs’ could have been seen as controversial, sure. At the time, phones were not powerful enough to do what developers envisioned using JavaScript, while the language was also not in the best shape back then.

Fourteen years is a lot of time, however, and we do definitely see that — with phones often “rocking” eight cores, six gigabytes of RAM, and capable of running demanding software. Today they are now more than ready. Apple’s legendary CEO was simply ahead of his time — it’s a shame he did not live to see his vision become reality. A little glimmer of hope was Firefox OS — a niche and discontinued operating system that had apps written in JavaScript, only.

What are the benefits of PWAs, then?

Code Reusability To The Fullest

There is often a key question — does one develop a web app or a mobile app first. The answer that PWAs provide is… why not both?

Creating apps that often share 100% of code is frequently a reality. There is simply no reason to adjust your code. You can prompt users to install your app in the same way on all platforms that Chrome runs on — Linux, Windows, macOS, Android, iOS… With one codebase.

No App Downloads

The heading might feel misleading. How can it be that there are no app downloads, if clearly, one has to download the code for the website? That is true. Your users still have to download your website. There are a few key differences in this case, however.

  • You are reducing the number of steps one has to take to install the app
  • The size of the app is much, much smaller
  • The app is easier to discover, and your users are not seeing your competition’s ads in Play Store, or App Store

Quicker Time to Market

Before your product hits the market, there are very few metrics than the expected Time-to-Market. A true blessing is the ability to cut down on it, while not compromising on the quality of your solution too much. Especially, that all your team members can focus on one goal - completing the web app.

Platform Independence

Apple to a large degree (Google to a lesser one) has a monopoly on the market of software distribution on iOS devices via App Store, and Google Play Store. There are no real solutions to sideload apps on iPhones, in an effort to make the phones have airtight security for all. Installing apps on Androids from outside the official store is much easier, though the majority of users still choose the official way of getting apps.

Companies big and small (Epic, Spotify, Basecamp, Protonmail, Deezer, OpenDataBot, and others) realized, and more than a year ago formed a “Coalition for App Fairness”. Its goal is to “advocate for freedom of choice and fair competition across the app ecosystem.”

There is a way to distribute your app, that you control, from which you can collect all the profits, and which makes your app easily discoverable. What is it? Your website. PWAs do not face as many hurdles as native apps do, which is a big win.

Easy updates

By having to run in a web browser, your apps can be updated each time your users connect to the internet whilst using them. This provides for an effortless and quick update process. You control the update policy through the cache (caching = saving your app in a temporary location for faster access) configuration. You can choose to serve your app:

  • Cache-only (not the best way)
  • Network-only (not the best way)
  • Cache falling back to the network (offline-first apps)
  • Network falling back to the cache (apps that update frequently; the process can take a bit longer in case of a patchy internet connection)
  • Cache then network (apps that update frequently; better user experience) You may see the details, and example implementations of said approaches here.

Surely, the solution has to have some downsides, right? Yes, there are.

The Cons Of Using PWAs

Slower Than Native Apps

The major reason why Steve Jobs and Apple backed away from embracing web technologies to the fullest was the lacking power. The speed was not enough. Developers had to switch to Objective-C instead.

For Android, the language of choice was Java. The approach allowed for the creation of much faster apps, and, perhaps more importantly, opened up a steady stream of money to Google, and Apple.

Even though the phones nowadays are on-par with performance with some desktop computers, native apps, or hybrid apps, are the more popular solution. One reason is the speed of execution, still. A website running on top of a browser will be slower even on the fastest of computers, anyway.

With the interfaces running smoothly at 60fps, one has to wonder whether that still is a valid reason to forgo PWAs.

Some Native APIs Still Not Built-In

Even though Chrome can: access the contact book, access the native file system, implement NFC solutions (NFC is how, e.g., contactless cards work), and, handle Bluetooth connections;

there are still numerous things it cannot do. Thanks to Project Fugu, the list of things that web developers cannot do is getting smaller, and smaller, luckily.

Nevertheless, sometimes, developers have to pick up native SDKs to be able to solve their problems.

People Are Not Used To Installing Apps In-Browser

One “Law of User Experience” says that:

Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know.
In practice, this applies to the way you want users to install your app as well. If the majority of your competitors, or even companies that operate in an entirely different sector, have their apps working differently than yours, your users can be a bit confused.

This is the biggest obstacle that companies have to face before fully embracing the web-first approach. There is no obvious solution to the problem, either.

When should I decide on PWAs?

Startups have to be the biggest beneficiaries of Google’s attempt to make all significant native APIs usable through Chrome. Should you have a relatively small software development team, you will be the happiest. The same applies when your app will be rapidly updated; there is simply no way to update the apps faster than by creating a PWA.

Top comments (0)