Maciej Stachowiak 🇺🇸🇵🇱❤️🇺🇦 @othermaciej@qoto.org

@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.

@jayphen Seems like a bug to me! We support a related concept of how screen bookmarks (for sites that don’t support running as a standalone web app) but Twitter installs as a real web app.

@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.

@mackuba Yeah, it's confusing to users and even to many devs. Some people get mad if we don't use exactly this term, but if that's the cost of clarity, so be it.

We’re not mad at other people using the term and will use it when helpful, but this is why we usually use different terminology depending on context.

Contrast Web Components: this really is a clear and well defined cluster. There’s no debate or fuzziness as to whether specific specs are part of Web Components or not.

3. PWA in reference to a suite of technologies is amorphous and has no clear referent. Some technologies are almost always considered part of the core PWA set: Service Workers, Web Manifest, Notifications API, Push API (and related protocols). But other things may be considered PWA, Fugu, or just normal web technologies, depending on the day of the week. We don’t find such an amorphous grouping to be a useful way to think about web technologies.

2. When we intend to refer to installed web apps, the term “PWA” is ambiguous. Sometimes it refers to web apps that _can_ be installed, other times web apps that _have_ been installed. When we’re talking about different capabilities or extra behavior, we generally only mean web apps that have actually been installed, so we try to be more specific.

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.

Some anecdotal evidence that people use Add to Home Screen on iOS more than we might think, even with the indirect UI. Another reason it’s important to make the Web App experience great.

https://blog.mozilla.org/ux/2023/02/people-do-use-add-to-home-screen/

When it takes a week for someone to find a reason something good is bad actually... could it be their anger is purely performative?

@hi_mayank @jensimmons if you mean as a user - there is a Safari setting for that (and in any other WebKit-based browser that cares to expose the setting).

@naton I see. Unfortunately, server-side web development is beyond my expertise, so not sure how much I can help. There are general tutorials out there for how to set up Web Push and send a push notification from the server. We don’t have WebKit-specific docs beyond that.

@abhibeckert @ffScala @siracusa I believe it’s after 30 days, and specifically days of Safari use during which you didn’t visit the website. The clock resets in a site visit. But it’s correct that Home Screen web apps are uncapped.

@naton essentially it works the same as in other browsers. We found most websites that supported Push for other browsers just worked, as long as they didn’t have a hardcoded user agent lockout.

@ffScala I know people who use Elk saved to home screen as a Mastodon client on iOS instead of the various native options. It's not super duper popular, but maybe more so with this feature?