When we started building Superwave, we knew we needed validation of our vision for community, from community people, as soon as possible. Given our time and resource constraints, there was no doubt that we were going to start by building for the web browser.
As that vision has come to life in the browser, those community people that have come along for the ride have asked us for something new - the ability to reach their members on any of their devices, with branded apps and push notifications.
Often the answer to this request would be to build ‘native’ apps - one app for iOS, one app for Android. But there are costs to this approach.
We’re a small team, and native apps typically require a team each for web, iOS, Android and desktop. Coordination between those teams slows down the pace of delivery. And a separate app needs to be built for each and every community.
The result is that branded community apps usually cost 10’s of thousands of dollars.
Enter the PWA 🦸
In the search for a different answer, a few weeks ago our team started kicking around the idea of Progressive Web Apps (PWAs). PWAs allow you to build a single app that works across multiple platforms (web, desktop, iOS, Android).
Since the Superwave experience is already the same within both desktop and mobile browsers, how amazing would it be if we could continue to deliver at our current pace, but have PWAs supercharge communities by providing a native-like user experience, at a fraction of the cost?
In the post that follows, we’ll outline our technical approach to building a PWA in its simplest form to bring a powerful, inexpensive branded app experience to our communities.
Generating the manifest 📜
Each community on Superwave lives on its own subdomain; `community-a.superwave.app`, `community-b.superwave.app`, etc. With PWAs, each community will need to generate its own `manifest.json` describing the metadata for the specific community. A browser will look at this configuration file and figure out how to display the app.
In Superwave’s case, we leverage Next.js’s API routes to dynamically generate a community manifest on the fly.
Generating icons 🖼️
With the manifest set, visitors of the site can “install” the site onto their device home screen, for both desktop and mobile. We go one step further and generate icon images based on the community’s icon, again leveraging Next.js API routes.
We use `@next/og` under the hood to dynamically generate the various sizes for these icons – it’s typically used for social/open graph images but hey, it works well here too!
Chrome and Android have the lovely ability to read from a list of `screenshots` defined in the manifest to display a sheet UI, giving extra insight as to what a user will be installing onto their device – in our first version, we simply display the custom banner set by the community. You can imagine app preview screens like you would in an app store in the future.
Push notifications 🔔
Each Superwave community encourages members to opt into receiving in-app notifications as well as push notifications. When looking into how we were going to implement push notifications, we recalled that Safari earlier this year announced their support for web push notifications, catching up to the other major browsers 🎉. Apart from some UX differences between browsers, push notifications can be enabled on both desktop and mobile devices.
We use Google FCM specifically for push notifications support (it’s free!) – we create a simple wrapper around the API to help us handle browser support and user settings.
Into the PWA future 🔮
It feels like we’re riding a PWA wave that’s beginning to swell (Ryan Hoover certainly thinks so). PWAs ultimately enable you to bring value to customers, more quickly, on more platforms, than building native apps. And that’s a wave we want to be on.
In a following post, we’ll deep dive into the implementation details of FCM – for now, you can request access to Superwave, and our PWA, here.
