loading...

What's the benefit of us maintaining our Progressive Web Apps (PWA) of DEV?

lisasy profile image Lisa Sy ・1 min read

I put this document together to organize all of the platforms we're responsible for. We currently maintain at least 6 platforms for DEV:

  1. Native iOS
  2. Native Android
  3. Mobile Site
  4. Desktop Site
  5. Mobile Progressive Web App (PWA)
  6. Desktop PWA

our platforms

I recognize the utter importance of delivering an excellent experience on both mobile & desktop site (an obvious no-brainer), as well as our native apps. I want to open up the floor for conversation around the benefits and costs of
maintaining our PWAs
:

  1. Why did we support PWAs in the first place?
  2. What do we gain from maintaining PWA, especially on mobile, where we already have a native mobile version of our app?
  3. What are the costs of maintaining PWA?

Discussion

pic
Editor guide
 

Overview

There's a big overlap in all of them as they're not fully contained and separate from one another. I'll reference the 6 supported platforms by their numbers:

Service Workers (SWs) enhance performance for 3 & 4 and support a custom offline page for a better web experience. I think this is a good part of what it takes to support PWAs (platforms 5 & 6), so by supporting these features we're close to PWA level. The caveat of 5 is that Apple isn't welcoming to a good chunk of PWA tech (hasn't been and hard to believe it will change in the near future).

Note: This does not mean that PWA == SWs though, some good reads:

Because we've been pushing for a WebView approach on the native mobile apps (1 & 2) we also benefit from both the enhanced performance and the custom offline page from SWs. The most notable caveat is the reduced support in iOS, but some mobile native features are what gives both platform 1 & 2 their selling point IMO.

To answer the questions:

  1. Without having context of the exact reasoning (at the time that it was implemented) I think it made sense. It gives an enhanced experience for people that don't want to install a native app. More favorable for Android compared to iOS though.
  2. Support for users that don't want to install a native app at a low maintenance cost (most maintenance overlaps with what would take to support Mobile & Desktop Site)
  3. Some edge cases come into play, the most notable I can remember is the Share feature that we want to enhance with native capabilities gets trickier to support for platforms 2/3/5/6. I don't think it's a big overall cost.
 

The PWA is the website. It makes the site faster and better even if the user doesn't want to download an app.

I think the fact that any forem can have a near native experience out the box is a massive sell. I use the PWA on my android phone (I wouldn't want the full app as I feel I'd gain nothing) but on the desktop I just navigate to the site.

I think PWAs are the future and more and more people will tend to use them it's good that forem is showing how to do this well already.

Summary

  1. PWAs make a better web experience for all users.
  2. A PWA is more lightweight than an app and will just work, even if you update your code base.
  3. The costs are negligible if you're aiming for a good web experience anyway.
 

I agree with your point of view @link2twenty , my other comment echoes most of what you mention here. The only thing I may feel differently is:

I wouldn't want the full app as I feel I'd gain nothing

It's totally understandable as PWAs have great support on Android. Native Push Notifications, enhanced background audio playback (for Podcasts) and a native video player are available for native app users, but of course it may not be reason enough for everyone to prefer native > PWA.

There's plenty of potential to exploit from the native standpoint just as there is on PWA. It's actually great to hear your experience with the PWA has been a good one 😃

 

In my view the qualities that make something "eligible" as a PWA are probably more important than being a PWA in the first place. As PWA may or may not become a "thing", but the things that qualify a site to be a PWA are basically:

  • Fast
  • Works in offline scenarios
  • Accessible, and generally good UX.

The details that allow you to call an app a PWA are pretty minimal outside of the eligibility requirements I'd say we should maintain.

Our browser extension switcher works especially well because we load the app super quickly with service workers (which are technically a requirement for PWA to be fast + offline mode)....