[jonahx]

> We take tech literacy for granted, because it's like a dozen levels down fundamental to our entire field. But the tech illiterati exist, and they love apps.

They "love apps" because apple and android have spent billions to break their mental models and convince them that "you use apps to do things on your phone". Literally. That's the extent of most people's understanding.

So, sure, they "want" apps in the same sense that early internet users "wanted" AOL because in their minds AOL and the internet were indistinguishable. But actual free choice requires an understanding of the choices.

[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

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

[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?

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

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

[cyberrock]

To most modern users, web browsers kinda suck if they don't know URLs. For example, if they want to find an item they saw on Amazon, searching it in browser history just sucks compared to the in-service search.

A lot of users also use browsers like they use their Desktop folder, which is to say they have 100s of tabs open. The fact that apps enforce quitting and limited state is a plus to them, hence mobile Chrome adding an automatic inactive tabs cleanup feature (which mobile FF removed for some reason?).

Browsers really should've adapted to this reality with some UI/UX changes, like showing relevant site history. But none of them are actually interested in improving UI/UX, and the few changes that do get through just piss off long-term users.

[Akronymus]

> To most modern users, web browsers kinda suck if they don't know URLs. For example, if they want to find an item they saw on Amazon, searching it in browser history just sucks compared to the in-service search.

And, more and more, browsers are trying to hide the URL as much as possible. Which is REAPLY annoying.

[montag]

That is a great analogy! I still remember the day my cousin explained that there was a whole internet outside of AOL…

[jxdxbx]

No, because I used a computer before web apps took over and native software is a better experience.

[herval]

webapps are inefficient, clunky, slow substitutes to actual native apps. I think decades of marketing and billions spent by Google trying to convince people that webapps are better is what makes many tech people think they are. Literally.

People "want" webapps to be what users "wanted" bc it pays their salary...

[jonahx]

That's clever rhetoric, but for most use cases it's just not true, and that's the point of the original article. There are legitimate use cases for native apps, but many of them could be converted to an instantly loading, 50-100KB web page without losing any functionality. As opposed to a 50-300MB native app, which you need a fast connection to install, and starts up more slowly than the web page every time you use it.

[herval]

You’re doing native apps wrong if they’re 300mb. And also no web app in 2026 is just 50kb!

[high_priest]

They both have their uses. At the extreme, try to imagine Pubg as a web app. There are good modern games that work purely in a browser. But still, there are "applications" that function better as full fledge clients seeping small amounts of data and there are "applications" that function just aswell as dynamically loaded full server-side solutions.

[herval]

I know, I agree both have their uses :-) I was just jesting about the kind of extreme OP went for.

[Silasdev]

My take is that they love apps for the simple reason they show as easily clickable buttons to enter. Most dread having to type a Web address for something they regularly do. Few know that they can create an "app-icon" from any Web page. Should be advertised more.

[teo_zero]

> Few know that they can create an "app-icon" from any Web page

Let's say from most web pages. Some sites will hijack your browser and install their PWA instead of the page you requested.

[EduardoBautista]

I “love apps” because it’s less likely to be bloated electron crap or browser based. It’s easier for me to review code on the GitHub iOS app than in the browser because performance is much better.