Some people wonder why Apple/Safari/WebKit folks often refer to “Web Apps”, “Home Screen Web Apps”, “Installed Web Apps” or similar terms, instead of “Progressive Web Apps” or PWAs. There’s a couple of reasons:
1. We like to reflect language that appears in the UI when possible.
@othermaciej
I see PWA as more of a technology strategy term than a term that describes a particular application or set of APIs. Kind of like "web technologies".
As a tech strategy it is ever evolving and will always be a bit ambiguous.
IMO there needs to be *a* term that means "choosing the installable web-application route with all kinds of app-like APIs", when people consider this vs. Flutter / ReactNative / Swift+Kotlin. I don't really mind if it's PWA or a different term...
It's important because when we talk about e.g. PWA support in a particular browser, we talk about whether the browser supports PWAs *as a technology choice for building apps*, and this includes a set of solutions that evolves over time, based on user and developer needs.
@nomster I recognize the term has value for some people. The creator apparently intended it to be a marketing buzzword (along the lines of “Web 2.0” perhaps). Which seems similar to your notion of a term for a technology strategy. Still, I think our reasons for choosing to rarely use it hold up. We are mostly talking to users and developers, not CTOs or CIOs.
@othermaciej I was recently talking to an indie dev who was considering whether to use Flutter or to go the PWA route, and I found the term helpful. Indie developers are often their own CTOs (and CIOs), and choosing a "tech strategy" can make or break their future.
I wouldn't dismiss conversations with them as being a hype thing. Separating "developer" from "CTO" is missing something - a coherent story around helping devs succeed with a web-based approach to apps (call them what you will).
@nomster Maybe this points to a difference in emphasis. We’re not specifically looking to persuade devs to build apps with web stuff over any other technology or framework. We want to make sure that, if they do choose to build something web-based, they have the tools to deliver a great user experience, and it’s not too hard to do so. We’d like the same to be true of UIKit, SwiftUI, Flutter, React Native, Xamarin, etc.
@othermaciej Sounds good!
If the sentiment ("make sure that, if they do choose to build something web-based, they have the tools to deliver a great user experience") is there, the terminology is less important IMO.