676 Developers Are Furious: Your App Was Just a Webpage All Along

On July 9, 2026, British programmer Dan Q published a post with a provocative title: “Your ‘App’ Could Have Been a Webpage (So I Fixed It for You).” The piece lit up Hacker News, drawing 676 developers into a heated debate with 420 comments — blowing straight through the thin veil separating App Store economics from the open web.

The story starts with something mundane. Dan’s child was headed to a Disney performance, and the tour company required parents to install a mobile app called “Travelbound” just to view the itinerary. Dan checked the app’s size — a 43MB install that ballooned to 124MB once on the device. As a programmer of more than a decade, he found it absurd: I just want to see a schedule. Why do I need to download an app bigger than Super Mario?

So he did what programmers do best: reverse-engineered it.

What’s Actually Inside a 124MB App

▲ This is the 124MB Travelbound app — its job is to display a bunch of text, images, and PDF links. Source: Dan Q’s personal blog.

Dan intercepted the app’s network traffic with a packet-sniffing tool and uncovered a truth that was equal parts funny and depressing: the only thing this app does is concatenate a username and password into a URL, fetch a pile of data from the server, and render it on screen.

Specifically, the logic behind the app looks like this:

https://travelbound.api.vamoos.com/api/itineraries/{username}-{password}

The server returns a big chunk of JSON — an itinerary list, lodging details, PDF download links, accompanying images. And that content is itself wrapped in HTML. In other words, the app’s server is already producing web pages; it just chose to stuff them inside a 124MB shell before letting you see them.

▲ The intercepted server response — note the itinerary data already exists in HTML. Source: Dan Q’s personal blog.

So what exactly fills those 124MB, bloating something that’s essentially a “webpage viewer”? Dan found the app adds only two things beyond what a webpage would:

1. Tracking your Google account, feeding usage data back to the tour company
2. Pushing ads (the official euphemism is “travel inspiration”), nudging you toward buying more trips

Dan put it more bluntly: these two additions are “anti-features” — all downside, zero benefit.

From 124MB to 0.05MB: A Webpage Was Enough

Dan spent half a day writing a small Ruby script that periodically pulls the latest data from the server and auto-generates a plain webpage version. The result?

• App version: 124MB (tracking and ads included)
• Web version: a 0.05MB HTML page, plus some optional images (35MB, which you can choose not to download)

The web version is password-protected and uses the same account as the original app. It has no fancy interface, but you can copy-paste it, print it, save it to your phone, and open it on any device — exactly the things the original app couldn’t do.

▲ Dan’s own web version — ads and tracking stripped out, all core info retained. Source: Dan Q’s personal blog.

Dan ended with a soul-searching question:

“Some apps genuinely need to be apps. Travelbound is not one of them. I can’t understand how we got to a point where software companies make their own lives harder (and more expensive: getting on the App Store isn’t cheap!) just to push HTML content at fewer people, with fewer features.”

How Did We Get Here? Apple Economics

Dan’s confusion hides a bigger question: why, when a webpage would do just fine, do developers insist on packaging everything as an app?

In the 676-comment Hacker News thread, the top-voted comment cut to the core — Apple and Google have spent billions of dollars reshaping ordinary people’s mental model, convincing them that “doing things on your phone = using an app.”

Think about it: when an average person picks up a new phone, what do they see on the home screen? Row after row of app icons. Need to find something? Open the “App Store.” Want to use a service? “Is there an app?”

This “apps-are-everything” mindset didn’t form naturally. It’s the product of fifteen years and two tech giants spending real money to hammer it into us.

And the driving force behind it is money — specifically, the famous “Apple tax.”

The Apple Tax: The Economics of a 30% Cut

For any app or digital content sold through Apple’s App Store, Apple takes a 15%–30% commission. In 2024 alone, the App Store generated over $85 billion in revenue for Apple (based on Apple’s own disclosures and financial figures made public during the Epic Games litigation). Across the entire internet industry, you’d be hard-pressed to find a second “toll booth” this profitable.

And the web? The web is open. Anyone can publish a webpage without paying Apple, without passing Apple’s review, and users open it directly in a browser. If a service exists as a webpage, Apple gets nothing.

That explains why Apple has, deliberately or not, made web apps “worse” on iOS:

