[adamwk]

This doesn’t really make sense. Apps were pretty popular immediately after decades of web usage. There are many reasons to prefer an app. Even on desktop; if I’m using a service enough throughout the day, I want a native app, not a website.

[johnecheck]

There are many reasons to prefer an app, most of which are ways OS makers have crippled web apps for reasons that TOTALLY HAVE NOTHING TO DO with the fact that they get a 30% cut if the user chooses the native app.

[palata]

This is wrong. The most important reasons why I prefer mobile apps are the same as why I prefer desktop programs.

- I can download it once and then use it.

- I can see when it gets updated (versus a website that gets updated every time I load it). For security reasons it's better, I can even verify my app with other people online and make sure we run the same thing.

- End-to-end encryption doesn't make much sense in a webpage, because I fundamentally have to trust the server (which serves me the whole app I run every time). If you care about end-to-end encryption, you want an app.

- For open source apps, I can audit the code, possibly edit it, and use it. I cannot do that with a webpage.

- I exclusively use free apps, so 30% of zero is... zero.

[SebastianKra]

1. You can download & install PWAs for offline use too.

2. This isn't true for apps anymore. Server driven ui is a thing.

3. JS runs locally. You can inspect the network traffic more easily than you can with an app.

4. You can audit OSS websites too.

5. Your personal preferences have nothing to do with the fact that Apple makes tons of money from apps but not websites.

[palata]

1. If you do it like this, then I count it as a mobile app, not a webapp. A webapp loads in the browser. We're not debating programming language here, if you run Rust in your browser via WASM it's still loading in the browser.

2. Wut?

3. The network traffic of an end-to-end encrypted app is... encrypted traffic to the server you don't trust.

4. Not sure if it's bad faith or not, you conveniently drop the other ideas: can you fork a website and use it against the original service? And again, if you audit the sources and then load the website, you have no idea if you are running those sources or not. Or if you will next time you hit "refresh".

5. Granted, they make a ton of money for apps. My solution to that is to force them to allow third-party stores.

[the456gamer]

1. PWAs load in the browser too

2. many apps are also just webviews, and dynamically load updates from servers out of your control, whether you want it to or not.

3. I suspect they were referring to certificate pinning, but I'm unsure. I don't think the e2e encryption argument really holds up, as you have to trust the app vendor too.

4. Its always possible to do it, for personal use: at worst case, you will need to host an api proxy on a custom domain, so you can have different CORS headers. However, for open source PWAs, its possible customization would be officially supported (and/or hosting backend instances yourself), so you could use it as-is.

5. not hobbling PWAs would be nice

[palata]

> 1. PWAs load in the browser too

I keep getting that kind of answers, and it just tells me that people just don't get my one point about end-to-end encryption...

> I don't think the e2e encryption argument really holds up, as you have to trust the app vendor too.

... and that shows a misunderstanding of end-to-end encryption again.

It does not matter whether it is coded in Javascript or not. What matters is how it works. If it sends the data in plaintext, it's not proper end-to-end encryption. If it sends the data weakly encrypted in such a way that it is trivial to decrypt, it is not proper end-to-end encryption. If it fundamentally dynamically executes code coming from the server whenever it wants, then it defeats the point of end-to-end encryption.

That means that for end-to-end encryption to work well, you have a bunch of constraints.

- The Signal client app is a good example: it's open source and it is distributed in such a way that you can reasonably trust it (i.e. it's reasonable to believe that Signal and Google are not colluding to attack you personally, and if you believe they do you can reasonably compare that you run the same app as someone else). This all makes it very difficult for Signal and Google to attack it.

- Anything that dynamically loads Javascript from the server and runs it is a poor fit for end-to-end encryption. Whether it loads in the browser (like web.whatsapp.com) or does something dynamic that allows the server to modify the code you run this one time and without leaving a trace, it does not matter. The fact is that everything that you load in the browser works like this, so a simple rule is that everything that you load in the browser is a poor fit for end-to-end encryption. Then of course because it is an app does not mean it is a good app, but that was never my point.

[johnecheck]

> If you do it like this, then I count it as a mobile app, not a webapp.

This is pretty funny distinction to make. It's hardly a surprise you find web apps inferior if you define them so.

Whether through a store or browser, your computer is downloading code from the internet and executing it. A browser adds cross-platform ease for devs and a sandbox for security at a slight performance cost. A store adds gatekeeping (for better or worse) and a 30% tax. The other differences are UX choices from browser makers and OS designers, nothing more.

[palata]

> This is pretty funny distinction to make

Is it? Wikipedia says: "A web application (or web app) is application software that is created with web technologies and runs via a web browser."

