Not an IPhone user: but honesty I'd rather have things open an actual browser tab, as then I can interact with it via all my standard extensions (e.g. adblockers), rather than be opened in a webview.
Also, given how often you need to change phones (given build quality), if I have important data and you're a web app, I rather the server be the source of truth, and the phone a cache (so I don't loose data when the phone breaks).
With Firefox Mobile on Android, you can confiure webviews to open as Firefox webviews as well, and my extensions seem to be running because I don't see ads there. They're still webviews of course, you don't get the tabs, bookmarks etc. Just webviews with extension support.
There used to be an option to redirect the Custom Tabs API to just open a regular Firefox tab. I loved that option as it replaced a reduced functionality API with the full thing. Too bad it got lost in the great fenix rewrite.
That's what I do as well, but still sometimes it's chrome that opens, and so a "always really open an actual browser, never a webview" would be preferrable (and more recognisable when preferences are ignored.
Web apps are mostly optional and otherwise work as a normal web site. Differences are that some functions are exclusive to web apps, so you wouldn't get them on a web site anyway. A feature I do find annoying is the ability to save a page onto my (Android) phone screen is taken away and replaced by "install app". I work around that by going into airplane mode, fetching the page unsuccessfully, and saving that!
The point is that with EU mandating alt-browsers on iOS, it should have been a possibility to have "Installed" (home-)PWAs where the engine is the alt-browser, not safari/webview.
Those browsers could have implemented the Home-PWA functionality while maintaining your ability to install plugins such as adblockers within that PWA's context.
Apple has made this impossible by removing the OS APIs that allowed "Installed" (home-)PWAs entirely. This is just so they aren't forced to allow these under a different browser engine.
Of course, this is all done because "think of the children" (i.e.: think of the poor people ticked into using a non-privacy-respecting browser to run their PWAs).
I prefer websites to apps too. That way the server takes care of storing the data and you don't have to worry about backups.
Still i will never buy apple products again because of their anti open stances. The last product i had from them was an iphone 4.
That is at some level a distinction without a difference (and I have implemented PWAs, and tried to get them to work on mobile, including offline for significant periods of time). I've found (as a user) that most webview based apps (including those in the mobile stores) that I've used as a user tend to be held together with bits of string, and that running them in an actual browser tends to work better except in the case where there's literally no internet (i.e. for flaky internet browser beats wrapped pwa).
these are not inherent problems to PWAs tho. The data loss situation is pretty much the same for any native app. They can choose to be local only or sync to a server. Apple can also support iCloud for PWAs in theory.
Also there is nothing stopping extensions to work for PWAs. They do on Chrome desktop and you can disable/enable extensions per app. Not an Android user (yet) so I don't know how is it on mobile.
I’d like to quickly address the second paragraph. From my experience, iPhones last until their software support runs out, barring any accidents. Furthermore, PWAs need not be offline applications (so TFA overblows the data loss potential ever so slightly) but often work exactly like you want them to.
I use the Outlook PWA. It’s great because I don’t have to let my company manage (part of) my phone.
Sure, caches make sense, and are where PWAs are a legitimate solution. But PWAs also are sold as a replacement for native apps (hint: they're not, but a whole bunch of native apps should be PWAs, or just static sites...), and the author of TFA does subscribe to that view.
But they can replace a lot of native apps. Calendar, Notes, Weather, Maps (to an extent), Reminders, Calculator, $CellProviderApp, Stocks, Cloud Drive (Apple, Google, Microsoft, …, to an extent), Translator, Mail, various Messengers, Youtube, Amazon, various public transport ticket apps, EV status apps, parcel tracking apps, …
I’m only on home screen 2 of 5 and oh my, it’s almost all of the apps. Granted, some would perform worse in some ways. Some could not realize all features (like automatic photo upload). More integration (like sharing to PWAs) would be needed. But some others? Yeah. Why even develop an app?
Sure, and a bunch of those are already on the web, though it depends what you're trying to do e.g. mail could just be a view of an existing service (in which case it's just making the existing interface mobile friendly), or it could be an actual client (using IMAP/SMTP), in which case it should be native, rather than having some weird intermediary (which if you want to to do IMAP/SMTP via the web, you need to do). Personally, I'd rather native apps with well defined interfaces that use well defined standards (e.g. IMAP/SMTP/ical), rather than some hacked together web version. But people like reinventing wheels...
Also, given how often you need to change phones (given build quality), if I have important data and you're a web app, I rather the server be the source of truth, and the phone a cache (so I don't loose data when the phone breaks).