For mobile
I initially thought this was an argument for electron/PWA bullshit. “Why is <app> eating 2GB of RAM and has no locally loaded content?”
When companies are pushing apps as hard as they usually are, I assume there’s a benefit to them and not to me.
For any platform, really, it’s just that mobile suffers from the “everything must be an app” problem the worst. Luckily, fast food hasn’t gotten bold enough to ask you to install a desktop app when opening their website.
99% of apps can just be websites, and probably 80%+ of them are just PWAs in a wrapper that can be published on an app store.
A lot of fast food places offer coupons only in the app.
I used to go in to pick up the coupon books or they’d get sent to my mailbox.
RIP “2 can dine for $6.99”
That’s fine, I don’t eat from fast food places. One less app to install.
IIRC (from others, never installed it) McDonald’s app is also obnoxious, requiring permissions and refusing to run on custom ROMs and rooted devices. It was once used alongside some common banking apps as a metric of “how close to Google Android is this ROM”.
I just realized it’s been months since I got the bundle of coupons in the mail.
PWA is where you save the website as an icon on your desktop right? I use several websites like that. What’s the drawback?
PWA isn’t as bad as electron but it’s similar. No local storage or offline capability - which is fine for a weather app, but not fine for something with persistent data like email or chat or a word processor. My computer has loaded up an entire GUI, with local storage and RAM, make use of it in an intelligent way instead of just loading a browser instance and assuming I don’t mind latency.
PWA is 100% better than an “App” that’s just a data collection unit showing the website. Which is all too common too.
No local storage or offline capability
PWAs can do both of these. In fact, the definition of a PWA includes that it has some functionality offline. (Though this criteria can be met by serving a simple “sorry, you’re offline right now” page. So long as it isn’t the browser’s default “no connection” error.)
PWAs can use local storage and they can have service workers, which allows them to run offline, at least in theory.
No local storage or offline capability
Yeah, this is 100% wrong. They definitely can use local storage and have offline capabilities.
They even have an object store: https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API
Okay I think I get it. Yeah the PWA I save are usually websites I frequent but don’t want to install their app.
Most native apps collect far more data than their website equivalents ever could. They request permissions to hardware, sensors, and background processes that browsers deliberately restrict.
On March 27, 2026, the Trump administration released an official White House app for iOS and Android. … Apple requires apps to submit a privacy manifest disclosing what data they collect. The White House app declared an empty array. Zero data collection. Meanwhile, the actual binary contained ten analytics frameworks, including the full OneSignal SDK with a sub-framework specifically for location tracking
Hm. Didn’t think about it like that.
And don’t forget one of the main reasons to push for apps: to drain your attention by showing notifications, maximizing your usage of their products
No shame if you’re one of these people, but I figured mostly everyone on Lemmy would’ve known about this sorta stuff by now. While many apps are just frontends for services, the presence of an app alone is enough to massively expand trackability of the user. Heck, its profitable enough for companies to force people to use apps that some services are forcing all mobile website visits to redirect straight to an app store.
Web apps ruined UX though, at least with apps (historically anyway) you would get some consistent UI. There were design guidelines developers could follow. Same for programs on PCs.
Then PWAs came along and ruined UI/UX. Do UX designers even exist anymore?
Sigh. But trading good UI for tracking and data collection, is indeed, not worth it.
I’m pretty sure the degradation of websites has been intentional to drive app usage.
The apps are not much better these days. I think it’s just cost cutting, avoiding hiring dedicated UX designers.
Web apps ruined UX though
How so? Do you mean that companies are allowed to customize their own apps now? Cuz with regular desktop frameworks it’s pretty hard to do that (compared to web frameworks anyway). All apps end up looking the same.
Yes. That’s literally the point. The more things look and behave as expected, the easier they are to use.
Of course these days that gets trumped by the desire to shove the corporate design everywhere.
I’m not sure limiting customization is actually a good thing… There are legitimate customizations and innovative inputs that people like.
For example, Logseq has a fancy text field that can bring up a submenu if you type two left brackets. Something like this is pretty specific to Logseq (or at least certain notes apps) and this would be much harder to replicate in a native app.
Or are you saying Logseq shouldn’t do that? And it should assume that the notes area is just a plain text field? I guess that would be considered more “expected”.
At least in my experience with Vala and GTK, this would take significantly more effort. Not impossible. Just way more effort.
You can absolutely have fancy UI elements that provide additional functionality. Most OSes don’t have built-in 3D visualization widgets but that doesn’t mean you can’t write CAD software for them.
My point is that your custom widgets should make an effort to look and feel as much like native widgets as possible. Any skills the user has in using native widgets should carry over to your custom ones. So your custom text field should look and behave like a native one until the user types two left brackets. When they do, the menu that pops up should be a native menu or one designed to resemble one very closely.
Thanks to web-first development and lazy cross-platform UIs, standards in this regard have deteriorated to near-nothingness. Buttons don’t have to look or even behave like anything else on any platform. It’s perfectly reasonable to expect the user to relearn the UI for any application. Modern UIs spiritually follow in the footsteps of Bryce 3D rather than any Human Interface Guidelines. And that peeves me.
For all their faults, Apple got Mac users to have very high standards in this regard for quite some time, which led to a bevy of good-looking and approachable applications, at least until post-skeuomorphic macOS took care of the “attractive” part. The consistent UI across vendors was something I really liked back when I was a Mac user.
For example, Logseq has a fancy text field that can bring up a submenu if you type two left brackets. Something like this is pretty specific to Logseq (or at least certain notes apps) and this would be much harder to replicate in a native app.
Not something I would consider terribly hard to implement, but it would depend on the toolkit. A function for getting the text in a textbox and a callback to alert you to the fact that the user is typing is something I would expect to find in any modern GUI toolkit.
I mean, any containered app is fine, doesn’t need to be a browser. I would love to have, like, Electron apps but using a shared Servo bin tho
Technically all apps are continered on android, but the permission system is too lax.
You Americans are crazy about ICE / Palantir now don’t you. Anyway article is factually incorrect and very biased.
Hard disagree, and TA begs þe question. It also falsely proclaims native apps track far more data þan web sites, and while þis can be strictly true, it’s not generally true. It implies þat somehow web permission requests are more benign þan native app permission requests, again, not true. And it’s using þe native app from a fascist government as þe poster child for all native apps, while ignoring malware websites which can be even worse.
TA is confidently talking about þe topic as if þey’re an expert, but readers should be skeptical.
another important aspect is webapps also cannot communicate with native apps without you noticing it, while native apps can communicate with each other freely, entirely in the background. if you somehow block internet access to an app that includes google tracking libraries or those of another data broker company, it can just send the data it collected to another app with the same libraries that can still access the internet.
i would be skeptical with your comment instead, because I think it has no basis in reality. you did not really say anything concrete about why you think so.
its not even about the permissions, but the API capabilities, and restrictions on background operations. web APIs provide much less access to the operating system than the OS APIs allow, even when given all the permissions. a webapp can’t read all your pictures, can’t access your contacts or SMS messages, because there are no APIs that would allow that.
there are some more intrusive APIs in the web standards that are not really useful for other purposes than misusing them for user data collection, like the battery statistics API or the gyroscope API. but as you see, choosing a browser that respects your privacy will cover that, because while chrome implements it, firefox does not