> It's hardly a surprise you find web apps inferior if you define them so.

Then I guess we agree :-).

> A browser adds cross-platform ease for devs and a sandbox for security at a slight performance cost.

Mobile apps also run in a sandbox. But a sandbox does not magically remove all security concerns.

My point about security was regarding end-to-end encryption. If you don't trust the server, then the model where you dynamically execute whatever the server sends you every time you use the app is fundamentally a problem. I assume it is the reason why you cannot run Signal in the browser even though they distribute an ElectronJS desktop app (I believe it's ElectronJS?).

> A store adds gatekeeping (for better or worse) and a 30% tax.

Sure, but that's not all of it. A store adds a third-party intermediary:

- If Signal wants you specifically to run a modified version of their client that will leak your key to the Signal owners, they have to get Google to serve you a different version of their app, and hope that you don't compare it with someone else (which you can trivially do with an app). In other words they have to collude, and if you really care you may well realise it.

- If Google wants you specifically to run a modified version of Signal that will leak your key to Google, they have to make the Signal Foundation sign their modified build, otherwise your phone will refuse to install the update. They also have to hope that you don't compare it with someone else. In other words they have to collude, and if you care you may well realise it.

- If ProtonMail wants you specifically to run a modified version of their web client that will leak your key to Proton, they can just serve a different version of the client this one time only, just for you. They don't have to collude with anyone else, AND there is absolutely no reasonable way for you to realise it.

It's not "UX choices", it's the difference between "reasonable end-to-end encryption" and "having to trust the server".

[63stack]

This is only true if you are using apps that require no communication with a server. Otherwise it's constant forced updates, and basing security on the version number of the installed app is a moot point since you can't guarantee the server will send the same replies to 2 different users.

I can't parse the part about e2e not making sense for webpages.

[palata]

> This is only true if you are using apps that require no communication with a server

End-to-end encryption is all about going through an untrusted server. You don't need end-to-end encryption otherwise.

> Otherwise it's constant forced updates

There are apps that allow you to verify that you are running the same signed binary as others. Think key transparency but for apps. It's trivial to do.

> basing security on the version number of the installed app

Obviously you don't base your security on the version number of the installed app?!

> since you can't guarantee the server will send the same replies to 2 different users

With a website, you cannot. When you open protonmail.com in your browser, you don't know if you are running the same code as I am when I do the same.

With a mobile app, you can. You get a signed binary, it's trivial to compare. Also even if you don't check that, if you get the Signal app through the Google Play Store, it means that the app is signed by Signal but distributed by Google. They have to collude in order to have you get a different binary.

> I can't parse the part about e2e not making sense for webpages.

It's what I'm saying above:

- If you audit the Signal sources, compile them and run them, then you don't have to trust the server.

- If you use the Signal app distributed by Google, you can trust that you got the same app as everybody else who downloaded it through the Play Store, unless Signal and Google collude.

- If you open protonmail.com in your browser, you have to blindly trust that the Proton server is sending you the code you expect. But if you have to blindly trust the server, then it's not exactly end-to-end encryption anymore, is it?

[Akronymus]

> - I can see when it gets updated (versus a website that gets updated every time I load it). For security reasons it's better, I can even verify my app with other people online and make sure we run the same thing.

in many cases this is no longer the case. Discord, for example, has introduced capabilities to update parts of the app without goung through the play store on android, same with youtube. Which they obviously use to enshittify things against your will.

[palata]

I understand your point, but I am not sure how relevant it is to use bad practice as a criticism of the technology itself.

Like I can write a modern C++ program that will be orders of magnitudes slower than an interpreted Java program from the 90s. But that does not mean that C++ is slower than interpreted Java: just that I can't write software, right?

If I care about security, then I choose apps that I believe are built correctly. I do happen to believe that ProtonMail is built correctly, and Signal as well. But it remains that because of how the technology works, the end-to-end encryption happening in ProtonMail requires me to trust the server, which defeats the point of end-to-end encryption in the first place [1].

[1]: to be fair, it does not defeat the purpose of ProtonMail entirely. It helps me trust that ProtonMail doesn't massively store data of all the users. But it is weaker because Proton can easily target me personally, and Signal cannot.

[tcfhgj]

One important which is not included: web apps are resource hogs

[stackghost]

Electron and React apps, perhaps.

It's completely feasible to build a webapp that is lightweight. I have done it several times.

[gxs]

Or just shitty developers that never give things a second - just sayin

[tcfhgj]

put the same optimization effort into a native app

[johnecheck]

Why?

[tcfhgj]

to avoid comparing apples with oranges

[pjmlp]

