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 issue we will be solving is — your business wants to develop a cross-platform mobile app. What should you do? Of course, you may seek a software development partner, though what options do you have, should you decide to develop an app yourself?
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.
There is frequently 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 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.
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.
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.
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 respectively. 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.
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:
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 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 even the web interfaces running smoothly at 60fps, one has to wonder whether that still is a valid reason to forgo PWAs.
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.
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.
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.