Should you build a PWA for your business?

Should you build a PWA for your business ?

How to make your decision ?

PWA are a new way to build applications. They are faster to build and ship, work cross platforms and cost less to develop. Given the times we are in, this may be worth considering if you have an app project.

If you are in a position to make a decision in your organisation, this article is for you. There is as few technical jargon as possible.

Let’s imagine this potential app. What would be the channels to distribute it?

Distribution / installation

The core concept of a Progressive Web App is that it’s built with web technologies : HTML, CSS and Javascript. These apps are executed inside a browser.

This is also why you can “instant install” such an app. It’s very light weight, compared to a “native app”.

The browser already provides the runtime, ie the “program box” in which the app wil run. This means that the amount of code which needs to be downloaded by the user is very low (2 to 5 MB) compared to a native app that needs to package the whole thing (several 100 of Mb).

And because you run it with a browser, it’s naturaly cross platform. A PWA will run on desktop and on mobile. Any operating system with a browser is good to go: Android, Mac OS, iOS, Windows, Linux

If you’re going to ship an app, how will you put it in the hands of your user. What will be your distribution channel ?

Distribution

Distribution can be as simple as turning your website into a PWA and offer to your visitors the option to install it.

Does your project imply a brand new app? At the most basic level just provide a link to your users.

You do not need an app store to distribute a PWA. When time is of the essence, not depending on being validated by a store to ship an app can make the difference between success and failure.

I speak from experience.
When you want to ship a tool for your employees or for your users, you don’t want to be dependent on a decision made outside your organisation. As a bonus, this makes updating your app a quasi-transparent operation: as seamless as pushing a few changes to your website.

Nevertheless, you may want to be listed in an app store. What are your options in that case?
Well, some providers have embrassed the PWA cause and some have not. The main players:

  • Windows store: automatic submission via Bing crawler or manual submission 1
  • Samsung Galaxy Store: manual submission 2
  • Google Play : publish your PWA as an APK 3 –a packaged app.
    Alternatively you can use PWA builder to submit to Google Play 4
  • Apple store: that’s a hard nope. Apple made a U-turn about Web App and decided they don’t want these in their App Store.

Another option to consider: get listed in one of the specialised PWA stores, which basically are a listing of links to PWAs. At the moment this is an opportunity because these places are not overcrowded yet. These 2 stores below seam to be the best at the moment:
https://appsco.pe/
https://progressiveapp.store/pwas

Enterprise distribution:

What if you are building a business tool for your employees?

Apple lets you generate a Web Clip with Apple configurator 5. You can then distribute it by email, on a web page or using a Mobile Device Management server.

On Windows platform, you can deploy a Web App over Group Policies 6

On other platforms, if you’re distributing a business app inside your company, the easiest way is to send a link with instruction by email.

User Experience

Performance first

A PWA shines in constrast with native app because it’s lightweight, fast and you don’t need to install it to start using it. If the user chooses to do so it feels instantaneaous.

Be aware, though, that if you build a PWA for both desktop and mobile, you may need to adapt for both layouts.
Alternatively you could choose to restrict the body width to narrow width only.

If your app is intended for consumers, the look & feel may be of importance to convey the branding. Just think that it’s CSS & HTML. It’s versatile enough to create a good UX. Especially if your user need to do data entry. HTML provides natively all the controls you may need.
At the end of the day, it all depends on the type of app you are building.
Does your user need to execute a task and be done with it as fast as possible and then close and forget the app ? You’re good to go with a PWA. PWA are fast.
Some good use cases are e-commerce, finance app, reporting app, business tools.

Do you want to provide “delight” and “slick animations”. Your goal is for the user to spend as much time as possible inside your app ? You’ll always struggle to replicate “native” feels.

Now, most of the use cases for apps are task oriented. And the average Jane can’t even notice if what’s displayed on her screen is native or not. All she wants to do is: buy the thing, report the fact and be done with it.
She wants an UI that is clear, usable and let her do what she needs. So you wouldn’t spend a lot of time agonizing over the perfect nuance of layout. In this domain, performance will beat any other matter.

Sometimes, your app needs access to some low level hardware feature. What have we got inside a browser? A lot, actually.

Access to platform APIs

This is where we’re heading into 2 very different regions :
Android Google, Windows, Samsung and other smartphone builders are pushing hard and fast to give access to a lot of features in their platform.
On the other side of the frontier stands Apple who jealously guards its closed realm in the name of user privacy.
That given, what do we count on for sure, on all platform?
And what depends on the platform ?

What you can expect for sure:

  • Service workers : that’s the foundation of PWAs
  • Local Storage, indexedDB: you can store a lot in indexedDB
  • Access to camera, audio. iOS finally fixed a bug, now you have access to userMedia in standalone mode
  • Geolocation. Have been there for 10 years, at least. But only when app is running. (no geolocation when the app is in background)
  • Payment API. Meaning in-app purchases :)
  • Authentication
  • Offline use

