HN Debrief

“It works better in the app”

  • Mobile
  • Privacy
  • Developer Tools
  • Open Source
  • Consumer Internet

The post starts with a very ordinary failure case: subscribing to a shared Google Calendar from a phone. The link opens the Calendar app, the app cannot do it, mobile web cannot do it, and the only working path is the desktop browser. That small annoyance landed because it captures a broader pattern readers know well. Companies keep claiming things “work better in the app” while shipping fragmented products where the app, mobile web, and desktop web each expose different chunks of functionality.

If your product can be used in a browser, forcing an app is now a trust and conversion risk, not just a UX choice. Keep a fully functional web path for critical flows, and treat app-only gating as a business decision that can push customers to competitors or abandonment.

Discussion mood

Strongly negative. People are tired of app-only gates, hostile mobile web experiences, and fragmented feature sets, and they overwhelmingly interpret the app push as a mix of tracking, notification spam, and organizational laziness rather than real product necessity.

Key insights

  1. 01

    Feature parity is the actual minimum

    The useful standard is not whether app or web is inherently better. It is whether a company that ships both can avoid sending users back and forth because each surface is half-built. That framing cuts through the usual app-versus-web tribalism and lands on a more damning point. Fragmented functionality is not an unavoidable tradeoff. It is a quality failure that companies have normalized.

    Audit your top user tasks across app, mobile web, and desktop web. If any critical flow requires surface-hopping, treat that as a product defect with an owner and a deadline.

      Attribution:
    • munificent #1
    • flerchin #1
  2. 02

    Native still has real edge cases

    The strongest defense of apps was not generic “native feels better.” It was specific capabilities that still break down on the web. Reliable NFC scanning for passports and identity documents matters because it proves the physical document is present and reads chip data directly. Persistent background location for things like tour guides is also still awkward on the web, even when foreground geolocation works. These are the kinds of cases where app-only can be justified without sounding like a pretext.

    If you are going to force an app, tie it to a capability users can recognize as genuinely native-only. If you cannot name that capability in one sentence, you probably should not gate the workflow behind installation.

      Attribution:
    • rcxdude #1
    • edent #1
    • pj_mukh #1
  3. 03

    Big-company UX breaks at the framework layer

    One credible explanation for obviously bad app behavior was not that nobody uses the product. It was that centralized design systems and platform frameworks get rolled across hundreds of products, and the local team no longer fully controls the interaction details. That produces absurdities like floating buttons obscuring real actions, inconsistent behavior between surfaces, and bugs that everyone notices but nobody owns. The result feels like indifference even when the root cause is organizational structure.

    When you standardize UI across products, assign someone to own the exceptions. A shared design system without product-level escape hatches will quietly ship broken workflows at scale.

      Attribution:
    • munificent #1
    • pjc50 #1
    • ChrisMarshallNY #1
    • dmayle #1
  4. 04

    PWA adoption fails on distribution, not capability

    Several builders argued that progressive web apps already cover far more ground than users realize. Camera, GPS, sensors, and installability are often good enough. The blocker is that ordinary users think an app lives in the App Store or Google Play, not behind “Add to Home Screen,” and platform owners do little to fix that. So teams either ship app-store wrappers around web code or build and maintain parallel clients mostly for discoverability and legitimacy.

    If your web app is already good enough, the main product problem may be onboarding and packaging, not engineering. Test whether clearer install prompts, better mobile polish, or a thin store wrapper gets you the adoption signal you want before funding a full native rewrite.

      Attribution:
    • _fat_santa #1
    • emursebrian #1
    • azuanrb #1
    • badc0ffee #1
  5. 05

    Power users are rebuilding browser control

    A notable slice of people are not just refusing apps. They are building technical workarounds to preserve a browser-first life. F-Droid, GrapheneOS, WireGuard, Unbound, Hagezi blocklists, RethinkDNS, uBlock Origin, and Firefox came up as a stack for reducing tracking and keeping services usable. That matters because it shows app resistance is not just aesthetic. For some users it has become an operational security posture.

    If your audience includes technical buyers, assume some will actively route around your app and trackers. A clean browser experience is part of trust, not just convenience, and it can affect enterprise and high-value customer perception.

      Attribution:
    • drnick1 #1 #2
    • safety1st #1
    • efreak #1
  6. 06

    Parking apps showed what good app optionality looks like

    The parking examples produced one of the clearest positive models in the conversation. People were fine with a city parking app when it was genuinely optional, did one job, let users stop sessions early, and still left kiosks or card payment available. That is very different from captive install flows that force account creation just to pay for curb parking. The distinction is not “digital bad.” It is “digital with no fallback becomes coercive.”

    For public or quasi-public services, keep a no-install path alive even if app usage is high. Once basic access depends on one vendor app, every outage, compatibility issue, and privacy concern turns into a service failure.

      Attribution:
    • a2tech #1
    • stackghost #1 #2
    • mikepurvis #1
  7. 07

    The real bottleneck is incentives, not coding difficulty

    People kept circling back to the same organizational diagnosis. Missing features like calendar subscription are not hard. They just are not promotion-worthy. Large companies reward visible launches, roadmap wins, and migration to the next thing. Maintenance, parity work, and edge-case cleanup get stranded. That explains why glaring defects linger for years even when everyone agrees they are stupid.

    If you lead product or engineering, create explicit incentives for polish work. Without budget, ownership, and recognition for maintenance, your app strategy will decay into permanent half-completion.

      Attribution:
    • iamkeithmccoy #1
    • blenderob #1
    • hombre_fatal #1
    • RichardChu #1

