Your 'app' could have been a webpage (so I fixed it for you)
danq.me
danq.me
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.
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.
"Aim camera at QR code to put "open-link" icon on your home screen"
Does something like that not exist?
https://developer.mozilla.org/en-US/docs/Web/Progressive_web...
Though of course...
> This is not supported on iOS.
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.
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.
It used to be worse.
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.
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.
But of course...
> This is not supported on iOS.
> 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.
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.
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.
https://web.archive.org/web/20070722172208/http://developer....
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.
It's completely feasible to build a webapp that is lightweight. I have done it several times.
- 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.
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.
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.
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.
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.
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.
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".
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.
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.
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.
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.
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.
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".
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
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.
I can't parse the part about e2e not making sense for webpages.
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?
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.
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.
Of course, Apple and Google will never do such a thing when their cut of app sales is ~$100bn globally.
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.
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.
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.
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).
I'd switch over to the 16-bit VB4 form version as soon as available.
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.
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?
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.
> 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.
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.
As with many reddit problems, old.reddit.com is a pretty universal fix.
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".
Let's say from most web pages. Some sites will hijack your browser and install their PWA instead of the page you requested.
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.
And, more and more, browsers are trying to hide the URL as much as possible. Which is REAPLY annoying.
People "want" webapps to be what users "wanted" bc it pays their salary...
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.
Login flows are simpler and persist better, with local storage etc.
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.
- 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.
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.
- 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.
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)
Edit: I have been truly wowed today https://web.dev/learn/pwa/installation-prompt
> 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.
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.
In this world, every single site now pops up asking to be installed. No thanks.
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?
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.
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.
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.
Can someone explain why this isn’t obvious?
So you can easily make an "App" for normies, from a web page.
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.
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.
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.
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.
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.
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.
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.
Now, I’ll be the first to admit that my actual app is pretty much garbage. I don’t expect it to be popular. It’s basically a worse version of stuff that is already available.
I expected this to be a learning exercise about the process of getting stuff published.
Long story short, by the end of the ordeal I was somewhat surprised that anyone independent bothers to publish apps at all. The amount of red tape and nitpicking by the initial app review process is astounding. The business/legal side is also annoying. I might be misremembering or misinterpreting, but it seems like you really need an LLC with a mail forwarding service and a cheap second phone line just to avoid the App Store sending the whole internet to your personal phone and address.
On a website you can just not deal with any of that, and not give Apple $99/year just to keep your app on the store.
And we haven’t even gotten into the big royalties you’re paying for App Store purchases.
Still, I understand the appeal at some point, just not for an app like OP was forced to use. I certainly wouldn’t want to use something like Immich or Opencloud without an app: these apps need to deeply integrate with my phone to be truly useful.
I have no interest in installing a web app that could look innocuous today and be entirely different every time I hit F5.
Just weeks ago they published a sanctioned Russian bank's app masquerading as a pomedoro timer lmao.
I think if they didn't have immunity for all the scams and fraud - and that's being challenged by both the EU regulators and in US courts - they'd probably have a lot more than 500 people. Multiples of it.
BTW, good recent comment on the difference between Apple and Google reviews: https://news.ycombinator.com/item?id=48911599
Search right now in the App Store for "Morpho" and you'll find a "Morpho: Network" app. That app says it's some sort of TODO/Note taking app. It uses very broad language in the screenshots and assets from morpho.org (a decentralized protocol).
Once you open the app, it immediately downloads another bundle using OTA updates and shows an entirely different app where you "connect your wallet". You can imagine what happens next.
Section 230 immunity baby!
That's been the case with native apps for a long time now too.
It's such a weird thing to be concerned about though. Your phone automatically updates apps by default so they can suddenly look different later. And even then, so what? If the change was malicious just stop using it? Apps are sandboxed, websites are sandboxed, you'll be fine.
What's worse is that there's practically no process to report any sort of rulebreaking, so someone could be mining crypto or running a residential proxy [1] through the mobile game I've been playing, and I'd be none the wiser.
Not that it doesn’t occasionally happen, but at that point you’re trying to dodge the police… as compared to there being no police in the first place.
All the time I hear that "PhotoSync" is good or I install an app for a business that I deal with like my bank or the local gas station.
On the other hand I feel like it is safe and usually worthwhile to browse the web -- even the sketchy parts, like the web sites that lead me into rabbit holes right out of Videodrome.
You cannot make that claim unless you know how many apps Apple has rejected for being garbage. On one hand, developers complain Apple runs all kinds of checks on their apps before publishing on the App Store. On the other hand, users complain that App Store has too many low-quality apps. Both can be true at the same time if the stream of apps is high volume and low quality.
and failing at it, because that garbage got published on the app store.
Or as I have encountered several times over the years, it turned out to have vanished without a trace for whatever reason (author got bored, became ill, didn’t want to pay for the domain any more, etc) when I reach for it, sending me searching for an alternative in the midst of a task.
Self-contained binaries stored on my personal devices don’t do that, and one can usually find third party copies scattered across the internet long after the author stopped publishing/maintaining them.
I personally have no love for web apps either. No matter how many well-behaving developers are out there, the median web developer has ruined the web as an app platform to the point where I view web software as generally hostile, ad-filled, spyware, that's under the control of and serves the web developer's interests over the end user's interests.
The other issue is that web browsers are dynamic environments (much more so than operating systems) and sometimes break/change things. Users who’ve frozen PWA updates don’t have any access to critical fixes. A lot of devs just wouldn’t support frozen versions.
I’m a dev and understand how web apps can be attractive to us, but as a user they irritate me. During my formative years, software by and large served the user over the dev, so flipping the scales entirely in my favor as a dev feels almost wrong.
It’s working. Your low quality project you weren’t really committed to got filtered.
I got apps on the store before age 18 because I did not believe they were low quality.
You also can make software without selling it on a store.
My project hasn’t been filtered at all. I just found the process more of a bureaucratic exercise than made sense (and the end result was that my low quality app was accepted so none of this is done in the name of quality).
My last attempt, it felt like Apple was no longer interested in the idea of hobbyist developers. The setup just to get the Xcode project setup felt like I needed to have a company and a website. When I selected something about iCloud, because I thought it would be nice if what I made synced to iCloud, I couldn’t even get started without paying $99, so I had to start again and choose a different option without it. And here I thought the $99 was just to publish to the store.
Considering how Apple started, this trend feels wrong. When I wanted to make a simple little app a few weeks ago, I ended up using python with webview. It seemed to be one of the few ways to make a little GUI app without boiling the ocean.
Recently I tried out tiktok for a day and couldn't fathom why I would possibly want to ever use this app. Same with Instagram. But people who followed their trajectory since their earlier days find them normal.
Same with Facebook, actually. And Google.
On the other side of that equation, my very old YouTube account (which still has a subscription to "YouTube Red" that costs half of what a new subscription to YouTube Premium costs) has been trained to show me certain content, and if I joined with a new account or told someone else to join, I know the homepage would be filled with dumb slop.
I agree with everything else you said though.
That's an EU thing. If you don't publish in the EU you don't need to dox yourself.
Technically the government knows where you are and all that, but the public doesn't easily know where I literally sleep at night.
And, really, if someone was to mail me a letter as a customer, I would get it. The forwarding service will scan mail for me or let me pick it up in person for a trivial fee
This ends up costing about $10/month depending where you live.
Just one more little way that this is a bit of a hassle to just sell a little $5 app as a side gig.
And I know this is more of a government regulation thing but I wonder if there's no other way to be compliant with regulations and also save solo/small businesses from this little extra bit of annoyance and cost.
Large companies or even relatively small businesses that exist in leased commercial space don't have this problem since their mailing address does not represent a real person's house and has no ties to an individual.
The internet has created a culture of deranged harassment that makes posting your identity online alongside anything you publish more insane than ever. And your market is more or less the entire world rather than your local community.
A random counter-example from France. If you have a one-person small business (i.e. with a registered business number and the right to invoice), all personal information beyond the name is private by default, it cannot be looked up. The Nordic countries are perhaps closer to the image you're painting. Personal tax information is famously public in Sweden, for example.
But IMO differences are easy to exaggerate. Let's not forget that private phone numbers used to be published in paper directories - with home addresses! - everywhere, including America.
It used to be much more open, with phonebooks and open tax records, but the last decades I think every Scandinavian country have started prioritizing especially online privacy. E. g. the Norwegian Datatilsynet used to be legendarily tough on things like public CCTV, and now they go after even random chrome extensions.
It's infamously difficult to dox someone from Scandinavia compared to e. g. the US with tons of databrokers.
Unless I’m mistaken, Steam and GOG games aren’t listing the address of the game developers in the EU, but I admit that I might be mistaken.
For something free I can get why this would seem unreasonable (modulo scams, for which this is a hoop I would rather have than not), but if money's involved, a consumer should be able to contact a human and be made whole, and having the money be handled by a company (even if that company is just a one-man-show) honestly does not seem unreasonable.
If you want to bypass that, you just shouldn't publish to the App Store, which does (or at least is supposed to) have protections suitable for most people. You should still be able to make apps and use them without the App Store involved, then the individual human who wants that app can make decisions based in the specific app in question and the people behind it, but that's a separate conversation.
That sounds like something that needs to be fixed.
> Contacting the developer by physical mail doesn’t have any effect.
Ditto.
However, if you’re running your own website you can make those decisions on your own without being forced into most of them.
Plenty of very large “reputable” companies obfuscate their physical address and phone number, and don’t even offer an email address for contact.
I’d also say that this shouldn’t be as necessary when an app platform is involved. Apple takes 15-30% of the revenue and acts as a full retailer. Why do App Store customers have any need to contact the underlying developers in this scenario?
Walmart doesn’t make it easy/possible for me to contact the manufacturer of their t-shirts.
There are even other digital software stores like GOG or Steam that really aren’t selling you software that has a guaranteed point of contact.
Those platforms just have a half-decent to decent return policy and act as the middleman.
But when you’re on iOS you have all the burdens of a third-party supplier without all the benefits.
This is whataboutism. They should do that too. The fact they don't isn't an excuse for smaller devs or companies.
> I’d also say that this shouldn’t be as necessary when an app platform is involved. Apple takes 15-30% of the revenue and acts as a full retailer. Why do App Store customers have any need to contact the underlying developers in this scenario?
You should be able to contact the underlying manufacturer or whatever of any product you buy. Why should programs be different?
> Walmart doesn’t make it easy/possible for me to contact the manufacturer of their t-shirts.
They should.
> There are even other digital software stores like GOG or Steam that really aren’t selling you software that has a guaranteed point of contact.
More whataboutism. You should have a guaranteed point of contact for what you buy there too.
In the Walmart t-shirt example, should I have the contact info for not only the factory but the other suppliers who made the dyes, threads, cotton, the people who made the fuel for the harvester, the people who welded the tractor together?
Sure, maybe your idealist answer is yes, and on a conceptual level I can agree with that. But from a practical standpoint as the end consumer there is a stopping point.
My point is that Apple handles the money and the refunds, and they make all the software APIs. Completely closed platform. Why doesn’t the buck stop there? I feel like they pass along business responsibilities despite taking a large percentage of revenue.
If they’re going to pass on all those responsibilities for me then their cut should be more like ~5% to just cover transaction and platform costs.
Down to the manufacturer of the whole product you're buying. In the case of your strawberries that would probably be the farmer.
> In the Walmart t-shirt example, should I have the contact info for not only the factory but the other suppliers who made the dyes, threads, cotton, the people who made the fuel for the harvester, the people who welded the tractor together?
No.
> Sure, maybe your idealist answer is yes, but from a practical standpoint as the end consumer there is a stopping point.
Of course there is. But you as the sole dev of an app are not at that point.
> My point is that Apple handles the money and the refunds, and they make all the software APIs. Completely closed platform. Why doesn’t the buck stop there?
My local electronics shop also handles the money and refunds when I buy a Dell. I can still get a refund directly from Dell if my machine breaks (not that I actually have a Dell). Yay reasonable laws.
The platform being closed and all the APIs being controlled by Apple are different problems that should be solved separately (which the EU is working on!).
In case of an app, what is the "product" you are buying? Because according to Apple, they add a lot of "value" by ensuring the software is safe, performant, etc etc. Am I not buying "a safe, checked app"? Or am I buying an app and then separately pay Apple for an added service of "checking the app for safety" etc etc. I'd very much presume the first.
But if its separate, "an app" can be rather ambigous. For a one-time-purchase game, its clear. But many apps are really a service or even more that happen to have "an app" as one of the ways to interact with the service: Netflix, Uber, protonmail, Vinted (or ebay), etc etc: the app isn't the thing I buy. It's a wrapper around a service. Or even just one of the portals through which I can buy stuff. Point being: It's not simple, so your answers don't fit the analogy of "wallmart".
The app.
> Because according to Apple, they add a lot of "value" by ensuring the software is safe, performant, etc etc. Am I not buying "a safe, checked app"? Or am I buying an app and then separately pay Apple for an added service of "checking the app for safety" etc etc. I'd very much presume the first.
If you want to, you can imagine the 30% cut being that separate service, but most analyses I've seen of this assume the first is the case, and I can't really see why it wouldn't be.
> But many apps are really a service or even more that happen to have "an app" as one of the ways to interact with the service: Netflix, Uber, protonmail, Vinted (or ebay), etc etc: the app isn't the thing I buy.
In those cases the app on the App Store is free, so there's nothing a consumer can really complain about, since they haven't bought anything. You can complain about the service rendered when you pay, but that purchase is handled completely separately from the app (non-)purchase.
> Point being: It's not simple, so your answers don't fit the analogy of "wallmart".
It does for apps bought as products. If you want an analogy for apps bought as services, then I'll use a different analogy, since they behave differently, and are treated differently in law.
Walmart sells both fresh/frozen/packaged food (lots of food safety regulations) and t-shirts (few regulations by comparison). They also sell things like cell phone plans and subscription services that have entirely different sets of regulations.
Exactly as you described, if I make a specific type of app, maybe the business address and responsible party should really be Apple. If I make a subscription service app, then it should be me.
Replace 'app' with literally any other product or service in that sentence, and it still seems reasonable to me. You should be able to reach the producer of your frozen nuggies from Walmart, as well as the manufacturer of their t-shirts.
If your product or service is free, then a lot of that flies out the window (assuming it isn't actively hurting someone). Netflix's free app doesn't really do anything if you don't pay, but since it's free, you can't bring a claim to Netflix to complain about it, since you haven't paid for anything. The moment you pay for service though, then your right to complain if there's a fault in the service kicks in, which may or may not involve the free app (which Netflix is pointing you to and telling you to use to use their service). Once a consumer has paid for something, they should be able to follow the trail back to whomever made the product they're using.
I wouldn't presume that. Malware ends up in the app store all the time.
I personally think it's a lie at best, or a scam (on multinational level) at worst. I've always been convinced that regulation should force companies that make such statements to be held responsible. Treat them like an insurance company or such.
I pay a few dollars every month to be protected against scams and malware. So when I do get infected, Apple failed to do what I paid it for and Apple should be forced to pay me for damages.
I know this may seem like moving goalposts, but I forgot to mention another point here, which is that I'm perfectly happy with allowing my customers to reach me by mail and they actually can reach me that way. What I'm much less okay with is someone knowing where my family and I sleep.
I have a mail forwarding service so that I don't have to give out my home address. If you send me mail to that address, I will see it!
It's another cost and hassle to have to set this up just to avoid the rare but possible doxxing situation that comes along with putting things out in public. The other part of this is that big corporations are obviously much better equipped to handle this scenario and they don't represent a single person's reputation or literal home in the same way.
I realize that addresses aren't really private but you never know what can happen. Maybe my app blows up and goes viral, there's some kind of controversy that gets out of my control via the media or something like that, and now my App Store listing for my viral app has my home address and a bunch of people on the Internet start sending me poop in the mail.
Now, all of this may be more of the fault of EU regulations and that's also perfectly fine but it makes me wonder a little bit if there can't be some kind of solution that is compliant but a little friendlier to small/solo businesses? If it's not possible I can definitely accept that.
> I have a mail forwarding service so that I don't have to give out my home address. If you send me mail to that address, I will see it!
In this case you have an address where people can reach you. I have no problem doing things this way. And even if you were a knobhead who only did that to fulfil the regulations and ignored any actual mail going to that address, being able to send mail there, have it go in a black hole, and then be able to go to whatever consumer protection agency and tell them 'I mailed them a letter and they never responded' has value in and of itself for the consumer.
> It's another cost and hassle to have to set this up just to avoid the rare but possible doxxing situation that comes along with putting things out in public. The other part of this is that big corporations are obviously much better equipped to handle this scenario and they don't represent a single person's reputation or literal home in the same way.
> I realize that addresses aren't really private but you never know what can happen. Maybe my app blows up and goes viral, there's some kind of controversy that gets out of my control via the media or something like that, and now my App Store listing for my viral app has my home address and a bunch of people on the Internet start sending me poop in the mail.
Fair point that it's a hassle for you as an individual. I get that you don't want to be doxxed. In an ideal world the people doxxing you would be prosecuted for doing that, but that's probably a big ask if you're in the US, at least from what I can tell. In Europe from what I can tell, while it's not a non-issue, it usually doesn't get worse than verbal abuse and people being angry on the internet, and while nobody deserves death threats, at least it's just words and not, ya know, letter bombs or swatting. Even relatively 'minor' offences caused by going viral, like stalking, are prosecuted and dealt with from what I can tell (exceptions obviously exist in both directions).
> Now, all of this may be more of the fault of EU regulations and that's also perfectly fine but it makes me wonder a little bit if there can't be some kind of solution that is compliant but a little friendlier to small/solo businesses? If it's not possible I can definitely accept that.
I'm not sure what can be done beyond loosing the restrictions on the little guy, but I'm not sure if there's much political will for that (and don't get me wrong when I say this, but also, good reason). If there's a reasonable solution that upholds consumer protections and rights, I'm open for it.
The EU decided so, and Apple didn't require this before EU did
Did the EU specifically demand this from Apple? Did they specifically require that consumers must be able to contact developers?
Or is this another "spin" by Apple to make the EU look bad when it imposes consumer protection that is bad for Apples revenue? Like they did with "chargers", "cables" and like the ad- and surveillance-industry has done quite successfully with their "spin" on the GDPR (making it seem like the EU or GDPR requires cookie banners - which it doesnt)
This changed recently.
You will however pay for that privilege - a lot of people don't seem to realise their home address is in the WHOIS data, because they didn't pay the protection money to redact it
Apple does not provide any mechanism for developers to issue a refund, or even look up or view your purchase or subscription - so there is nothing a developer can do here besides refer you to apple support.
(Although as a developer I would like to be able to do this, because customers are very confused by it)
You're buying a digital good. You can already get refunds. An email address is fine for contact.
You definitely don't need someone's physical home address, nor an actual phone number.
And sure enough, they are in fact the ones who can issue a refund if you need one. The developer cannot. By design.
Yet I can also ask Dell for a refund despite buying my Dell at my local electronics store. Both should be reachable and both should be able to give me a refund if my item is broken.
> And sure enough, they are in fact the ones who can issue a refund if you need one. The developer cannot. By design.
And Apple should fix that.
What Dell will do is repair or replace a computer that is still under warranty. They won't refund.
They're legally required to.[1]
[1] https://lovdata.no/dokument/NLE/lov/2002-06-21-34/KAPITTEL_5... Section 35
Edit: Forgot there's an English version.
Reading the law, it does not say that the consumer is entitled to a refund.
Simple. They operate within the law and provide the customer with a refund, or they get fined. From the consumer's point of view, this is irrelevant. Business can fix this B2B issue between themselves however they wish, so long as it doesn't affect the consumer. If you don't like it, then don't do business here.
Here's a case where a consumer complained directly to the manufacturer,[1] and the Consumer Disputes Commission ruled in favour of the consumer.[2] It's not even the core of the issue, but just mentioned, since it's settled law.
> Reading the law, it does not say that the consumer is entitled to a refund.
Refunding is one possible remediation, see section 32 (cancellation) and section 26 (The consumer's rights in the event of defects). That option cancels the purchase contract, meaning you as the consumer give the item back, while the seller gives you the money you paid for the item.
[1] https://www.forbrukertilsynet.no/wp-content/uploads/2025/12/...
'Innklagde er klaget inn i kraft av å være produsent av syklene. De er følgelig ansvarlige for kjøpsrettslige mangler etter direktekravsreglene i fkjl. § 35.'
Rough translation: 'A claim is lodged against the defendant due to it being the manufacturer of the bicycles. The defendant therefore liable for for defects accordance with the rules on direct claims set out in section 35 of the Act relating to consumer purchases.'
[2] They didn't rule in favour of the consumer's demand to have the manufacturer pay for their jacket that got damaged following them falling of their broken bike. They did rule in favour of the cost of repairing the bike (a new handle bar that the consumer bought themselves to fix the issue), so the manufacturer is on the hook for that.
Only if the manufacturer fails to fix it per section 31: "If the defect is not rectified and no redelivery takes place pursuant to sections 29 and 30"
I'm finding it hard to reconcile a) how difficult the process and b) the load of absolute garbage apps that are out there.
This is an EU requirement, and Apple didn't do this before EU required it. All app marketplaces have the same requirement for EU
> On a website you can just not deal with any of that
This may violate other EU compliance requirements but sure there's obviously no authority determining your compliance before allowing you to publish on web
The idea of an app really appealed to me (at first), but the more I thought about it the more I didn't want to deal with iOS and then Android and then maintaining parallel functionality on the web and all that mess just for a fairly-local hobby project that I make no money off of.
So, I just kept it as a website (which is also a PWA) with extensive testing on every platform I can think of. It's just worked out so well and is so, so, so much less complicated. And if I abandon it, should just keep working for years so long as the website stays up (or until browsers start doing something very different JS-wise.)
(You can see it at https://trailmaps.app if you're interested.)
Does the PWA state of things resolve that in the modern days? If it did, yeah I'd agree, no need for an app at all. In my case the app was being used in rural Ontario. I cant even make a phone call here without wifi.
Each map is 16MB - 20MB in total, so this is all nice and simple to do. Even on a slow 3G connection it's only a minute or so for a full map update to stream in.
The whole point of this system was to take a snapshot of data (mostly OSM), add on some local things that can't really be represented in OSM (like WHICH parking lots are most appropriate, stylistic overrides, system descriptions, etc) and display them. Because of issues I've had in the past with well-meaning-but-misguided OSM mappers wrongly editing trail systems I did not want anything that pulls live.
And then by having purely static content the hosting is very cheap and easy, there's no security concerns around... well... anything dynamic on the site. And each map is portable were I to want someone else to host them. And literally in a couple of years if I haven't updated the map it won't change yet still will work, and that's fine and accepted for this use. Sort-of like a mobile version of a traditional print map. Kinda like the print workflow of editing/design/etc and then rendering the PDF, but web.
This all aligned nicely for me to have a tool that works this way, with each map generated by a tool.
(Sort-of disclaimer: It was also a big personal project in learning to work with AI stuff for development. I knew and understood the inputs and outputs, was able to design the UI, handled/managed all the testing... But I didn't have to worry about the actual-code part. I was able to make pretty quick progress and iterate nicely on my ideas.)
Happy to talk, etc, more about it too. Either here, or contact info is on the site.
Gosh, I wish more apps did some kind of progressive "enhancement" and let people read already cached messages and do deferred sends like the old days, instead of being completely useless without a data connection.
I spent many late nights trying to debug reachability bugs. It's frankly a nightmare trying to build a reliable app when the user has /some/ cell service, but not enough to operate the app reliably.
(And so, so many little bugs in my map thing from upthread were these odd timing quirks when a user didn't have good service and one check would run and leave something else hanging resulting in a blank map. <sigh>)
Home depots website sucks anyway, slow, clunky, terrible touch space, and the search is awful.
Aside, they should ad cell repeaters inside to fix all this.
Also, apparently Apple really doesn't like approving apps that are basically wrapped PWAs (Google will, I guess?) so that is yet another check against bothering with an app.
The main idea was to solve the gap of how many trail systems have colored loops, or signed/colored loops made up of multiple "trails", and Trailforks (et al) has no concept of that. So the situation a user finds themselves in is being at a trail, with Trailforks up, wanting to follow the "Orange" loop (for example), and Trailforks doesn't show that.
Hopefully the "Orange" loop is documented as a route, but this stuff often gets missed, and is still awkward since the image of the map still doesn't match the signs.
So my goal was to show the map close to what's physically there, use OSM data as much as possible, and filling in gaps for what OSM doesn't capture, rendering it all into a static map that also happens to work offline. For some specific examples, compare these two systems and their print, Trailforks, and trailmaps.app maps:
RAMBA: [1], [2], [3] Shelden Trails: [4], [5], [6]
There is the same kind of gap when compared to RideWithGPS, Strava, Gaia, etc.
And also, I'm a volunteer with our local trails non-profit. I want anyone and everyone to be able to find maps so they can enjoy the trails. A /lot/ of trail clubs are starting to replace maps with a link to Trailforks, which I believe does riders a disservice because it both requires an app and account and (if a user is trying to view a map out of their home area on a phone) payment. It's literally locking the basic info about a trail -- the map -- behind a semi-paywall. By making a system like this for our local trails I've helped completely avoid that mess. And so I made the map generator open as well so other techy folks can do the same or build on this.
This generated-static-map system does have the downside of being single-person-ish manually managed, and the maps do NOT update automatically. But I also see this as a feature, just like the print maps and in-person signage they are designed to complement.
I've prattled on a little more about the what-why-etc over here on my personal blog if you're interested: https://nuxx.net/blog/2026/06/25/trailmaps-app-map-generator...
--
[1]https://static.wixstatic.com/media/9d19d2_b85c5684f54a4fdc85...
[2] https://www.trailforks.com/region/ramba-trails/
[3] https://trailmaps.app/ramba/
[4] https://www.metroparks.com/wp-content/uploads/2022/04/2022-S...
[5] https://www.trailforks.com/region/stony-creek-metropark/
Our local trail association did that. Well, actually we went from an old “become a member to download GPS files” to “go find the trails on Trailforks”
But that was when Trailforks was more open and less locked down.
We’ve discussed replacing Trailforks with something better/more under our control, but haven’t gotten around to it.
And I think I got that. I like how mine does what it does (maps breaker panels and records home maintenance and stuff) without someone trying to sell me something.
But once I realized what advertising costs everywhere, I pretty quickly realized that app exists essentially just for me.
And that’s ok, but it’s a stark contrast from the goldrush years of (even garbage) apps making money.
The app review process is explicitly meant to keep out garbage apps.
Sounds like it worked as designed?
It didn't, because his admittedly garbage app ended up on the app store, because the app review process doesn't actually keep out garbage apps.
If anyone is interested, it's called HACK and I am writing this comment from it. Link is in my bio.
On the web side of things DNS only recently started being more private - 10+ years ago it was common to have your phone + postal address on whois.
Two take aways from my experience 1. I'm happy that I invested more in the web 2. The app store gives you distribution - I have a few websites with almost 0 traffic, but the app I wrote gets a handful of downloads a week almost 2 years later?
This is the .dk TLD today, and it's the reason I've never posted my website here. The .dk registry (punktum.dk) is run by absolute clowns.
On the other hand, the first thing I do before spending money on a danish website is "whois eksempel.dk", and if it doesn't return a danish address (and wasn't created recently), I'm out.
I don't remember the source or methodology for that number, but I have no trouble believing it. An app gives the developer a foothold on the user's device. It can more easily send notifications, track the user's location, resist customization like ad blocking, and remain present on the user's device even when closed. It's easier to funnel users into profitable behavior with an app.
Companies wouldn't do this if a large fraction of users refused the app, but most users don't.
On well implemented mobile websites, Google password manager pops up as does Google pay, can even authenticate with my fingerprint, zero friction. Theres zero need for an app.
And that's coming from a millennial who used to buy big ticket items on the PC.
I've had to use this a few times when on my phone to be able to actually access the webpage.
I do like local native software, preferably using the native UI toolkit, filesystem and features of the device hardware not necessarily available to the browser. That doesn't describe most commercial mobile apps in 2026.
Drug sales are often profitable.
The short version: ad blockers work on browsers but not apps[0].
Apple did that because they want their sweet 30% from in-app purchases, which they couldn't enforce in PWAs.
[1] https://en.wikipedia.org/wiki/Progressive_web_app
[2] https://infrequently.org/2015/06/progressive-apps-escaping-t...
[3] https://trends.google.com/trends/explore?q=%2Fg%2F11bzxympx6...
https://web.archive.org/web/20071012231544/http://www.apple....
https://web.archive.org/web/20071012025941/http://www.apple....
I am not sure about the history, but a lot of it now is about tracking, and perceived security. Its far harder for users to manage things like location tracking in apps than in browsers.
i don't want to pay for servers just to have an app.
and updating apps is slow, for flutter you need to pay for shorebird.
In react native land, not sure but there are paid stuff like expo? you can self host but usually you end up payign for some OTA provider?
The only reasons I'll use an app over a website is if I have no choice in the matter, or if the app provides an easier UI/UX than the website.
Apps like YouTube are an exception, but there are other ways around that on Android.
Have DoH/DoT enabled as you mention, then open brave, go to YouTube.com
Web traffic is so diluted and low signal.
Thie assertion is extremely funny to me. Historically we come from an "app culture". Back in the day, around 2000 or so, if you wanted some functionality, you ran an application. You ran software in your computer.
Then on the early 2000s people started migrating their software web" , inventing "SaaS" (software as a service" .
I remember my young self being strongly opposed to that, because I saw little sense in constraining what you could do with a scripting language, when you could easily get the "networking" capabilities adding tcp/ip to your software .
But the web and Javascript won, mostly due to control (there was advertising in software since the 90s, for example Opera or GetRight had ad banners) .
The feature and mobile phones came and people started to migrate to "apps" again. So we came full circle.
Native apps would be the better platform in my eyes if the Operating Systems would be better in terms of letting a user manage what a native app have access to and can do.
But currently they are preferred by companies despite more dev effort because they can get more user data without the user having easy ways to prevent that. And of course showing ads without the user being easily able to block them
Possibly not even that: just a dumb terminal sending keystrokes & displaying text returned by the server.
Setups like this have been around almost as long as computers exist.
I recall that these replaced library catalogs in the form of drawers full of cards. Each card representing a book located elsewhere in the library (or available upon request from a central location). Man I'm old...
In the 2010s the model inverted: now you need to keep an entire browser open to use google chat, and people try to get you to install an app to read a web page.
In corporate IT, for instance, you have to roll out new versions of software all the time. There are better solutions for managing desktop fleets than there were back then, but with a web app you just update the server and... you're done!
- well-designed apps retain enough state to be useful offline or in places with spotty coverage; PWAs can kinda be made to work like this but IIRC iOS will happily evict them under disk pressure;
- notifications. I've read that Apple have implemented them for home screen installed web apps but for reasons unknown I have not seen this in action even once.
IMO the reason we got to this place is twofold:
- apps give companies a spot on your Home Screen and allow you to develop a habit of opening it. I suspect Apple are very aware of this, which is why they continue to make it very difficult to install a web app to your home screen.
- notifications. Which, again, draw a returning audience
It depends where the ads come from. I block ads at the DNS level for example, and there is little apps can do (I also filter public DNS servers by IP to prevent bypass). Not that would use apps that show me ads, or really any commercial apps. If something cannot be done in a browser, I'll simply pass.
Businesses have the incentive to give their users that low friction experience (at the point of need) using already familiar rails (i.e. "install app from app store").
The makers of both iOS and Android treat the ability to "bookmark" a web URL onto your home screen as a power user feature that requires navigating through complex, technical-sounding menus. Does it have to be like that? Of course not. They just have a business interest in pushing users away from the open web and towards their walled gardens.
--
Mind you, I'm not saying, "advertising doesn't play a role in this". A clump of well aligned motivations is obviously going to be more powerful than a single isolated motivation. But let's not forget that apps built for non-technical users, which—I cannot stress this enough—IS MOST USERS, benefit greatly from lowest common denominator solutions where they never feel like they have to learn anything to get going.
I’ve worked on projects where we ran this experiment, and the success rate of “install this app and click on it” is several times higher than “navigate to this webpage every time you want to use our tool”.
One small correction though, android has made it easier to add a “progressive web app” to the home screen now. You can prompt the user with a dialog asking if they want to install it. I think there was at least some period where Google was really encouraging PWAs. iOS still sucks. I’ve had very poor success rates in getting users to install our PWA using the iOS workflow (and our tool is something they need for their jobs, so they are highly motivated to install it).
Not the case on many Android browsers, you can present the user with a button to do this for them by listening for the `beforeinstallprompt` event. There are some requirements to meet for that, but it's a pretty user-friendly way to push your PWA to the home screen: https://developer.mozilla.org/en-US/docs/Web/Progressive_web...
I have published a few of them in the last few years, and I have tens of them which I haven't published. I use them for tons of different things:
* allowing only text tweets on X
* blocking photos and videos on all Meta products
* blocking explicit content
* customizing exchange rates for online shopping (Argentine peso, you wouldn't get it™)
* having reddit hot as default for the home and subreddits (they been pushing the "best" for a couple years and it's actually trash)
browser extensions have allowed me to regain some of my cognitive sovereignty while being a heavy internet user.
Virtually every company will treat it as a negative as the first thing most users are going to do if you allow them 100% experience customization is remove all the ads.
Most web apps suck too though so I guess pick your poison. My strong belief is they want apps because they can spam you with notifications to get your attention.
I believe the same about the Youtube App, I just can't see why else it exists and I hate the video links try to open in the app if you're not careful!
Vinegar is a Safari extension that fixes that on iOS and macOS. May exist for other browsers as well.
Apple doesn't let other browsers use their own engine on iOS (unless you are located in the EU).
uhh wow. How did Microsoft face antitrust lawsuits for merely bundling IE when Apple is literally forcing their browser?
And a nice side-effect of that is that YouTube doesn't throw away the list of other videos on the page you came from!
Uninstall (disable) the app, YouTube on Firefox mobile is fine.
Like the OS native APIs that offer the very utility for these apps to even exist?
Integration with OS features is what made the app ecosystem, because of utility. Project whatever conspiracy on that you want.
You think a developer making money from their app is a conspiracy? Or that apps track you and developers monetize that data is one?
I don't think you're being intentionally obtuse anymore.
Push notifications.
> Integration with OS features is what made the app ecosystem, because of utility.
This is true of some apps, like the beer-drinking one that uses the accelerometer / other orientation sensors.
It's not true of a large number of other apps, hence the "your app could have been a webpage" charge. This is distinct from "every app could be a webpage".
https://developer.mozilla.org/en-US/docs/Web/API/Push_API
> hence the "your app could have been a webpage" charge
No debate there. I was responding to the ever vague and broad "they want" comments.
Responding but never answering to anything. You were asking a bunch of questions with obvious answers that you should have known or could have discovered yourself, but expected others to dig out and chew them for you. You even went to ridiculous lengths to pretend that apps only do things "because of utility" and everything else like data collection, tracking, ads, etc. is "conspiracy". That's negative value in a conversation.
https://apps.apple.com/us/app/loupe-what-apps-can-see/id6766...
Seconds since last reformat, number of times clipboard was used since last reformat, seconds since last reboot, dozens of other apps installed on the phone…
On Apple devices, so much is leaked to developers, and they will use it.
Loupe HN thread: https://news.ycombinator.com/item?id=48608645
Who are 'they' and how do you know what they want
The point I'm trying to make that these ever-prevalent 'they just want' remarks are superficial, uninformed, overly broad, and vague, to the point of having no point.
There are many benefits to native apps over web apps on mobile devices, depending on the use case. A conspiracy against the people need not be part of every developer's choice to utilize the native platform and associated app store for distribution.
I know there's lots of horrible companies out there (hi Meta!) who will drive you to their native apps just for performance of ads and 'engagement'. This doesn't justify the conspiracy thinking getting applied to native apps as a whole.
- No waiting for a page to load
- Home screen access (most don't know about bookmarking web apps)
- Discovery (where do you go to find PWAs?)
- Features (native apps have access to more platform APIs)
- Absence of browser chrome (more immersive UX), though on iOS the chrome can be removed from PWAs once bookmarked, using meta tags
- well written apps use less memory, battery, and bandwidth
- security: apps go through at least some review while a web app could change with every reload
- scripting: apps often expose more functionality to Apple Shortcuts
- accessibility: the system accessibility features seem to work better with apps
- UI/UX: the best native apps are always going to be more responsive and feel better than the best web apps
Simple fact is that people love to project evil incentives onto entities they don't even bother defining.
Not every native app developer is a 'massive company' with a 'vested interest' (what does that even mean) in monetizing your attention and data.
All examples of first party social media clients.
A minority of native app developers, I'm willing to bet.
But, AFAIK, you need the server for push, though. It used to be possible to program entirely from the client with this proposed feature but AFAIK it's abandoned: https://github.com/GoogleChrome/developer.chrome.com//blob/m...
While the app is awake, sure.
I'd like notifications to work even if the OS backgrounded the app, and even without a network connection, like I'd expect a reminder to work.
> https://github.com/GoogleChrome/developer.chrome.com//blob/m...
Looks like this is what I need and it doesn't exist. So the short answer is "no". Thanks for the link!
That's not true. The browser's push service wakes the service worker on delivery, even if the PWA is fully closed. That's the entire point of Push API vs polling.
That's it, an app installed on a mobile device is a much more effective attentional hook than a website that must be either bookmarked or remembered. It is like inviting a door-to-door salesman to your house, of course they will take the invitation.
And the P in PWA has become "Personal" ... vibe coding apps with no backend for non-developers for their _personal_ needs e.g. a create a job hunting app for my son specific to the types of jobs he's looking for. If I update it, it updates on his phone plus he can sync to his laptop via WebRTC.
My strong belief is they realized people were prone to spending absurd amounts of money in Facebook games, so they hijacked "social gaming" and spent 20 years deteriorating in defense of it.
Consider this timeline:
- Apple launches iPhone in 2007 with web apps central
- Zynga launches "Zynga Poker" on FB in 2007
- Apple launches App Store in 2008 with single-purchase apps
- Zynga hits 40 million monthly users in 2009
- Apple implements IAP and defensive policies in 2009
- Hundreds of millions of people playing Facebook games in 2010
... Apple goes to war with, bans and eventually kills Flash, the core technology to these games, and all of it moves to mobile and IAP
... web apps deprioritized, arms race with other browsers prevented
Since my last smart phone broke, I have held out on getting a smart phone for personal use. Sure for doing professional stuff for work, I'll use the work phone, but NOT going to pay my own money to get a surveillance device now.
If you are a business, and the you don't have a web site working, then yeah too bad.
Until Ubuntu Touch or something similar catches up and can run on old smart phone in a reliable way (not having to hunt down ROM like LineageOS ) it will be going back to before 2007 for me. It is more inconvenient sometimes, but life is also better in many ways.
> It reports tracking data associated with your Google Account back to the developers.
Fortunately webpages never do any tracking whatsoever, let alone “Gobshite LLC and its 1131 partners need your permission for (contd. p94)”
Another lesson here is about how Adobe screwed that up when they had control, but then again they never wanted Flash they just wanted to kill Macromedia, by the time someone woke up over there it was way too late and even Air was too little too late.
Those are reasonable guesses, but as someone who was at Apple at the time (in developer relations, with Adobe/Macromedia among my developers), neither of those were Steve's primary annoyances with Flash. The actual annoyances were that the Flash runtime was (1) slow and (2) very crashy compared to the Windows version.
The former mattered because it created/reinforced a perception that Macs were slow. The latter mattered because it created/reinforced a perception that Macs were unstable, and it created a lot of expensive support calls. (For quite some time, the Flash runtime was the #1 cause of Mac crashes.)
There's more to this story (Adobe was threatening Apple on other fronts), but IMO Steve did the right thing by responding to a toxic partner in the way that he did.
If done for the right reasons, a native app could theoretically be a bit more power- and bandwidth-efficient for a given level of polish.
But usually what you're getting is some cross-platform mystery meat UI, a boatload of tracking, and no real system/OS integration (because it isn't trivial to do from whatever cross-platform environment they chose).
I want my phone to be the portal to the places I want to go to and the things I want to see. I want to have the same experience going to a web app or website I regularly visit as with a normal app.
Like, I want to click on an icon and be there. I don't want to click on the browser and then find the tab.
Also, I want PWAs and website shortcuts to be first class citizens. I want a normal icon, not one that has some sort of visual marker that it's not a normal app.
It's been an ongoing annoyance, but it's getting to be more commonplace of an issue because there are a lot of people building cool things on atproto, and they generally start as a web app before they maybe build a phone app.
This has nothing to do with ‘sharing’ something
By the way, the link doesn't load for me, so I used the archive to read it. https://archive.ph/ByFBN
Shipping a local app eliminates a lot of those headaches.
Open Safari, navigate to the web app, tap the Share button, scroll down, and select 'Add to Home Screen'.
No it's not. Hosting a web app is one of the most trivial things you can do these days, far more trivial than attempting to get an app into the app store. Hosting API's and Databases is a little more difficult but you still need those things if you're building an app.
There is no world in which getting your app signed, getting it approved, getting every update approved and paying $X/year to Apple or Google is easier than hosting a webapp, even if you host it in the most difficult way possible (on say AWS + Cloudfront). And even that method isn't that difficult, just moreso relative to other ways of hosting a webapp.
Make your website static and host it on a CDN. There's nothing expensive or thankless about it.
Stop over engineering.
Except it seems like plenty of apps these days are just vehicles to give web-based services some native abilities, so they're practically useless without a data connection.
What I want to know is: How many people actually used the website? How many people prefer the website?
It's easy to forget that many people use their computers (and phones) differently than the typical HNer.
Also: I wonder how easy/hard it is to do this with an LLM / vibecoding? Seems like there could be a Napster moment for bad apps where the LLM installs the app in a sandbox and makes educated guesses about how to turn it into a simple website.
That said it seems like we're constantly coming across things that are sub par or sometimes broken on the web that work in native apps. E.g. autoplay, background playback (TBH this is a real pain on Android too [3]), notifications, and there's probably more.
For instance, I've spent a good chunk of time today and yesterday battling the address bar on mobile Safari, which sometimes animates up/down, changing window.innerHeight, while we're trying to run an animation, leading to some layout issues.
This is really unfortunate because for a host of reasons the web is so much nicer to develop for than the App Store/Play Store, and all of the missing features are things that browsers could support.
[1] https://treefortsystems.com [2] https://web.dev/articles/pwa-with-offline-streaming [3] https://dontkillmyapp.com
Apps are great for tools which the user needs to depend on regularly. A consequence of this is that apps shouldn’t change their UI too frequently.
> With only a couple of minutes experimentation I discovered that the app works by concatenating the username and password5 and using it in a URL of the form:
The example from the article:
> This summer, the kids’ performing arts school are singing and dancing in a show at Disneyland. We’re all very excited, but my excitement, at least, was muted a little when I was told to install the “Travelbound” app in order to get access to the itinerary, travel arrangements, and accommodation details.
I don't need an app for this or website for this. Just email me the information and let me put it in my calendar and then leave me alone.
No. Damn. Way.
I'm only surfacing two api requests that Costco's app is using, but even with a server as a middle man between the browser and Costo's backend this is way faster than the app.
We worked hard so you don't have to vibe code your way to get the experience you prefer.
Like on most other technical opinions this person has I probably agree, but they're so absolutely wrong (for the majority of modern consumers you will fail without an app) that it makes me wonder what other seemingly obvious things we're both completely wrong about.
There's a weird conspiratorial thing that people do about this whole topic that is so easily debunked. For instance "Apple wanted apps more than PWAs!". Android powers about 73% of the world's smartphones, yet PWAs are irrelevant on the platform.
Web apps can be incredibly powerful, but there's just a massively lower bar in the web app domain, historically. Like people are used to the website being dogshit, a mishmash of broken functionality, terrible layout quirks, slow responsiveness, and so on. Because that is generally acceptable to the web community, where it is deadly to an app.
Like I think it's hilariously ironic that the website telling us that the app could have been a website is currently completely broken, unable to handle a relatively tiny amount of traffic.
Businesses have an app developed because they feel the market demands it. Their marketing departments feel they have to be able to tell prospective customers "we have an app!" and if they can't, they feel they'll be seen as inferior, not with the times, thereby losing customers.
I totally agree with the article that apps shouldn't be the automatic first choice, but that's the way it is. We've reached the stage where it's seen by users as the default. App icons on the homescreen can be seen, for many, as the modern alternative to bookmarks in the browser. And regarding "sharing a slick URL isn't always easy", perhaps the App Store is, for many users, the modern alternative to Google Search?
Businesses started advertising that they had an app because user's preferred apps, having had so many poor experiences with websites and web "apps" that the entire field was tainted.
This is 100% a "made your own bed" kind of thing. Again, the general standards among web apps for years were terrible, and users became accustomed that using a website on a mobile device was a brutal experience. Things have gotten a lot better, and honestly AI tooling should massively improve the space, but people really need to be honest about root causes.
I mean...a local grocery store advertises their "app" and it's just their website wrapped into a webview, and it is just total dogshit. Because they brough the extremely poor standards they have in their web domain into the app domain, and it simply doesn't transfer.
https://dennisforbes.ca/blog/microblog/2026/05/terrible_mobi...
Apps initially looked like the fancy thing to do (so marketing departments loved them), and very quickly snowballed into becoming simply "the way it's done" on mobile.
Most of them are just their website wrapped into a webview. They're sometimes awful, but they mostly do the job well enough - exactly as well as if it was a website instead (coming back to this thread's article).
Such as? Give some examples, which should be easy given that it's "most", right?
In the linked piece it details one that is so exceptionally trash that it is universally hated. I mean, ostensibly it isn't even allowed by appstore / play store rules, and it's a shit, lazy thing to do.
My thesis is that the standards for web teams were often much, much lower than for app teams. Where tolerance for shit, tolerance for slow and inconsistent behaviours, and so on was just much, much more common.
That is why there was such a fracture. And it's why the "webview wrapped website" is universally reviled trash.
Do websites have to be bad? Of course they don't. But the norms of the realm made users jaded.
I guess you haven't used the mobile web? Practically any website you use covers half the page with a banner saying don't use the website, the app is SOOO much better.
That ought to work better for people who don't have fancy phones and data plans. I've heard they exist somewhere.
However, there's a lot of stuff that does, indeed, require a native app.
That's the stuff I like to do. Doesn't really scale to Web pages.
Definitely nah. Life’s too short, and I’m already in the back nine.
Sorry. I should have known better, and refrained from commenting at all.
My bad. I thought it was a serious attempt at engagement. I enjoyed the post, and didn't really read the comments before posting.
Have a great day!
> Never wrestle with a pig. You both get dirty, but the pig likes it.
I've been wanting to write an article on a very similar topic myself for some time now. Perhaps I'll finish it and share it here. Absolutely done with this modern 'convenience' and app culture.
Full circle.
I remember when people were complaining that native was smaller, faster, and had richer accessibility integration.
yikes
If the app just shows a webpage then no.
One criticism, though: I wish you would have made a simple form-based alternative to the app's population mechanism, rather than just make the one-off consumer for yourself(/those you shared with). Definitely way more work and not something you should have to do. But that would have been a cherry on top. Not only prevent needing the app for viewing, but also removing future incentive for an organization turning to an app like that in the first place.
Yeah, I considered that. I even wrote the code in such a way that it supports that. But I'm concerned about the legality of distributing it. Given that it hits API endpoints that were expected to be private to the developers' app, giving away a "tool" that bypasses the app (which hosts ads, albeit for their other products, and so serves as a money-maker for the app's owner) could be illegal.
At the very least, it could be a violation of the terms of service or just an annoyance to the app developer, either of which could lead them to trying to stop me from doing it, which would be an inconvenience. So maybe I'll wait until after the trip, when the page becomes useless to me, and THEN open-source it!
I know hosting an entire sign up process and user content is not something you can just build and forget about, so my thought was that a sufficiently decent website could bundle a package that could be hosted on existing organization infrastructure. A zip file of the user's content that they could upload to dropbox/drive/sharepoint/etc. Then the consumer page would match a url slug to a package file and serve the content that way.
It's... a lot of stuff for a quick workaround project. And it's a pathology of an engineer to make solutions where solutions aren't needed. So grain of salt on any of that. But I did want to clarify since you were willing to engage with the concept, as understood. Hopefully this proposition strikes you as less concerning/illegal! I never want to steal anyone's work or infrastructure. I just believe that better alternatives - even ones borne of seeing how badly other people are doing it - can and should win out, if people ever provide them.
What annoys me is not that "this app could've been a webpage". It is that "this app should also have a web version".
TripIt comes to mind as the opposite way: they started as a website only, and quickly the need to have an app was obvious: GPS integration, offline access, contact list for sharing, and more.
It's ×(multiplication), not +(plus). Interface is not simply overlaid on Information; it actively changes how information is perceived and used, thus User Experience (UX).
Users have limited screen space, attention time, context retention, etc. So, apps must be wise about what information matters at any given moment, and make the best out of those limited resources.
Developers have been crazy about this: A/B testing, CVR, retention, churn, LTV, ARPU, DAU/MAU, North Star Metrics. Deploy and analyze, develop and optimize, rinse and repeat, and apps end up as revenue-generating machines.
A side effect of this optimization loop is that, apps become a designed thinking process for users. Apps decide what to show, what to hide, what to emphasize, and what comes next. They actively shape how people see and think, all to lure them into spending money.
So, "this could have been a webpage" misses the point of what apps are for, and, by extension, who apps are for.
Still, I see a bit of potential here. Document is a natural user interface -- almost all apps, including even SPAs, have document-like or document-driven views. Perhaps we've been too obsessed with computer-program-like UI. Documents can always be dynamic and interactive without being overdesigned. Perhaps this is what folks wanted to point out.
While I'm at it, also screw mozilla for messing up the browser history so badly.
I think the answer is "only when there is no native app for the system I use", ie Linux.
So FOSS people want for apps to become much worse for everybody else, so that they can have the apps also through a web browser. Remembering that everybody else is who pays for the apps and all development, while FOSS people will never pay a dime to software developers.
And there are now solutions that are very similar or the same on Linux (flatpak, appimage, snap with their very degrees of isolation). Windows, I will admit, I don't know much about it, but it may be the odd one out on this.
I've been in the room when companies talk about web vs. app. It's always a business decision that basically comes down to "The LTV of app users is higher, because we live rent-free on their home screen and we can push notifications to get people to re-engage." Doesn't matter what company: apartment searches, rideshare, communications app, etc.
The reason I will always prefer web experiences is because:
* I have a user agent that I can configure the behavior of. I can examine, and even change, app behavior to suit my needs. I can intercept and black-hole telemetry. I can remove distracting UI elements. uBlock Origin allows me to do this. Vimium gives me a keyboard-centric interface to help avoid mouse usage, since lots of mousing gives me RSI.
* I write web apps that are self-contained HTML files. These are awesome because they endure. An app written that way will open in 20 years just as well as it does today. Tiddlywiki is a living example of this.
* Browsers provide a baseline of functionality: selecting, cutting, pasting, and editing all work the same (or can be made to). Apps randomly prevent me from selecting text, or pasting a password.
* Apps are a constant treadmill. Staying up to date with APIs and app store fees and reviews all cost money, which means apps have to make money. This discourages hobbiest coders from releasing cool tools like the did 15 years ago, but it's those apps, the ones made for fun or utility, not for profit, that tend to behave the best. App stores are selecting against the very thing that brings me the most value, in favor of what brings them the most value.
* Finally: control. App stores increasing think they should not only vend money-making software, but they should be the only source where users can go to get functionality. I reject this outright; it's my computer, I decide what runs on it. The web is the last bastion of this on mobile, so I prefer the web.
The question should be reframed in the opposite direction: why do apps need to be siloed into multiple incompatible systems (appstores).