What depends on the platforms:

  • Names ^^. For all platform, PWA is the name. Except for Apple which does not want this appellation and call them “Home Screen App”
  • Installation: Android will prompt the user to install the app on homescreen. iOS will not. There is a workaround with a Web Component7
  • Installed mode / standalone local storage:
    Android share the same storage space for both installed app and browser app.
    iOS will not share any local storage from Home Screen App and app running in Safari. This makes the “install” more convoluted if you need to authenticate your user. But on the bright side, the Home Screen App is not tied to cookie management from Safari and private browsing mode. First party cookies will work no matter the choice of the user.
  • Push notification, background sync, background update:
    Android , Windows Edge, Opera, Samsung
  • Background update: Android, Opera, Samsung
    Apple is not planning on implementing these in the foreseable future. The only exception being push notification for Mac only and with a proprietary implementation.
  • Bluetooth, filesystem read/write: Android , Windows Edge, Opera, Samsung
  • NFC, access to contacts, text and barcode detector: Android only under feature flag

A good place to check for all new capabilities: whatwebcando.today (it’s a PWA, of course :) and https://tomayac.github.io/pwa-feature-detector/

If you’re building an app for your company, there is a good chance that you manage a devices fleet. It’s a good time to think about the features you want and check if the devices can align with the project.

Keep in mind that since you’re using the browser as the “program box”, you get the benefit of always having an up-to-date runtime. Even an old smartphone will run the latest version of the browser. With a difference with iOS that ties the version of Safari to the version of iOS.

Just so you know, my development device is a Nexus 4 which runs Android 5.

Offline / Sync

Due to service worker, PWAs do work offline, almost by default. You’ll want, obviously, your service worker to provide for the case.

Want to know more about service workers? See my next article.
To be notified when it’s published, tweet this: PWAS are faster to build and ship, work cross platforms and cost less to develop

If your user can do stuff offline, can she then sync her work with cloud services, or your own back-end? Of course, she can.

Sure, Android/Chrome will give you an easy way with a sync event that will trigger in the background when your user is back online.
No such event exists on iOS. Some possible workarounds would be to try a sync action each time your user access the app, or offer a UI action to manually trigger the sync.
Anyway, I think that no matter the platform, it’s a good design pattern to give your user a way to trigger a sync by herself as a fallback action when having the data backed up is important.

Performance

Let’s not loose sight that PWA are performant and should stay that way.
You should always have performance in view first : the less code the app has to download, parse and execute, the faster it’ll be.
All the PWAs that I’ve built were only HTML, CSS and vanilla Javascript.

Tech Stack / framework

You don’t really need a framework. See “Performance” above.
I read a lot of articles that firmly state that a good PWA is a SPA.

Let me respectfully disagree –along with Alex Russel with all my force and experience:
You might consider going for an MPA + SW architecture until you’ve confirmed that session depth is very deep (think > 10 clicks on average), otherwise the cost of SPA framework JS may not be paid back in terms of user experience.
—Alex Russel

Since the service worker will intercept every navigation from the browser, this will give you basically a router for free.
Said service worker will serve any page directly from the cache storage if you tell it to do so.
Why add a bunch of boilerplate code when all you need is a collection of interactives pages? In the same view, you want to defer managing the app state for as long as you can.

Most of use cases boil down to “enter some data, add some media like photos / audio, store it for later use and submit to service or sync it with a server”.
There is a very slim chance that you’re building an email client or the next FB. Staying lean, shipping as few code as possible will lower the number of bugs, hard corner cases and test scenarios.

Then, PWA or not PWA?

As a recap, you may consider going the PWA route if one or more of these points are true:
  • you want to ship fast
  • you do not have a big budget to spend on development
  • you want to control the distribution of your app
  • your app is task oriented
  • cross platform is mandatory and you have a tight set of requirements
  • you control the devices where the app will run

I host an Office Hour on building PWA. If you have any questions, consider yourself invited. Just head over here to claim your spot.

Footnotes
  1. 1 Progressive Web Apps in the Microsoft Store
  2. 1 https://medium.com/samsung-internet-dev/introducing-progressive-web-apps-to-samsung-galaxy-store-47ecd317725b
  3. 1 https://developers.google.com/web/android/trusted-web-activity\
  4. 1 https://www.davrous.com/2020/02/07/publishing-your-pwa-in-the-play-store-in-a-couple-of-minutes-using-pwa-builder/
  5. 1 Configuring Multiple Devices Using Profiles, Profile-Specific Payload Keys: Web, profile for configuring web clips on the device
  6. 1 how to use Group Policy to automatically distribute programs to client computers or users
  7. 1 Web Component from the PWABuilder team for an ‘install’ experience