How to Get Your New App Built Faster (and Cheaper) Using ‘Progressive Web Apps’

You need an app! The question is… which kind?

For the last 8 years or so this has been a two-sided debate: Native vs Hybrid. Recently (i.e. 2ish years), though, this debate has heated up (I am playing it fast and loose with the term “heated up”).

Why? Because we have a newcomer on the scene: Progressive Web Apps (PWAs). They have been around for a few years, but they have been exploding recently. In fact, you probably are using some and don’t even realize it:

• https://app.starbucks.com/
• https://flipboard.com/
• https://2048game.com/ (My wife is the champion of this game)
• https://auth.uber.com/

In 2020, when our clients come to us asking for an app, we often find that a Progressive Web App is the best solution. Is it for your next app? Let’s see.

What’s all the hubbub?

Now if you are like most of my clients, you probably have no idea what a PWA even is. So let’s start at the beginning….

Like most web tech, PWAs have been around a lot longer than most people think (circa 2015 or so). PWA’s were “invented” by Google ninja Alex Russell, but they really came into the limelight when the major browsers started supporting them in 2018. Now, in 2020, they are everywhere, and they bring a lot of neat features to the table.

That is a great history lesson and all, but what is a PWA?

The easiest way to think about a PWA is that it is a website that can work offline. Whoa. What?! Yup. A PWA is a website that you can open in any modern browser on almost any device and continue to use even if you go offline. Pretty neat, right? Now, of course, you need to start online, but if you need to wander away from Wi-Fi, you can do so and come back without losing any data.

Good example: We built a PWA for a medical manufacturer who needed to inspect their equipment in hospitals. Hospital Wi-Fi is often spotty (lots of equipment, thick walls, and often older tech), so we knew that a regular web app wouldn’t cut it. They needed an app that would work across devices, even if the technician wanders into a lead-lined room that has no hope for a signal.

The PWA we developed requires you to be online when you login (at which point we download all the data we need), and then you can be on your merry way. We go on and offline, and it is completely seamless to the user. No downloads, no funny business.

How do they work?

Without going fully into Nerdville, the basics of a PWA are the following three ingredients:

• Secure Context (HTTPS): All PWA’s must come from a secure URL (the little lock in the address bar). This is non-negotiable because the browser needs to trust that the website is who it says it is.
• Service Workers: This is where the magic happens. These little robot ninjas are responsible for saving and working with the data whether they are online or off.
• Manifest File: This sounds super boring, but it is actually very cool. This little file is what tells the browser that this website can be installed on your phone. Wha? I thought you said no installing?! The cool thing about PWAs is you can visit them like a normal website or you can install them on your phone like an app. No stores required. All because of this little manifest file.

PWA vs Hybrid and Native Apps

Ok, enough geeking out. Let’s get to the reason you are here.

As I mentioned before, in earlier times the debate was only between hybrid and native apps, but now we have a third option. While we have built many apps of every flavor, we have found ourselves recommending PWAs more often in 2020. Here’s why:

Ease of Use

The biggest problem with both native and hybrid apps are the stores. Whether you are into Apple or Android, getting your employees to download and keep their apps up to date is no easy chore.

With a PWA there are no apps to install (although you can if you want to). No dealing with stores or updates. No worries about compatibility with specific devices. Just open your browser and go.

Discoverability

This is a tricky one, but worth mentioning. If you are a new consumer app, then getting Apple or Google’s attention is downright impossible. Thousands of apps are released every single day and you have no real tools to get in front.

A PWA is a website, which means that you can use all of the tools to promote your app as you would any other website (organic search, paid search, etc.).

The web is still a jungle with a billion other apps out there, but at least in this one you get a spear or something (yeah… that analogy was trash, but you get the point).

Cost

Did I mention that a PWA is just a fancy website? Sounds repetitive, but this makes a difference in cost (and developer support), too. Finding a good dev is easier when things are built with standards, which helps on both fronts.

Also… no stores! Not having to deal with the stores saves you money because you don’t have to pay your team to manage and maintain the certs, images, updates, etc. It also helps you make money since you don’t have to give the big gorillas 30% of every transaction, either.

Finally, these take the “code once deploy twice” concept that hybrid apps are known for and kick it up to eleven. Instead of deploying only to iOS and Android devices, a PWA deploys everywhere… iOS, Android, Chrome OS, Windows, and Mac. If it can run a browser, a PWA will work on it. This can save you some serious money over time.

Bottom line: the tech stack is simpler, which means that development is simpler, which saves you money. That isn’t to say that building a PWA is a cake walk. Offline support is tricky no matter how you slice it, but in the end a PWA will save you money more often than not.

Not All Roses

Just in case you think I am a shill for the PWA cartel or something… before you pull the trigger on one, ask yourself the following questions:

Do my customers want a native app?

Yes there is app fatigue, but some customers still like apps. They like going to the store and downloading shiny new things (even if they rarely use them). If your customers are into apps, then a PWA isn’t for you.

This sounds obvious, but this goes back to knowing your customers. The last thing you want is to build a PWA and find out that your customers don’t want one.

Do my customers NEED a native app?

There are lots of things that web tech can do on a modern mobile device (pictures, barcodes, geolocation, etc.), but they can’t do everything . If your app needs deep device integration, apps to communicate with each other, or you need push notifications (PWA + Push does not work on iOS because… Apple) then a hybrid/native solution will work better for your needs.

Along these same lines, do you need a lot of animations and transitions? If so, again, go hybrid or native. This isn’t the fault of the PWA specifically, but rather browsers and web tech in general. With a native app, you get to talk straight to the device. With a web app of any kind there is a layer between your app and the hardware. Practically speaking, animations can sometimes get jittery on web apps.

Bottom line: super slick animations will be much smoother on a hybrid or native app.

Are your customers primarily Apple fans?

I joke with my team that Safari is the IE 6 of 2020 because we often have to tweak our web apps to make them look good on Safari when they already look good everywhere else. The reason for this is that Safari is usually a bit behind in standard adoption.

For PWAs this means that there are some gotchas for your dev to worry about. They aren’t deal breakers, but you will need to make sure your team tests well on iOS and Macs. This becomes particularly important if your audience is mostly Apple snobs… er users.

So there ya go. PWAs for the win (mostly). All in all, I find that my clients don’t even know that PWAs exist, and when they hear about them, they get pretty excited. If their app fits into the box, then it is often a great option.