Intro
We're talking about Progressive Web Applications (PWAs), a hot topic in today's developer community. Many are just realizing what is it, and some have been developing it for a while as it's been slowly gaining a reputation.
For many companies today, finding the right starting point for a new application takes time and careful planning, and often the question is "where do we start?" PWAs are worth considering for many businesses, and will likely become the web standard in the near future. To begin, we need to know what a PWA is. After that, we can understand its relevance in today's shifting tech landscape.
What is a PWA?
A PWA could be described simply as "apps for the web". It is a website disguised as an app without being stuck in the browser. For the developer, this approach reduces the number of architectural headaches in app development.
PWA is a brand for the modern web with a set of standards for creating native app-like experiences.
The developer uses the browser to deliver an application, but to the end user, it's just an app. The progressive part of this is the on-going engagement from browser with the end user as they continue to use the application. Engagement could look like asking the end user if they'd like to install the wen app locally without the need for the browser.
While this is true for the end user, PWAs can be thought of as more than one thing: it's a brand for the modern web, and it's also a movement for creating native app experiences that are installed on devices similarly to native apps.
From a technical perspective, it's a set of standards defining information about the app, where and how it launches, with what themes, and a service worker handling network connection. Information about the app comes from a web manifest and can specify where the app launches and its UI, and the service worker can handle a number of tasks including enabling offline capabilities for an app.
Whether as a brand, a movement, or a technical standard, all of these parts come together to create an experience that's indistinguishable from native apps.
What is a service worker?
For PWAs, "installing" an app isn't like your typical install. In fact, you're not actually installing anything. It's a combination of adding an icon to your systems desktop or screen while performing route navigations like typing a url in a web browser.
The things that control how the app handles network traffic events is the Service Worker. It's like a proxy that exists between your app and the network. For example, while process network traffic, the app could stop and do something else as a side effect- performing other network calls, fetching more assets, etc- and serving them back to the user. Before there were service workers, there was app cache, but it didn't keep the app synced.
Service worker can be extended to do other things as well. It's a process that's not running all the time. If the app is idle, the service worker shuts down after a few seconds of inactivity, but it can launch very quickly. For instance, if a user isn't in the app, but a notification comes in, that will trigger the service worker, perform any checks, and show the notification bringing the user back into the app.
Workbox is a tool that helps with groups of service worker tasks, background syncing, and app refresh, helping developers avoid the pitfalls building these patterns from scratch.
One thing to note as a common pitfall of implementing a service worker from scratch, is a PWA opened with multiple tabs. Since the service worker is attached to each instance of the app (that is, every tab that's opened), you have multiples of the same service workers running, so you would have to account for that scenario.
Why are PWAs important today?
Technologies like HTML5 spec, CSS3, geolocation, just to name a few, help establish the idea for the modern web. But where these tehcnologies failed to meet a company's needs, a new "brand" must step in to take its place. This new brand helps companies re-engaged with the web in an attempt to rebuild trust with the web.
What PWAs bring to the table is a new way of defining how the modern web works, how it's used by the end user, and how companies re-engage with the web under a newer, better brand.
Buy-in from a company is a huge factor in an apps success. While some companies can look at examples of great apps, and decide that that experience is, or what they would like, does the web provide all the features needed to succeed now and in the future? Company buy-in is often based in future successes, whether or not today's technology will meet that goal, or if competitors buy into another technology.
Any company can choose a product for mobile development, like Flutter, and potentially lose business. Regaining trust in the web also involves comapanies being aware of available features, and roadmapping what technologies that company needs. Some of the trust has been lost in the work because you don't know if technologies will keep up.
Where are we now with PWAs?
One can say that we're in an early Renaissance. We are just now starting to get the capabilities that we need to be able to build real apps using web tech. However, the awareness for what's available or in development is lacking.
So how can we build awareness while we're still in development in the modern web? Build cool stuff with the technology we have available to show off what's possible!
Every big company has at least three dev teams, which is detrimental from a business cost perspective, and they're all building the same experience with three different technologies - web, Android, and iOS. Yet, many apps don't need all those variants.
PWAs are a great cost-effective strategy for companies to consolidate web, Android, and iOS apps into one.
Additionally, for the end user, they may get a great web expereince, but end up with a poor native mobile app experience. The different sets of work required to make the other experiecnes (Android and iOS) consistent results in wasted effort, especially if the app doesn't work, leaving the user to run back to their laptop, only to see that the web version works as expected.
With PWAs, you minimize the cost to create the same product for different platforms because it works independently of the operating system- one of the greatest advantages for PWAs. Companies can begin to develop for a single application with a consistent experience.
Caveats for developing PWAs
Today, Apple's Safari browser is impacting the web because it doesn't offer the same features as other browsers- which is ok for them to do- but they restrict other apps on their devices as well.
Chrome, and any other browser, on iOS devices, is simply a wrapper for Webkit. They're not different browser engines, so they lack the capabilites that other browsers already have. This doesn't mean that we can't built experiences for iOS users that are progressively enhanced as those capabilities become available. What it means for the end user and developer is that the web on this browser will eventually become irrelevant, and both parties will have to move on because they aren't met where they are.
Perception is another factor that can hinder progress as well. In the case of Apple products, Apple users may not be aware of what's missing unless they're looking for specific features. A user might need a specific feature that a certain set of hardware can't provide.
How do we advance web standards?
A side note for those who've experienced roadblocks from unavailable features: it helps to complain or submit requests, even repeatedly, for features to arrive. Big company names will stand out among all of the requests for features on webkit.
How can we make the switch to PWAs?
Regardless of whether or not a company has a released product, here are a few things to keep in mind for implementing PWAs today:
Use HTTPS
Websites must be served over HTTPS. Where many APIs can be split and accessed from different domains, all new APIs should come from a single domain or origin, keeping with the good security models for the web.
Take for instance a user who clicks a link an it directs them to another domain. That might take them out of your PWA. So you should, in theory, only have one origin.
Configure service worker for offline mode
Requirements for a service worker have now changed to include offline capailities. It used to be that you just need to have a service worker: it was good to go. Now, you need to have some kind of offline experience.
We're moving towards having an offline experience, but it's still in progress. For now, service workers should provide a page or notification to the user that they're offline.
Have a manifest for the app
Lastly, have a web manifest, typically in JSON, where you describe your app. The manifest determines how the app launches and with what themes.
Does versioning matter with PWAs?
When it comes to version control, PWAs have the advantage of already being installed. Because they're already installed, you can provide a couple ways to get the user onto the latest version.
One solution is to provide an opt-in strategy, or update on navigation, but another is a true analogous experience. This can be accomplished during the first time somebody opens the app, immediately showing them content while in the background, prepare newer content, or experiences.
Part of that is achieved by caching assets locally. Then next time when the app boots up, if it already has a service worker installed, it begins serving from the cache immediately. The way the model can be built or designed is to immediately show the old experience on launch, and then perform updates in the background that are prepared for the next launch.
Deciding the best approach doesn't come without its pitfalls too. There is a chance of locking a user into an older experience if a rollout strategy isn't implemented correctly. Ultimately, whatever strategy makes the most sense to a business is the correct approach.
There are tools for helping with version management, like WordBox, which helps with pre-cache assets.
Keeping the app experience consistent
App consistency is key to a successful PWA. Unfortunately, there are limitations with them on iOS devices, but with Android devices, there's no telling the difference.
Frameworks, like Ionic, the closest to the desired web solutions for distribution, are marketing for usage in PWAs. They have capacitor, a tool for getting an app into a native package, and into the app store quickly. However, that brings up a concern about awareness for PWAs that isn't the standard download from an OS's app store.
To keep awareness up for new apps as PWAs, developers take advantage of Google's offerings for wrapping their websites to be displayed in the Google Play store. The same rules of the app store still apply as the do for other apps. There are other services being worked on for assisting app store launch like Cordova.
App distribution channels
Software distribution is hard. Fundamentally, it's one of the more difficult problems as a developer in general. The web model for publishing new versions of a PWA stays intact. It's as simple as pushing your code to a new server, with some of the work, as part of that effort, goes to generating a service worker that has information about that built.
It extremely easy to throw a webpage on the internet, and that's really all that needs to be done while having additional amazing web capabilities. Standard app distribution is difficult because there's all the code form for the specific platforms- signing and buying validation certificates, for example. This is the reason that PWAs are so important and valuable. Best of all, updates can be published at any time. Apps aren't stuck in a review queue, companies aren't losing business, and no middle entity is standing between the company and the user.
What makes a successful PWA?
Just like any web application, a successful PWA is one that users want, and that works seamlessly between desktop and mobile experiences. Think about what the user is doing, and how they might use an app. That will often guide the design and experience.
Over-designing experiences for different platforms becomes a headache when you consider the different platforms and dedicated launguages you have to work with. As in Swift for Apple, you're restricted to what the platform allows, but a PWA opens up the ability to design consistanly across devices. A button remains the same button it was as described in the manifest, and because it all comes from a single code source, there aren't multiple configurations needed.
Implement what you need
In thinking about what the user is doing, enabling features that aren't needed or not providing features that work similarly to most common native app experiences, will prove an unsuccessful app for the end users.
If web capabilites don't exist that an app absolutely needs to succeed, these features that aren't ready can always be enabled when they are.
Lower the bar to entry
Make it easy for a user to access an app. If a user is on a Starbucks line and sees a notice for a rewards program, but they don't have the app installed, it wouldn't be effective for the user to download the app and have to wait for the download to finish. Once the download is finished, they'd still have to login, whereas, the website remembers their credentials. Companies spend so much money trying to figure out how to get a user to download an app, but the conversions happen when products are made easily accessible.
Consistent app experience
A successful PWA means that users shouldn't be made aware of differing experiences from a native app to PWA. On that line of thought, the thing that should be different is the security. Again, users shouldn't be able to tell the difference here, but there are differences between native apps and PWAs regarding authentication.
In the browser, we can take advantage of Cors to secure a site over https. In native apps though, you can just hit the network without asking for security. This means that PWAs, with a good authentication path, are more secured right away, and without extra configuration.
For native apps, the default strategy was to make sure it's safe, and then run the app, but the web default says that it's probably not safe, so let's make sure that the browser protects the user as much as possible.
Conclusion
PWAs' benefits far outweigh any arguments against them. They are a great cost effective strategy for minimizing codebases across web and mobile platforms. What we've seen, so far, only scratches the surface on what we can do with the web, and there's so much more on the horizon that's being released.
Thanks to my guests Kenneth Rhodes, Adriana Salazar, and Henrik Joreteg for their thoughts and experience on PWAs, and for helping to build up awareness in the community with the work.