Webviews are not much better since Window 98 Active Desktop, yet here we are.

[esaym]

Yes, this

[bloppe]

At this point, most of those "native" apps are actually just web apps packaged in Electron. The fact that you generally can't tell the difference is proof that there aren't any real reasons to prefer a native app. All the reasons have to do with either OS vendors trying to hobble PWAs, or web developers creating React monsters for no good reason. Web apps can actually be very performant.

[gymhasanapp]

The real reason is really simple tho, and we could identify it ahead of time even before apps existed:

The average users sucks at managing bookmarks.

Telling a user that a feature is a webpage instead of an app means that they, in their glorious tech illiterate brain, think they have to memorize the url. They don't want to do that. They want to "have it" so they don't forget it. And having it is easier in the app mental model to them than in the bookmark one.

I know sufficient 40+ year olds who have the most absolute disgraceful phone desktops, filled with garbage. And yet, this is what they want. They want their bookmarkrs in the one place they'll check. And they want no folders.

[oblio]

This is trivially solvable with a good mobile OS level feature to create phone desktop icons from websites.

Of course, Apple and Google will never do such a thing when their cut of app sales is ~$100bn globally.

[Calazon]

I just tried and it looks like I can do this in Chrome on Android relatively easily. The UI could be a lot nicer for it though.

And I did run into an issue where if the site allows me to install it as a PWA, Chrome will want to do that and won't want to bookmark a specific page on that site instead.

Also, maybe your point was that this could be done at the OS level rather than the browser, which is fair.

[BlackFingolfin]

Not sure what you are talking about (is this sarcasm?), but on iOS, Safari allows you to add any website as an item to your home screen. I am pretty sure Android has a similar feature.

[oblio]

Is that front and center in the UI? How many users know about this feature? Do they promote it as much as they promote other features they want to promote?

Location and marketing matter. Otherwise we're in the Hitchhiker's Guide to the Galaxy where the aliens put Earth's demolition notice on the bottom of a cupboard in a cellar on a planet light years away from Earth.

[philipallstar]

In what UI? I've definitely done it by accident as well as on purpose before.

Most people like apps because they're often better to use, unless you have accessibility requirements (and even then an app that makes sure accessibility is good might still be better than a website that makes sure accessibility is good).

[pjmlp]

Agreed, except that on Android, you can easily bookmark any site as icon, when using Android Chrome.

Don't forget that Google also has ChromeOS, it is Apple that isn't that keen on the Web.

On the other hand, thanks to devs and Electron garbage, the Web is actually ChromeOS nowadays.

[bloppe]

You could tell the average user that installing a native app would require memorizing a URL too. You would be lying, but you would be lying just as much as if you told them that they'd have to memorize a URL to use a PWA.

[tcfhgj]

Everyone can tell the difference immediately due to the lack of performance

[bloppe]

You'd be surprised. Obsidian, slack, Spotify, figma etc don't usually get panned for lack of performance, and those aren't even very light weight. As wasm apps mature, it will only get harder to justify maintaining 5 different native apps instead of a single cross platform one

[palata]

Slack and Spotify really suck. I can't judge Obsidian and Figma, I don't use them.

The one example I know where they seem to have done a good job (at least in the beginning) is VScode, and even there it's not great. It's just not terrible. Put the same effort into a native app and it will be great.

[avadodin]

Not being unusably horrible in terms of performance and being required to do something I need to do doesn't mean I enjoy or even tolerate your JavaScript app, bro.

I'd switch over to the 16-bit VB4 form version as soon as available.

[vaylian]

Web sites optimized for mobile weren't really a thing when the iPhone launched. That's why apps shined on smart phones. Web designers did eventually catch up with the <meta-viewport> hack but the trend towards apps was already too established at that point and people thought that you need an app to use a service.

[steve1977]

Funnily enough, when the iPhone launched, it didn't have a native SDK. With iPhone OS 1, developers were supposed to create web apps. That only got changed with iPhone OS 2.

https://web.archive.org/web/20070722172208/http://developer....

[vaylian]

You are right. Steve Jobs also used the opportunity to destroy Flash. But my point still stands: Most web sites weren't developed with the mobile form-factor in mind until a while later.

[pjmlp]

HTML 5 canvas exists because of the iPhone, originally it was going to use Web apps.

[JimDabell]

Apple created <canvas>, but it wasn’t for the iPhone, it was for Mac OS X dashboard widgets. This was a few years before the iPhone existed.

[pjmlp]

While I stand corrected, it was nonetheless pushed by Apple.

[rrrrrrrrrrrryan]

Eh it's partially true - the browsers on phones needed to get better as well.

