Progressive Web Apps versus native is the wrong question because every step on the path to a Progressive Web App makes sense on its own, irrespective of what a company does with their native apps.
Not all of your customers are going to have your app installed. For those who visit via the web, providing them with a better experience will make them happier and generate more revenue for your business.
It’s really that simple.
A nice introduction to progressive web apps. There’s a little bit of confusion about permissions—whether a site has been added to the home screen or not has no effect on the permissions granted to it (for things like push notifications)—but the wrap-up nails the advantages of using the web:
No more waiting to download an app, no more prompts for updating an app. From a developer perspective, it means we will be able to iterate a lot quicker. We don’t need to wait for app store approvals anymore, and we can deploy at our own leisure.
Another advantage that a progressive web app has over a native mobile app is that it is linkable, hence it is easier to share and, probably even more importantly, can be indexed by search engines. This makes discoverability of the app a lot better.
Alex runs through the features that a progressive web app must have, should have, and would be nice to have.
In general, installability criteria are tightening. Today’s Good-To-Haves may become part of tomorrow’s baseline. The opposite is unlikely because at least one major browser has made a strong commitment to tightening up the rules for installability.
Right now, this is in the nice-to-have category:
Mobile-friendly, not mobile-only.
Personally, I’d put that in the must-have category, and not just for progressive web apps.
Anyway, read on for some advice on testing and tooling when it comes to evaluating progressive web apps.
How Google And Others Are Plotting The Revenge Of The Web App | Fast Company | Business + Innovation
It’s always, um …”interesting” when a mainstream publication covers a topic from the web’s bikeshed. In this case, it’s progressive web apps, and—apart from the sensationalist headline—it’s actually not that bad at all.
This is a really good overview of progressive web apps:
An ideal web app is a web page that has the best aspects of both the web and native apps. It should be fast and quick to interact with, fit the device’s viewport, remain usable offline and be able to have an icon on the home screen.
At the same time, it must not sacrifice the things that make the web great, such as the ability to link deep into the app and to use URLs to enable sharing of content. Like the web, it should work well across platforms and not focus solely on mobile. It should behave just as well on a desktop computer as in other form factors, lest we risk having another era of unresponsive m.example.com websites.
Andrew picks out his favourite bits from this year’s Google I/O, covering web payments, CSS containment, and—of course—Service Workers and progressive web apps, although he does note (and I concur):
I wish Google would focus as much attention on ‘normal’ sites that perform navigations as they do on so called ‘app-shell’ (which is just a new name for single-page apps, as far as I can tell), but then many people will be building SPAs and these recipes will make those apps fly. In news publishing we seem to flip flop between traditional page navigations and SPAs, but I’ve never found a SPA news site (or a native app) that I really like more than a normal website. Maybe a really good progressive web app will change that. But I’m not convinced.
Still, as he says:
All this really just underscores how flexible ServiceWorker is and that with it we can disagree on what the right solution is, but we can all get what we want anyway.
Jason looks at the business reasons for and against building progressive web apps. In short, there’s everything to gain and nothing to lose.
Seriously, why would you not add a Service Worker and a manifest file to your site? (assuming you’re already on HTTPS)
The roadmap for progressive web apps from Microsoft; not just their support plans, but also some ideas for distribution.
I really, really like what Ember is aiming for here:
That’s how you get the holy grail of resilience and performance:
Subsequent visits and interactions are therefore nearly instantaneous, because they don’t rely on the network.
I sincerely hope other frameworks are paying attention to this layered approach.
Oh, and I also like this observation:
There’s an age-old argument about the difference between “web pages” and “web apps”. In reality, there’s a continuum between the two.
Colin pointed out this interesting perspective from an iOS developer moving to the web:
My work for the last few years has been on the web, and honestly, it’s a breath of fresh air. Instant refreshing, surprisingly good debugging / perf tools, intrinsically multi-platform, and most importantly, open.
Web tech gets a lot of shit from native devs (some of it deserved). But the alternatives are worse. I find the entire concept of App Review morally questionable despite Apple’s good intentions. So I sleep better at night not being part of that anymore. Sure, the web is messy, and it’s delicate, but it’s important and good and getting better fast.
Cameron looks back on his 2007 Mobile Web Design book:
I don’t anticipate native apps will die off anytime soon. But I’m warming to the idea that they may be less relevant to the future of the web, and I reaffirm that “a browser will be — or should be — sufficient for interacting with web content.”
Progressive web apps are poised to be remarkably relevant to the future of the web. Let’s not screw it up.
If you’re going to make a manifest file for an existing site, start with this very handy tool. You give it the URL of your site and it then parses the content for existing metadata to create a best first stab at a manifest JSON file.
A good impartial overview of progressive web apps, as described at the most recent Google I/O. This is very telling:
The term also begs the question; what is the difference between websites and apps? It seems many of the new capabilities fit well for any dynamic website, not just apps.
Anyhow. It’s good to have an umbrella term to talk about these things.
Google have asked me to moderate a panel on the second day of this event in Amsterdam dedicated to progressive web apps. Very brave of them, considering some of my recent posts.
Progressive web apps – let’s not repeat the errors from the beginning of responsive web design | justmarkup
Those who cannot remember the past are doomed to repeat it:
When people learned about responsive design, there were many wrong assumptions. The iPhone and early Android phones all had the same screen size (320x480px) and people thought it is a good idea to change the design based on these device-specific sizes.
We wouldn’t do that now, right? We wouldn’t attempt to create something that’s supposed to be a progressive web app, only to make it device-specific, right?
We are still at the beginning of learning about the best ways to build Progressive Web Apps. I hope it will make many more people aware of progressive enhancement. I hope that nobody makes the error again and concentrates on the device part.
Smart thinking from Alex on how browsers could better indicate that a website is a progressive web app (and would therefore benefit from being added to the home screen). Ambient badging, he calls it.
Wouldn’t it be great if there were a button in the URL bar that appeared whenever you landed on a PWA that you could always tap to save it to your homescreen? A button that showed up in the top-level UI only when on a PWA? Something that didn’t require digging through menus and guessing about “is this thing going to work well when launched from the homescreen?”
I agree with everything Andrew says here. Progressive web apps are great, but as long as Google heap praise on mobile-only solutions (like the Washington Post doorslam) and also encourage separate AMP sites, they’re doing a great disservice to the web.
More features arrive regularly to make this “one web” even better and easier to maintain. Service worker, streams, app manifests, payment request, to name a few. But adding these features one at a time to large, mature applications like WaPo or FT or Nikkei is a slow and painstaking process. That’s why it’s taking us a long time for us to tick off all these new features, and why it seems like madness to try and build the entire app several times over.
However, by creating the concept of PWAs and marketing them as they do, Google is encouraging publishers to ‘start again’. And they’re doing exactly the same thing with AMP.
In the web developer community’s collective drive to be more App Like and compete with native apps we may lose or weaken some of the web’s strongest features and we need to consider carefully before we throw away urls or the entire browser chrome in an effort to look like and behave like the cool kids of native.
So remember when I was talking about “the ends justify the means” being used for unwise short-term decisions? Here’s a classic example. Chris thinks that Progressive Web Apps should be made mobile-only (at least to start with …something something something the future):
For now, PWAs need to be the solution for the next mobile users.
End users deserve to have an amazing, form-factor specific experience.
I couldn’t disagree more. End users deserve to have an amazing experience no matter the form-factor of their device.
I’ve been poking around at Google’s information on “instant apps” since they announced it at Google I/O. My initial impressions mirror Peter’s.
Either they allow access to more device APIs (which could be a massive security hole) or else they’re more or less websites.
While many challenges remain, the good news is … it’s progressive. Developers can already see the benefits by sprinkling in these technologies to their existing websites and proceed to build on them as browsers and operating systems increase support.
Remy sums up the psychological end goal of progressive apps (HTTPS + Service Worker + manifest JSON file) prompting an add to home screen action:
This high bar of entry will create a new mental model for our users.
If I add this app to my home screen, it will work when I open it.
It’s a shame that this charge to turbo-boast the perception of the web on mobile is a bit one-sided: I would love to see Apple follow Google’s lead here. But if Android succeed in their goal, then I think iOS will have to follow suit just to compete.
A fascinating slice of ethnographic research in Myanmar by Craig. There’s no mention of the web, which is certainly alarming, but then again, that’s not the focus of the research.
Interestingly, while Facebook is all omnipresent and dominant, nobody is using it the way that Facebook wants: all the accounts are basically “fake”.
What I found fascinating are the ways that people have found to bypass app stores. They’re basically being treated as damage and routed ‘round. So while native apps are universal, app stores would appear to be a first world problem.
Now if there were only some kind of universally accessible distribution channel that didn’t require any kind of installation step …hmmm.
A response to a rant I linked to recently.
I couldn’t agree more. The tools have evolved and we now have frameworks and practices that allow us to render from the server and use the same code to render on the client, progressively enhancing from a solid robust base.
The problem is that I don’t see a willingness from developers to embrace this way of thinking. Instead I see it dismissed as being unrealistic or more expensive.
Still, it always takes time for behaviour to change so maybe things will only get better. I certainly hope so.
I really, really want to like this article—it’s chock full of confirmation bias for me. But it’s so badly-written …I mean like, just the worst.
Here’s an actual sentence:
So with a capable, HTML-based platform and a well-designed program that makes good use of CSS, one site could support phones, tablets, PCs, and just about anything else with one site.
So, yeah, I’m still linking to it, but instead of it being for the content, it’s because I want to lament the dreadful state of technology writing.
A hands-on look at building a progressive web app with Service Workers, manifest files, HTTPS, and all that good stuff. This is nice and balanced, extolling the virtues but also warning about the potential difficulties in implementing this stuff.
One nitpick though: there’s talk of graceful degradation, and while I get that that’s the outcome, I think it’s better to think in terms of progressive enhancement, which is the approach.
Following on from that last link, here’s an in-depth run-down of what you can do in mobile browsers today. I think a lot of people internalised “what you can’t do on the web” a while back—it’s well worth periodically revisiting the feature landscape to revise that ever-shrinking list.
Perhaps the biggest advantage the web has over native apps is how quickly users are able to engage. All that’s between the user and your content is one click.
Bruce gives a great run-down of what’s involved in creating one of those new-fangled progressive apps that everyone at Google and Opera (and soon, Mozilla) are talking about: a secure connection, a service worker, and a manifest file.
Crucially, in browsers that don’t support it, you have a normal website. It’s perfect progressive enhancement.
Funnily enough, this here website—adactio.com—is technically a progressive app now.
At their simplest, Progressive Web Apps are application-like things hosted on your web server. If you’re as old as me, you might call them “web sites”
Outlining the architectural thinking required to create what the Google devrel folks are calling progressive apps.
Browsers without service worker support should always be served a fall-back experience. In our demo, we fall back to basic static server-side rendering…
…but this is only one of many options.
Hmmm. In my opinion, sending usable HTML on first request isn’t an implementation detail—it’s crucial. But on the whole, this approach is very sensible indeed.
Why Atavist is betting on the web. See also:
It’s not about technology, performance and APIs – it’s about people.
Apps must run on specific platforms for specific devices. The app space, while large, isn’t universal.
Websites can be viewed by anyone with a web browser.
And that doesn’t mean foregoing modern features:
A web browser must only understand HTML. Further, newer HTML (like HTML 5) is still supported because the browser is built to ignore HTML it doesn’t understand. As a result, my site can run on the oldest browsers all the way to the newest ones. Got Lynx? No problem. You’ll still be able to find matches nearby. Got the latest smartphone and plentiful data? It’ll work there, too, and take advantage of its features.
This is why progressive enhancement is so powerful.
My site will take advantage of newer technologies like geolocation and local storage. However, the service will not be dependent on them.
Sensible words from Christian.
Web applications don’t follow new rules.
And frameworks will not help:
A lot of them are not really fixing fundamental problems of the web. What they do is add developer convenience. … This would be totally OK, if we were honest about it.
But as people spend more time on their mobile devices and in their apps, their Internet has taken a step backward, becoming more isolated, more disorganized and ultimately harder to use — more like the web before search engines.
This page does a great job of explaining Mozilla’s thinking behind “pinned apps”—an idea that would be great for the whole web, not just Firefox users.
The Web Manifest spec is still very much in draft, but it’s worth reading through Bruce’s explanation of it now. Basically, it will provide a way for us to specify in one external file what we currently have to specify in umpteen meta tags and link elements.
An astute comparison of the early years of the web with the early years of the app store. If there’s anything to this, then the most interesting native apps are yet to come. App Store 2.0?
With the usual caveat that I wish this were published on Craig’s own site, I particularly like this passage:
Apps, too, are ephemeral. Some of the most ephemeral software we’ve ever produced. Ephemeral if for no other reason than because of their gated homes. Our apps cower below the fickle whim of App Store Gods, struck down for no reasonable reasons or for very reasonable reasons. It doesn’t matter which, the end result is always the same: gone, forever.
I, for one, don’t welcome our applinks overlords.
So, you’re checking out your news feed on your Facebook app and you see a CNN post that you want to read. After reading the post on CNN, you decide you want to to read the source article on TMZ…
John echoes some of my recent thinking about what qualifies as a web browser and, by extension, what qualifies as the web:
We shouldn’t think of “the web” as only what renders in web browsers. We should think of the web as anything transmitted using HTTP and HTTPS. Apps and websites are peers, not competitors. They’re all just clients to the same services.
That said, I think he is perhaps underestimating the power of URLs. Addressability—particularly over an extended time period—remains the powerful feature of the web.
Some excellent research from Chris, canvassing opinions on whether there’s a difference between web “apps” and web “sites”. His conclusion:
Almost none of the points above ring true for me. All I see are exceptions and gray area.
If nothing else, the fact that none of the proposed distinctions agree with one another show how pointless the phrase “web app” is—if people have completely differing ideas on what a phrase means, it is completely useless in furthering discussion …the very definition of a buzzword.
This leads me to think perhaps the “web app” moniker (certainly the newer of the two) is simply just a fashionable term. We like the sound of it, so we use it, regardless if it truly means anything.
But all of this is, I think, missing the more important point: why? Why would you want to separate the cornucopia of the web into two simplistic buckets? What purpose does it serve? That’s the question that really needs be answered.
If we could pin down a super accurate definition that we agreed on, even then it might not be particularly useful. And since we can’t, I argue it’s even less useful.
Coming from anyone else, this glorious vision might seem far-fetched, but Anne is working to make it a reality.
Dan Bricklin—co-creator of the original VisiCalc spreadsheet—turns his attention to responsive design, specifically for input-centric tasks.
Scott gives us an excellent State Of The Web address, looking at how the web can be central to the coming age of ubiquitous computing. He rightly skips through the imitation of native apps and gets down to the potential of just-in-time interactions.
This a great proposal: well-researched and explained, it tackles the tricky subject of balancing security and access to native APIs.
Far too many ideas around installable websites focus on imitating native behaviour in a cargo-cult kind of way, whereas this acknowledges addressability (with URLs) as a killer feature of the web …a beautiful baby that we definitely don’t want to throw out with the bathwater.
Dan is collecting all of those product demo videos aimed squarely at young white single males with iPhones.
I share Tom’s frustration with news apps that should be websites:
I wouldn’t download a BBC app or an NPR app for my computer. Why would I want one on my phone?
Why mobile Web accessibility matters - best practices to make your mobile site accessible | mobiForge
There’s some great practical advice for building accessible mobile web apps here.
This post is ten years old, but I think it might still be the best attempt to demarcate a difference between web “sites” and web “apps”: think of them as stories and tools.
It’s also remarkably prescient about the need for an effort exactly like HTML5:
A widely-distributed, standards-compliant, browser and platform-independent library of functions that would perform the basic user interface functions for a web-based tool, relying on the server side only for the logic and data sourcing.
This is kinda funny (because it’s kinda true).
Taking apps out of phones and embedding them in the world around us …there’s a lot of crossover with what Scott Jenson has been writing about here. Good stuff.
Some future-friendly musings on mobile from Mozilla and Yahoo.
Brent Simmons follows up on that Dave Winer post with some future-friendly thoughts:
If I had to choose one or the other — if I had some crazy power but I had to wipe out either native apps or web apps — I’d wipe out native apps. (While somehow excluding browsers, text editors, outliners, web servers, and all those apps we need to make web apps.)
That’s not the case, though. Nothing has to get wiped out.
The great thing about the web is linking. I don’t care how ugly it looks and how pretty your app is, if I can’t link in and out of your world, it’s not even close to a replacement for the web. It would be as silly as saying that you don’t need oceans because you have a bathtub.
An excellent point from Jonathan: both native apps and web apps require an internet connection …and both native apps and web apps can be made to work without an internet connection.
This might sound obvious, but the myth that “only native apps can work without an internet connection” is surprisingly widespread.
A real-world anecdote from Jonathan illustrates some of the misconceptions around using HTML instead of going native. A lot of people don’t realise that web apps can store data offline.
An excellent article that examines the supposed benefits of publishing through someone else’s app store instead of the web.
Scott writes up some of the things he talked about at the Breaking Development conference: the just-in-time interactions that are inevitable in a heavily-instrumented world.
A quick overview and explanation of web intents.
It’s a provocative title but I certainly agree with this post’s premise. And the situation it describes is all too familiar.
I agree with this. I like it. I plus one it. So to speak.
A beautifully readable subset of the HTML spec, with an emphasis on writing web apps (and with information intended for browser makers has been removed). Very handy indeed!
John Allsopp calls bullshit on the notion that native apps are intrinsically better than web apps. I concur.
Here's a little piece of web history: the proposal that was presented and rejected at the 2004 W3C workshop that led to the formation of the WHATWG.
I'll be sitting in judgement on the entries to this neat competition which harks back to the good ol' days of 5k.org.
A nice collection of free apps for your mobile device. No app store required, thanks to offline storage.
PPK proposes a new buzzword for standards-based mobile development: HTML5 Apps. Definition: "an iPhone app that works on several other platforms, too, and doesn’t have to go through the app store approval process."
PPK offers a rebuttal to Paul Graham's attack on Apple's App Store policies by placing the blame firmly at the feet of developers who refuse to embrace web technologies.
This sounds like Yahoo's answer to Facebook Platform for single web pages or (spit!) widgets. We'll see if the reality matches the hype. "The Yahoo! Application Platform allows you to build and launch open-social applications to the largest daily â€¦
David Recordon shares his first impressions of Google App Engine.
Looks like Apple are trying to redefine the term "web app" to mean sites created for the iPhone. The revisionism is completely barefaced.
The first public alpha release of Apollo is out. Grab the runtime and then play around with some of the sample apps (none of which are that impressive but it's the thought that counts).
I used to think that Mike Arrington was a dick. Now I know he is.
The Future of Web Apps gets a write-up on the BBC site.
Danah Boyd's talk at ETech 2006.
The W3C proves that it can move with the times: "The mission of the W3C Web API Working Group is to develop specifications that enable improved client-side application development on the Web." This is very good news indeed.
CNET's News.com explains why web services are so cool.