• Every browser on iPhone must use Apple’s own WebKit engine — even Chrome and Firefox are just Safari wearing a different skin. In June 2026, Microsoft engineers published a benchmark report showing that if Chromium were allowed to run on iOS, browser performance could be 28.6% higher than Safari’s.
• Web apps (PWAs) on iOS can’t use Face ID, can’t sync data in the background, and face severely restricted push notifications — precisely the features many apps sell as their core value.
• Safari lags Chrome by months or even years on web standards support — want to use a new technology? Sorry, wait for Apple to catch up.

In Europe, the Digital Markets Act (DMA) is trying to break this open by requiring Apple to lift its browser-engine restrictions. But Apple’s response was described by a US judge as “malicious compliance” — it changed the rules on the surface while erecting a series of technical hurdles that keep competitors from genuinely entering.

The end result of all this? Developers are “forced” onto the App Store boat, and users are “spoiled” into recognizing only app icons.

The Other Side of the Debate: Some Scenarios Really Do Suit Apps

At this point, I have to state plainly: this is not an “apps are original sin” piece. In the HN discussion, a fair number of developers pointed out scenarios where apps genuinely beat webpages:

A programmer named OkayPhysicist shared his experience: his company had an internal reimbursement and documentation tool, which he built as a mobile-friendly webpage. The result? Coworkers chased him asking “how do I put this website on my phone?” “How do I open a website on my phone?” “Can you make it an app?”

The problem is habit. For most ordinary users, “app” is an understandable concept, while “webpage” is abstract. Asking them to type a URL into a browser’s address bar feels less natural than tapping a colorful icon.

Another developer made a good point: if you use a service a dozen times a day, a standalone native app really is more convenient than jumping in and out of a browser. WeChat, Alipay, maps — in these high-frequency scenarios, an app’s performance edge (faster response, smoother animations, offline capability) is real.

There are also scenarios web technology still struggles to cover:

• High-performance games: need GPU acceleration and complex 3D rendering
• AR/VR apps: need deep access to cameras and sensors
• Professional audio/video editing: need real-time processing and hardware codecs
• Services that must run continuously in the background: fitness tracking, navigation

These are reasonable boundaries for web technology. I don’t believe everything should become a webpage, but I equally don’t believe everything has a reason to become an app.

The Real Issue: Not a Tech Debate, but a Power Struggle

This “App vs. Webpage” argument is, at its core, a struggle over who gets to decide what software you can use.

In the open-web world, you publish a service with a URL, and the browser is your “app store.” No one reviews your content, no one skims your revenue, no one decides whether your product gets to “shelf.”

In the App Store world, Apple and Google are the gatekeepers. They decide what passes review (500 reviewers overseeing 2 million apps), they decide the cut (15%–30%), they decide which phone features your app may use. Users do get a certain “safety guarantee” — at least in theory, what’s in the App Store has been reviewed — but the price is the loss of choice.

This is the deeper reason Dan’s post enraged 676 people: the whole system is designed this way — turning what should have been a 0.05MB webpage into a bloated 124MB app. The travel app itself isn’t bad; the system forced it down a bloated path.

Epilogue: What’s Your Choice?

Dan’s story has a warm ending. He shared his homemade web version with the other parents on the performance team, and for the first time they realized they could see the itinerary without installing that bloated app. When his daughter sang and danced on the Disney stage, his phone had one fewer 124MB tracker on it.

For us ordinary people, the lesson of this story is simple: next time someone tells you to download an app just to look at something, ask one extra question: couldn’t this have been a webpage?

Because often, the answer is yes.

---

Reference Links:

• Dan Q: Your “App” Could Have Been a Webpage (So I Fixed It) — personal tech blog
• Hacker News top discussion: 676 comments debating App vs. Web in depth
• Microsoft engineer benchmarks: iOS browsers lag 28.6% due to WebKit restrictions
• Report on Apple’s WebKit restrictions and EU DMA compliance dispute
• PWA limitations on iOS and Safari support status (2026 complete guide)
• Apple’s 30% commission policy changes: fallout from the Epic Games antitrust suit
• App Store review system controversy: the reality of 500 reviewers and 2 million apps
• Open-web advocacy groups: the anti-competitive impact of Apple’s browser-engine restrictions