Your App Could Have Been a Webpage - And One Developer Proved It

We have all been there. You want to check a flight status, view a restaurant menu, or access your travel itinerary - and instead of a simple webpage, you are forced to download a 50MB app that exists solely to deliver what is essentially formatted text. Dan Q decided to do something about it.

His blog post "Your 'app' could have been a webpage" documents the reverse-engineering of Travelbound, a travel itinerary app that his family was required to use for a trip. What he found confirmed every suspicion developers have about these unnecessary apps - and the Hacker News discussion that followed became a masterclass in why this pattern persists.

The Technical Breakdown#

Dan intercepted the app's network traffic using an Android emulator with root access, HTTP Toolkit for proxy interception, and Magisk to bypass certificate pinning. The findings were damning.

The app weighs 43MB on initial download, expanding to 124MB after downloading content. What does all that storage buy you? The app simply reformats JSON data already delivered via HTTPS. Dan's replacement webpage requires 0.05MB (plus an optional 35MB for images if you want them cached locally).

The app's functionality breaks down to: text, images, and PDF links. All of which the web handles natively.

The real kicker: "they're clearly producing HTML code anyway" - the server was already generating the content in a web-friendly format. The app was a wrapper around capabilities the browser provides for free.

Dan built a webpage replacement that offers everything the app did, plus several things apps cannot match:

• Copy-pastable text
• Printable content
• Saveable and bookmarkable pages
• Searchable content
• Usable on virtually any device
• Potentially more accessible

What Hacker News Is Saying#

The discussion thread hit 254 comments and surfaced years of frustration with app-ification.

The notification theory won consensus. Multiple commenters agreed that push notifications are the killer feature apps provide that companies want. One commenter put it bluntly: "My strong belief is they want apps because they can spam you with notifications to get your attention."

Another expanded: "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."

The tracking angle got darker. Beyond notifications, apps enable fingerprinting and data collection that browsers actively block. One commenter noted: "They want apps so they could fingerprint your device, spy on you and get a lot more information than a web app."

Someone linked to Loupe, a tool that shows what iOS apps can see - "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."

PWA disappointment ran deep. The thread became a collective mourning for what Progressive Web Apps were supposed to deliver. "We were supposed to be in the age of PWAs. That was the initial plan for iOS before the app store and 30% cuts on subscription apps."

Some defended the technical capabilities of PWAs - web push notifications work, service workers enable offline functionality, you can add to home screen. But adoption never happened, and commenters debated whether that failure was technical limitations, discoverability problems, or deliberate sabotage by platform owners who profit from app stores.

Platform lock-in accusations flew. iOS took particular heat for restricting browser engines. "Apple doesn't let other browsers use their own engine on iOS (unless you are located in the EU)" - meaning every browser on iPhone is Safari with a different interface. The comparison to Microsoft's antitrust troubles was raised: "How did Microsoft face antitrust lawsuits for merely bundling IE when Apple is literally forcing their browser?"

Real-world examples piled up. Commenters shared war stories:

• LinkedIn allegedly closes browser tabs to force app installation
• Ryanair requires the app for boarding passes
• Various retailers condition discounts on app adoption
• Reddit aggressively pushes its app and breaks the mobile web experience
• YouTube forces users toward the app despite the web version being fully capable

Some defended native apps. Not everyone agreed with the anti-app sentiment. Native apps offer real benefits: no page load delays, better performance, access to platform APIs, integration with system features. One commenter noted that users genuinely prefer apps for frequently used services, even when a website would suffice.

The Broader Pattern#

Dan's adventure exposed a truth about modern software distribution: many apps exist not because they provide superior functionality, but because they serve business interests that websites cannot.

Apps offer:

• Better user retention via home screen presence
• Push notification access for engagement hacking
• Richer analytics and fingerprinting
• App store visibility and discovery
• Ad monetization that browser privacy tools cannot block
• Platform lock-in that increases switching costs

Websites offer:

• Universal access across devices
• No installation friction
• Better accessibility defaults
• User-controlled privacy
• Linkable, shareable content
• No platform tax on transactions

The gap between what apps should require (complex offline functionality, hardware access, gaming, real-time communication) and what actually gets shipped as apps (menus, itineraries, loyalty programs, content viewers) reveals the incentive misalignment.

What Developers Can Do#

If you are building something that is fundamentally text and images - consider whether you actually need an app. PWAs have come a long way. Responsive web design handles mobile gracefully. Service workers enable offline access. Web push notifications exist.

If you are a user frustrated with app requirements - Dan's approach works. Network traffic inspection, API reverse-engineering, and building a custom frontend is within reach for technical users. Many apps are thinner wrappers than you might expect.

And if you are evaluating whether to force users into an app - be honest about whether the technical requirements justify it, or whether you are just chasing engagement metrics at the cost of user experience.

Sources#

• Original article: Your 'app' could have been a webpage (so I fixed it for you)
• Hacker News discussion (254 comments)
• MDN Web Push API documentation
• Loupe - What apps can see (referenced in thread)