Zuckerberg famously made the Facebook apps basically just a responsive webpage under the belief that maintaining one codebase for all platforms would be best.

The performance on mobile was so terrible that Instagram started eating his lunch simply by maintaining native mobile apps that are actually performant, and Zuckerberg was forced to panic purchase Instagram (made by a team of 13 people) for a billion dollars.

Eventually phones got more powerful and mobile web browsers got good enough that PWAs could perform comparably to native apps, but it was too late, and Apple and Google had absolutely zero interest in promoting something that would damage their app store / play store revenue.

[wwweston]

It has now been longer since apps on smartphones were introduced than it was between the web’s birth and smartphones (to say nothing of popular uptake, it’d be generous to give the web a full decade there before the rise of the smartphone). Combine that with recency bias and the marketing serving incentives of platforms and vendors to push towards “native” and the point seems pretty strong.

There’s some minority of apps where work is offline resource bound or mostly offline regardless, those certainly have always made sense on device, other than that habit and mindset probably is the main driver of preference.

[alt227]

The original reason apps were popular was because they provided access to device apis such as accelerometer and gps which websites didnt. Think the beer drinking app etc.

Since web apis have caught up and allowed the same functionality, the common perception hasnt shifted back as App Stores have perpetually tried to keep attention so that they keep getting their cut of sales. If everyone knew you could do everything in a wepb page that you can in an app, sales would stop flowing and that is a bad thing for Apple/Google.

Most 'native' apps are just electron wrappers around a webpage these days, so how do you know you 'want a native app', just because it has the convenience of being managed through the app store?

[palata]

> Most 'native' apps are just electron wrappers

Desktop apps tend to be ElectronJS, because somehow Desktop failed. But because ElectronJS sucks doesn't mean that it's impossible to have good desktop apps. I have high hopes that Kotlin multiplatform and Compose multiplatform will make desktop apps cool again.

Then mobile apps are a completely different story: a good mobile app is a lot better than a webapp. At one end of the spectrum, I don't need an app to show a website (this should be visited from the browser). At the other end, I don't want a complicated webapp in my mobile browser, I want a mobile app.

Another thing that web people tend to completely forget is that a webapp is re-loaded every single time. A mobile app is downloaded once and fetches the data, and can sometimes mostly work offline.

I am very, very happy that CoMaps is a mobile app and not a webpage.

[alt227]

Everything you have said here is pretty much incorrect. Are you a coder and do you know how native and webapps work? If not I would do some research rather than assuming, because things you are saying about how webapps work are just not true.

[palata]

You may start by elaborating on why everything I said is incorrect. I can't really engage on "it's wrong, trust me bro".

> Are you a coder and do you know how native and webapps work?

I am, and I do. I am thinking that we may disagree on what a "webapp" is. I meant webapp as "a dynamic webpage that behaves like an app, but in the browser". Not "web tech used to write a desktop app" like ElectronJS. With ElectronJS you ship a desktop app built with web tech. You may also ship a mobile app built with web tech. But that's orthogonal to my point.

My point is that what you load in your browser is not installed. It's fetched at runtime.

[dminik]

I kind of get this, but quite a lot of the websites/webapps I use are better off on the web.

Imagine that from tomorrow, hackernews is an app. You can't do stuff like open 10 different tabs of it, put it in a tab group, expect it to restore where you left off after shutting down your device. It's interaction with other pages is also wrong. It would have to either open a webview or a separate browser app, both of which make navigations more complex. Extensions no longer work, you can't change stylesheets or use user scripts and so on.

This is why I don't like Reddit pushing an app and breaking/limiting the mobile website. It's just not how I want to use it at all.

[Akronymus]

> This is why I don't like Reddit pushing an app and breaking/limiting the mobile website. It's just not how I want to use it at all.

As with many reddit problems, old.reddit.com is a pretty universal fix.

[dminik]

I do use old reddit on my PC, but unless I'm programming or gaming, most of my browsing is done on mobile.

There are extensions to make old reddit mobile friendly, but by default it is a terrible experience. Another example for "you can't use extensions on apps".

[Akronymus]

I personally find old reddit on mobile more usable than both new and the app version.

[Pavilion2095]

Back then developers didn't have tools to create websites that look good on both desktop and mobile devices. So websites back then were hardly usable. Apps solved this issue.

[memsom]

I want native apps because I don't want to rely on the internet existing and I don't think hosting an offline web page in a captured browser is "good enough"

[curt15]

A lot of "native" apps rely on the Internet for essential functionality. Your Starbucks app would be deadweight if it couldn't pull your account info and store catalogs from starbucks.com.