Against the grain

  1. 01

    Alternative apps can rescue bad web apps

    The anti-app line misses a real failure mode of web-first software. Some browser experiences are memory hogs, spin CPUs, break history, and become unusable, while a dedicated app can at least isolate that mess or offer a better client. The deeper complaint here was not that apps exist. It was that companies lock down APIs so third-party clients cannot compete with their bad first-party web products.

    If your web app is heavy and fragile, a native client may genuinely improve the experience. Also think hard before closing APIs, because third-party clients are often the pressure valve that keeps a service usable.

      Attribution:
    • cosmic_cheese #1
  2. 02

    Expanding the web also makes browsers worse

    Not everyone wants the browser to absorb more native capabilities. One line of pushback was that piling on WebUSB, WebHID, GPU access, and other APIs turns the browser into a giant attack surface and a de facto operating system. From that view, “just make it a web app” is not liberation. It is a technical and security trade that should face more scrutiny.

    Do not assume web parity is cost-free. If your product roadmap depends on powerful browser APIs, weigh the security and complexity burden alongside the convenience story.

      Attribution:
    • Quarrelsome #1
    • xboxnolifes #1
    • ethin #1
  3. 03

    Sometimes the whole security stack is the problem

    One detailed account argued that blaming apps misses the bigger failure. Fraud checks, ID verification vendors, banks, and account recovery flows can create impossible loops even when every step technically exists on the web. The Amazon identity check that effectively required a phone camera was less about app ideology than about brittle security theater stitched across multiple companies.

    When you design verification or anti-fraud flows, test them end to end on constrained setups like desktop-only, VPN use, and no smartphone. Security controls that strand legitimate users are operational defects, not edge cases.

      Attribution:
    • Intermernet #1
    • nickff #1
  4. 04

    Some vertical apps are plainly better

    A few people conceded that most apps are junk but pointed to domains where the app experience is actually polished and faster than the web. MLB ticketing was the clearest example. That matters because it keeps the critique honest. Users are not rejecting apps on principle. They are rejecting low-value apps that demand permissions, updates, and attention without earning it.

    If you want users to accept an app, invest until it is unmistakably better at a specific task. Convenience has to be obvious and repeatable, not hypothetical.

      Attribution:
    • ryukoposting #1

In plain english

F-Droid
An app store for Android focused on free and open source software.
GrapheneOS
A privacy- and security-focused version of Android for supported phones.
Hagezi blocklists
Popular filter lists used to block ads, trackers, and malicious domains at the DNS level.
NFC
Near Field Communication, a short-range wireless technology used for things like tap payments and reading passport chips.
RethinkDNS
An Android app and DNS service that can block trackers and route traffic through VPN-like tunnels.
uBlock Origin
A browser extension that blocks ads, trackers, and unwanted page elements.
Unbound
A self-hosted Domain Name System resolver that can answer domain lookups directly instead of using a public DNS provider.
WebHID
A browser API that allows websites to connect to Human Interface Devices such as keyboards, gamepads, or custom controllers.
WebUSB
A browser API that allows websites to communicate directly with USB devices with user permission.
WebView
A component that lets an app display web pages inside the app instead of building a fully native interface.
WireGuard
A modern virtual private network protocol used to create encrypted network tunnels.

Reference links

Progressive web apps and browser platform

Tools and workaround stack

Historical references on app culture

Privacy and mobile security

Books and essays

  • Tools for Conviviality
    HEY was linked directly in a comment about choosing tools that reduce daily frustration, alongside a mention of Ivan Illich’s book
  • xkcd 1367
    Referenced as a comic that captures the frustration of app and web fragmentation

Example products and demos

  • Earthview demo
    Shared as an example of a sensor-heavy web app that feels native to nontechnical users
  • sensor-js demo
    Linked to show that phone sensors are accessible from the web in modern browsers
  • OpenStreetMap
    Used as another example of geolocation and mapping working fine in the browser
  • Skatanica
    Shared as a mobile-first social web app built explicitly to avoid app installation

Payments and QR ordering

Surveys and adoption claims