The important point is that how OSs should (with user consent) grant installed PWAs access to system APIs like notifications. I'm just trying to condemn Apple's preferential treatment of native apps in this regard.
I totally agree that PWAs count as apps and are eligible for end-to-end encryption (as long as they don't dynamically run code coming directly from a server). I don't know exactly the story on iOS though, I just know that I like "native apps" better then PWAs, but that's a preference.
> I'm just trying to condemn Apple's preferential treatment of native apps
Are they actively working against PWAs, or are they refusing to spend resources supporting another technology? I could understand that they don't want to go out of their way to add new "features" they don't care about.
What difference does it make? I'm hardly surprised that they won't dedicate engineering resources to tech that threatens their bottom line. But it is a choice, and it's to the detriment of their users and I. For that, it deserves criticism.
I think it makes a difference.
To find other examples, I don't find it unacceptable that Samsung doesn't try to support GrapheneOS on their phones, even though it would benefit their users and I. Or that Google doesn't support misp for Android. Because I like RISC-V does not mean that Microsoft should be forced to support RISC-V. And because I like Erlang does not mean that Linux should accept Erlang contributions into the kernel.
I don't find it unacceptable that Apple doesn't work on supporting Asahi Linux. But I would find it unacceptable if they added some kind of hardware attestation that would prevent it from running.
It's the difference between "I will not help you do what you want" and "I will block you from doing what you want".