Progressive web versus native apps: a war, or just wagging the dog?

To understand the state of the web in 2018, you need to go back more than twenty years, to 1996, the year the movie Space Jam was released. If you’re not familiar with this basketball-stars-and-cartoon-characters-but-in-space movie, it goes like this: a bunch of aliens steal the Looney Tunes cartoon characters and then Michael Jordan gets sucked into a golf hole, and there’s some basketball and then – victory for Earth! No one is sure why the movie was successful, just as no one is exactly sure why the website for the movie is still around.  

The important thing is, at some point during production, a website was created, one that did just about everything the web was capable of doing in 1996. And it’s still around.  

Backwards compatibility 

The Space Jam website has iframes and a table-based layout. It’s as 1996 as a pair of overalls with one strap down. It couldn’t survive without our thirst for cringeworthy pop culture nostalgia, but it’s also a reminder of what’s so special about how the web was built. As the web evolves, it’s up to browser vendors to ensure backwards compatibility.  In other words, when a browser vendor prepares a new version for release, they adhere to a rigorous process that ensures they don’t break anything that’s already there.  

One recent example is what’s known among developers as SmooshGate. Two developers wanted to add a ‘flatten’ function to a JavaScript language itself, but the term ‘flatten’ already existed in an old library called MooTools. Using the term in the new library would have disrupted sites still running MooTools. One (joke) suggestion made was to rename the new function ‘smoosh’, as a synonym for ‘flatten’. Not-breaking-the-internet is centrally important to web developers, but that doesn’t mean it’s always easy.   

Space Jam is an artefact of just how dedicated web developers are to backwards compatibility. Whatever you do, don’t break ‘Planet B-Ball.’  

What’s a progressive web app? 

In short, a progressive web app is just a great website that looks and behaves like an app, but the user can access it on the web. You still usually ‘download’ it, but it’s usually incremental, and much smaller. It’s also ‘progressively enhanced’, which means it provides a modern, up-to-date experience on a new device, sometimes with enhanced features, but will also still work on older devices. With native apps, developers sometimes build fallbacks to allow functionality with older operating systems, but progressive web apps do this by design.  

They’re designed to be reliable, fast, and engaging. It’s more than this, of course, and Google has a checklist for what you need to qualify as having built a progressive web app. But a true example of one represents best practices for websites and applications — because that’s what they’re designed around.  

The advantages of progressive web apps 

It’s not that it’s never time to build a native app, but because building native is often so much more expensive, it’s just useful, as a rule, to assume something can be built for the web – until it can’t. It used to be the case that it was harder to create good user experiences for mobile web, but that’s not the case anymore. In fact, companies like Twitter and Tinder have created progressive web app versions of their products.  

Progressive web apps are, in general: 

• More discoverable: Users can find the service in a Google search, and skip the app store step 
• Less tied to app stores: There’s a lot more business model freedom when you don’t need to go through approval processes. App stores do provide some credibility, but if you’re building a service people want, you’ll be able to build that in another way 
• Universally compatible: They work even on poor connections, offline environments, and on crummy devices. This is especially helpful if your user base isn’t on the latest iPhone 
• Always fresh: Users don’t have to update it, developers do
• Backwards-compatible: They’ll still work in 20 years, when our current interfaces are mostly a cute piece of web history – and native apps mostly won’t work at all
• Cost-effective: If you don’t need a native app, then don’t develop twice.  

They’re also not the end-all, be-all of digital services. Despite what a lot of inflammatory articles would have you think, web developers aren’t trying to kill off native apps.  

When do you build native? 

It’s important to remember that what you’re building is a service for customers, not an app for a platform. The mobile web can do a good job of that in more circumstances than it could in the early years of smartphones, but sometimes native apps are the right choice. 

As a general rule: 

• Native apps can be made more secure: This includes geofencing, which can’t currently be done with progressive web apps 
• You can do more hardware-intensive work: if you need to use things like cryptographic hardware, a native app is your only good option here 
• If you need push notifications, you need native: For now, you can’t send push messages from web apps to iOS devices (you can send them to Android) 
• Apps can interact more easily: It’s easier to interact with other apps if you build native
• App Store processes can lend credibility: For some applications, in markets where there’s trust of companies like Google and Apple it’s helpful to have jumped through some hoops to launch 

Always be user-centred 

The question isn’t whether you should build web or native, but what your users need and want. When you’ve done your research, and you know what users expect of the service you’re building, you can start going through what’s actually needed for these users in particular. You can use a site like What Web Can Do Today to check your users’ needs against what progressive web apps can do. 

• Do you really need push notifications or can you send them by SMS?  
• What other hardware is involved?
• Will this be used in a market that has connectivity issues, expensive data, or older phones with capabilities that are restricted to apps (for example, the camera on an older Android can’t be used with web apps)?
• What are the privacy concerns?  
• Are the users in a market that is less trusting of big platform tech companies (in which case they might want a web app to access a service directly) 

Your users don’t want an app of any kind 

In fact, they probably don’t even ‘want’ your organisation. They want the service you provide for them. If you’re focused on what they need, what they care about, and the environment they’re in, then you’ll build the right thing. But nobody is looking at their device thinking, “What this thing needs is another app.” 

It’s true that a lot of what is currently done by native apps can be done by progressive web apps. And there are misconceptions about the mobile web – that it can’t deliver good user experience, that users universally trust native apps more – that need correcting. But there is no war, and nobody is trying to kill off native.  

That said, the web is still beautiful, useful, and it remains usable, no matter what version of browser it was built for. And if the Space Jam website had been a native app, it wouldn’t be around to remind us that once upon a time, we used a ridiculous thing called iframes.