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.
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.
- 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.
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.
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.
"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.
But of course...
> This is not supported on iOS.
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.
> 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 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.
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.
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.
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.
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.
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.
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.
I have no interest in installing a web app that could look innocuous today and be entirely different every time I hit F5.
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!
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.
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.
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.
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.
and failing at it, because that garbage got published on the app store.
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.
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
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.
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.
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
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.
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.
I wouldn't presume that. Malware ends up in the app store all the time.
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 (new handle bar), so the manufacturer is on the hook for that.
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)
That sounds like something that needs to be fixed.
> Contacting the developer by physical mail doesn’t have any effect.
Ditto.
That's an EU thing. If you don't publish in the EU you don't need to dox yourself.
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.
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.
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.
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.
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.
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.
It’s working. Your low quality project you weren’t really committed to got filtered.
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).
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.
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 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.
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.
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.
I've had to use this a few times when on my phone to be able to actually access the webpage.
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 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.
The short version: ad blockers work on browsers but not apps[0].
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
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!
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....
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.
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?
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
- 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.
Web traffic is so diluted and low signal.
Apps like YouTube are an exception, but there are other ways around that on Android.
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
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.
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’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).
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.
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.
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!
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?
Vinegar is a Safari extension that fixes that on iOS and macOS. May exist for other browsers as well.
Uninstall (disable) the app, YouTube on Firefox mobile is fine.
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
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.
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.
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.
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.
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.
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
Who are 'they' and how do you know what they want
- 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
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.
All examples of first party social media clients.
A minority of native app developers, I'm willing to bet.
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.
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).
> 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)”
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
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.
Open Safari, navigate to the web app, tap the Share button, scroll down, and select 'Add to Home Screen'.
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.
Shipping a local app eliminates a lot of those headaches.
Make your website static and host it on a CDN. There's nothing expensive or thankless about it.
Stop over engineering.
> 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:
We worked hard so you don't have to vibe code your way to get the experience you prefer.
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.
If the app just shows a webpage then no.
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.
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.
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.
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.
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.
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.
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.
Full circle.
I remember when people were complaining that native was smaller, faster, and had richer accessibility integration.
yikes
That ought to work better for people who don't have fancy phones and data plans. I've heard they exist somewhere.
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.
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.
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).
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.