Hacker News Reader

Comment by OkayPhysicist | Hacker News Reader

Nobody here is talking about the fact that a significant number of users want apps, too.

I'm responsible for an internal tool at the company I work for, hosted as a website, that handles a bunch of miscellaneous tasks that other employees need. Think reimbursements, documentation and reporting, gathering and presenting business data. That sort of thing.

When I took it over, it was desktop only ( a lot of <table> formatted pages with fixed px sizes). I spruced it up, modernized it to work on screens of any size, and created a mobile version of any pages that just didn't translate well to small screens (think "large tables of information").

When I announced the update, the number of people who asked me variations of "how to get website on phone if website on computer" or requested I make the damn thing an app was outrageous.

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.

View on HN

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

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

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.

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.

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

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.

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.

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

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.

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

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.

Yes, this

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

Electron and React apps, perhaps.

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

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

put the same optimization effort into a native app

Why?

to avoid comparing apples with oranges

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

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.

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

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.

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.

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.

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

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

Installed PWAs still run in a browser, they just don't show you the address bar so it looks and feels like a native app. (UX)

To all your points about a 3rd party intermediary, fair! Such an intermediary can be valuable. But whether we go through an intermediary is orthogonal to whether our app is running in a browser. Native apps can be installed without intermediaries (if your OS isn't evil) and there's no reason you couldn't build an intermediary for web apps.

As for your ProtonMail example... you got pwned. They just handed you some new code to run and you ran it. You could have ran the old code instead. You could have gotten a message saying "would you like to update?". You could compare the hash of content you received with others, tipping you off if you're being targeted.

To that, I imagine you say "but there's no reasonable way to do that stuff!"

And you'd be right. None of that is practical. Why is that? Is it some inherent difference between native code and code running in a sandbox? I think not.

I can't tell if you genuinely don't understand the difference between "installing a signed archive once and then running it multiple times" and "running code dynamically in a browser that is fundamentally made to be able to change next time you hit refresh".

Whatever you load in your browser is not signed, and it's not saved.

A PWA does not run in a browser, it is a browser. The question with it is whether you get the benefit of an app (you download it all at once and run it) or if it's just shipping a browser for wasting resources but then it still loads and execute the code dynamically everytime you open it (which again defeats the purpose of end-to-end encryption).

> And you'd be right. None of that is practical. Why is that?

Well it's a design decision. It's just not made for that. If it loads in the browser, it's fundamentally not made for end-to-end encryption. Now you can use webtech and build an archive that behaves like an app. I am not saying that "Javascript cannot do end-to-end encryption". I am saying that loading a webapp (that is, in the browser) defeats the purpose of end-to-end encryption.

> Is it some inherent difference between native code and code running in a sandbox? I think not.

Again, native code running on iOS and Android do run in a sandbox. You can always run code in a sandbox, it does not have to be webtech.

And it does not have to be "native code" to qualify as an app. You can use Javascript to develop an app. The difference is not in the tech itself, but in its distribution. A webapp is distributed dynamically in a browser, and as such it doesn't work with end-to-end encryption because a webapp assumes that you trust the server. That's fine in many situations (like talking to your bank), but not for end-to-end encryption, period.

We don't actually disagree, our definitions of 'web app' and 'browser' just differ. Personally, I find it absurd to say that PWAs (progressive WEB APPs) cease being web apps when installed, but whatevs.

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.

Right. Yeah it seems like we agree. My point is that if you dynamically run code coming directly from a server, you have to trust the server, and that is fundamentally a problem for end-to-end encryption.

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.

> Are they actively working against PWAs, or are they refusing to spend resources supporting another technology?

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.

> What difference does it make?

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

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

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

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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

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

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.

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.

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.

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"

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.

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?

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

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.

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.

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.

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

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

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

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

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.

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

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.

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

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

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.

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

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.

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

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.

When I say I want an app that implies a few things:

- this isn't a one-off use, I don't want an app to pay parking meter once and never use it again.

- it's an app and not a WebView pretending to be native

- it's native and not react-wanna-be-native

- you know how to make an app

I have to use this app to open a parcel locker and every time I launch it I have to wait for "downloading bundle". It's probably the easiest kind of app to make and yet somehow they made it worse then a website.

But take parents example. What is it you want the app version to do that a decent website can’t do?

Not the op, proper graphics.

Web 3D will never compete with native APIs in developer tooling, and hardware capabilities.

Now outside gaming, all CRUD apps could easily be mobile Web.

Okay, but why do you need 3D for an interface where you register leave?

Missed my last sentence?

To me the major distinctions are near full functionality even if I'm offline and the app hasn't been used in a long time and offline-first design with all major assets being available for download ahead of time and/or transferable between devices without re-downloading

Sure, but when it is for things like "reimbursements, documentation and reporting, gathering and presenting business data. That sort of thing.", I'm not really sure offline is that big a requirement, or that there are that many major assets. Even so, your mobile browser should be able to cache CSS and hero images.

Well, for starters, UIKit apps are faster and better on battery than web apps. Then we add a bunch of APIs that are just not available to a web app:

- Core Bluetooth

- Core NFC

- Periodic synchronization

- Background upload/download

- Background location tracking (in some cases, it's a plus, though)

- Nearby Interaction

- Anything USB

- No widgets

- No HomeKit integration

- No share extension

- No Live Activities or Dynamic Island content

The list is honestly too long.

To be clear, I do wish that Apple was less hostile towards PWAs and developers were better at making PWAs. Until recently, you couldn't even send a push notification from PWA.

> this isn't a one-off use, I don't want an app to pay parking meter once and never use it again

Just today I ran into a parkingmeter that was covered up in favor of ONLY allowing to pay via app. Which I find horrendous. (austria, for context)

End users don't care about if it's an app or not.

What they care about:

- Does it do what I need it to

- Can I access it easily

- Is it easy to navigate

- Does it work or is it buggy

- Is it slow

- Does it abuse notifications

- Is it prompting me to log in all the time

- Are there too many ads

- Can I use it on any device I have

- Does it complain about updating constantly

I don't think any of those actually has to do with being a website. The problem is that web browsers and websites didn't get a not-stupid UI for phones faster than the phone vendors could funnel everyone into their walled garden. Remember "click here for mobile" and having to develop two web interfaces? And half the time functions would be missing on one side?

I feel like I'm taking crazy pills reading these comments. Apps are clearly better for end users.

HTML and css is SUPER slow. It doesn't feel native, it doesn't feel good to use.

You also get so many weird glitches with state refreshing, sessions being cleared, log in not persisting.

Has anyone here actually used a PWA? You can feel that it's slow and clunky. Apps feel SO much better with the native UI, pre-downloaded, much faster etc.

I've found the most consistent indicator of overall app quality to be whether it is extremely small in size. An Android app under a megabyte in size is going to use the familiar, high-performance platform-native UI because it doesn't have room to do anything else. It is gonna do what it says on the tin and nothing else. It won't have ads. It won't phone home. Since it doesn't show ads and doesn't phone home, it's quite likely open source, meaning it quite likely has a GitHub project that I can look into if something goes wrong -- and because it's so tiny, I won't need to spend days trying to figure out how it works.

Or, you know, it's small because it's just a WebView wrapping a website.

You might be taking crazy pills or you've yet to come across an app that's just a webpage inside a web view (a lot of apps these days unfortunately)

For sure, and these apps feel bad. I notice instantly. But they manage local storage, caching, and sessions much better than a PWA anyway

> You also get so many weird glitches with state refreshing, sessions being cleared, log in not persisting.

And these don't happen in native apps? Because they somehow have less bugs?

> Apps feel SO much better with the native UI, pre-downloaded

React Native apps are pre-downloaded and have a native UI. Lots of them feel really bad. Not all, though.

You can make fast websites/PWAs just like you can make slow apps.

A web app is limited. Even if it loads fast, it feels clunky. Apps using native components have a much higher ceiling. Users don't care what tech is underneath

> A web app is limited. Even if it loads fast, it feels clunky.

But what about it feels clunky?

HTML and CSS are a lot faster than you want to believe. You can't tell me you've never used a website that isn't slow. Problem is the people making most websites don't care to optimize or profile anything.

Except most "native apps" shipped by most companies are Webviews, React Native, Cordova, Flutter, MAUI, and very seldom written with the native SDKs.

That sounds less like wanting apps, than simply having no idea what's going on.

Honestly, they probably would have been perfectly happy with a bookmark on their home screen, but have you ever tried walking someone who doesn't know how to enter a url into their browser through the process of making a home page bookmark on their phone?

Ultimately I ended up making a PWA that does nothing except act as a bookmark. Which was way more of a PITA than it should have been.

Sounds like what could be a useful built-in OS feature. Along the lines of:

"Aim camera at QR code to put "open-link" icon on your home screen"

Does something like that not exist?

It could, right? But let me tell you a secret: Apple doesn't want PWAs/web apps and actively limits Safari to force developers to build apps.

Devs can pretty easily implement this on their site using the BeforeInstallPromptEvent.prompt method.

https://developer.mozilla.org/en-US/docs/Web/Progressive_web...

Though of course...

> This is not supported on iOS.

>Ultimately I ended up making a PWA that does nothing except act as a bookmark.

Which is exactly what I was going to reply to your original post.

I am willing to bet 80-90% of user don't want / need / care if it is an Native app. They simply want the website / PWA bookmark icon on their App Screen selection.

The problem right now is the experienced of getting a PWA on to an App screen is not user friendly or in someway user hostile because it goes against the fundamental service revenue of their App Store model.

That and Apple ACTIVELY does not want PWA to catch on and be user friendly.

If a stupid website is turned into an App, then any purchases made through it instantly get slapped with a transaction fee straight to Tim Apple's pockets. There was a whole court case with John Epic about this and everything.

A PWA would bypass that. They really, really, really, really, really dont want that.

Apple especially has made this intentionally painful.

It used to be worse.

Most of the users of phones seem to operate on the no idea what's going on model. It's on developers to meet them where they are at, and if that's the app store you better be there for them.

Agreed, you never insult or complain about the customer you only address their issues

If pinning website bookmarks was more prominently advertised in the UI, they would be fine with it I guess. Though it would need some more changes.

Why do people like apps? Because they can put it on their home screen, they can open the app list and pick from there, they are searchable in a canonical repository, which is kind of like googling for the website but still.

Multiple apps can be switched between by just moving between the currently opened apps, while website tabs appear inside the browser only and are mixed with many other unrelated browsing tabs, making it harder to find.

I guess fundamentally all of these could be supported with browsers. But in the end, Google and Apple don't want to make bookmarks and independent persistent "browser windows" easier.

I really wish PWAs were more well-known among average users. If people knew and expected they could install certain websites as apps, that would simplify things so much and really balance the power of the app stores.

Unfortunately apple accomplished their goal of killing that entire idea. The time for it to take off was 10 years ago. They begrudgingly support it now but it's too late. gg

My problem with PWA, is that it usually completely ruins the multiple tabs/windows of the same app/data

On desktop or on mobile?

On mobile it's rare for apps other than web browsers to allow multiple tabs/windows and the ones that do (Ex: Gmail allows a draft to be a second window) have many multi window related bugs.

> On mobile it's rare for apps other than web browsers

One more reason I'd rather have a site than an app: because I can open multiple copies, open a link in a new tab, open different installations of the same site, and all the other things that browsers automatically support.

It's not well known because it's annoying to install ... and it's annoying to install because the stores are huge cash printing machines so that's not going to change.

It's not that hard to install. The website can just have a button you click to trigger an install prompt: https://developer.mozilla.org/en-US/docs/Web/Progressive_web...

But of course...

> This is not supported on iOS.

But on the same page

> On iOS 16.4 and later, PWAs can be installed from the Share menu in Safari, Chrome, Edge, Firefox, and Orion.

So you can't have an install prompt, but it's still pretty easy. If people can learn hamburger menus they can learn this.

When I announced the update, the number of people who asked me variations of "how to get website on phone if website on computer" or requested I make the damn thing an app was outrageous.

I had a similar experience. It was mostly lower- and middle-managers who needed to put their mark on something visible.

I responded with, "Tell me what features you want the app to have that the web site doesn't; or is this a vanity project?" The "vanity project" line is what made people re-think what they were asking.

When that didn't work, I pointed out that they'd have to hire an entire new team to do the app, and gave them a high six-figure number to accomplish what they wanted.† That always worked.

† For a number of regulatory and political reasons, we cannot offshore for cheap.

I think you're right, but I think it's also because the industry trained everyone on this model. I remember ~ 2010-2012 there was a big push to make everything an app. As far as I can tell the only benefit to users is a nice icon on the home page, and the benefit for the company is.. exfiltrating data from the users phone?

My PWA skills are rusty, but IIRC it's one click on Android to install web page as an "app" (ie it appears on the home screen like anything else), and it was about 3 in Safari - perhaps a onerous for B2C, but surely not for internal users.

So you can easily make an "App" for normies, from a web page.

I encountered something similar recently. I put a lot of effort into making a PWA mobile-optimized version of my product which is effective an app in a browser. And I was flooded by user feedback saying they simply would not use the product until there was an app available. There is little option but to create an app in this environment, or face disinterest from potential customers. And the internet is shockingly mobile-focused nowadays, 80-90% of traffic is coming from mobile devices. So not having an app is death for your business.

Apple will also not approve a straight web browser in an app wrapper, there's a specific rule that disallows this, so you have to make some good faith effort to implement it natively or not be allowed on the App Store.

As not a web dev, out of curiosity: What would be the drawback or problem with showing a header or pop-up on mobile browsers, offering to install them as (web)app? Then using the PWA functionality of the browser to do it.

I'm not a heavy user of those but the result of PWAs has always been an icon that's handled by the OS like if it was any other native app, and when opened it just behaves like the web browser in kiosk mode just for that website.

Would be great, but at least on iOS the only way to add a PWA to your home screen is via the share menu. Apple would need to support that header pop-up to install the PWA and they won’t unless someone makes them.

> What would be the drawback or problem with showing a header or pop-up on mobile browsers, offering to install them as (web)app?

In this world, every single site now pops up asking to be installed. No thanks.

> When I announced the update, the number of people who asked me variations of "how to get website on phone if website on computer" or requested I make the damn thing an app was outrageous.

This level of technical illiteracy shouldn't be tolerated in the workplace in 2026. We all work on computers all day, there's simply no excuse for being incapable of basic computer operations. Upskill or get out.

If the app store allowed you to install bookmarks, I doubt most people would notice.

It does. It's called a PWA.

That is not an App Store functionality, that is a Safari functionality

There are other phones. They allow publishing PWAs, it turns out.

The Google Play store did (maybe still does?) allow installing some PWAs advertised as light versions of the apps.

I came here to say that a significant number of developers want apps, too. Including me. For many reasons including performance. But the one I want to mention here is security, because it systematically gets missed by web people:

End-to-end encryption fundamentally doesn't work in webpages. Because when you load a webpage, you have a 1:1 connection to the server which sends you the code you need to run. You have to trust that the server sends you the right code, every single time, and there is no practical way to verify it. The whole point of E2EE is that you don't trust the server, and with a webpage you fundamentally trust the server. That's completely incompatible.

Let's compare the Signal mobile app and the ProtonMail website:

- With Signal, you can audit the sources, compile them and run that. You know you are running the code you audited. You can trust someone else to audit the code, compile it and run it. Or you can just download it through the Play Store and know that tens (hundreds?) of millions of people did that too. If you download it through the Play Store, you can "verify" your app with someone else, making sure that Google didn't send you a modified version (which would have required Signal and Google to collude in the first place). You know when the app is updated. If it matters for your life, you can make sure you benefit from end-to-end encryption.

- With ProtonMail, you load a website. Everytime you load it, the sources could change. When you enter your password, you enter it in that very code that the server just sent you. So the server could identify you, and just this one time, send you a different version of the code, just for you, that would leak your password to them. You don't have any way to pin a version of the website and compare it with others, and there is no need for Proton to collude with anyone else to do that (it's a lot easier when no collusion is needed).

Again: end-to-end encryption fundamentally does not work with webpages.

FTA

> I can’t understand how we got to this place with “app culture”

> Nobody here is talking about the fact that a significant number of users want apps, too.

End users, for the most part don't know what they want. They take when makes sense to them. To end users apps are easy. To us, a URL is easy.

> But the tech illiterati exist, and they love apps.

Yup!! And we get sucked into this vortex at times. Good post btw.

> Nobody here is talking about the fact that a significant number of users want apps, too.

This is true, as it depends on the nature of what is being presented and if offline usability is preferred or doable.

Everything as a website, can arguably be an equally bad fit for situations, as everything as an app. Flexibility and careful study is required.

On iOS, I think the only two reasons to have an app are: notifications and access to contacts.

Rich widgets on the Home Screen are valuable too. As a web developer, I wish I were able to make widgets for people to put on their Home Screen to perform certain actions in less clicks, or have information from my (web) apps easily viewable at a glance. Which I know they would want. Right now, as far as I’m aware, for me to do that in iOS (and possibly Android) is to build those in native land.

Use this to test it out, https://whatpwacando.today/

Wait wait. How does PWA when I click "install to home screen" actually show me that rich preview screen, with instructions? That's crazy!

Edit: I have been truly wowed today https://web.dev/learn/pwa/installation-prompt

the benefit of apps is they don't break. websites update out from under you and the web expects browsers to always be evergreen

> the benefit of apps is they don't break

What world do you live in? Apps are either enshittified with updates, or the content source the app was using is broken in similar ways to a normal website.

The only way you avoid this are sideloaded non-networked apps - which are not the usual.

updating apps is optional is my point

I agree with that point.

The useful executable code is contained on your device rather than fetched from a website. No update means you can run that useful code forever.

Not many apps are useful in that form though.

Wrap the page in an app and publish to app store.

Can someone explain why this isn’t obvious?

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

LOL. Kindly do this prompt to any LLM : "critize this statement, or any logical fallacy inside"

Try applying the same level of skepticism to your own statements before posting them on HN.

so add a manifest.json and give them instructions on how to install a PWA

The "uhm, ackshually" responses to this comment are insane.

Okay I guess? So then you politely answer to them the “app” is their web browser of choice! Problem solved

Reply on news.ycombinator.com