What PWA Can Do Today

Original Article ↗ Hacker News Discussion ↗

Progressive Web Apps (PWAs) now expose a wide range of device capabilities—push notifications, offline use, camera and barcode access, file APIs and more—making them a plausible alternative to native mobile apps for many use cases. Commenters weigh these benefits against major drawbacks: uneven browser support (especially on iOS and non-Chromium engines), Google-specific APIs that aren’t web standards, security and privacy concerns, and frequent UX flaws and performance issues. The result is a split view of PWAs as either a promising way around app-store gatekeeping and multi-platform development, or a fragile, browser-dependent layer that too often fails to match native apps or simple, traditional websites.

Overall sentiment on PWAs

  • Thread is sharply split: some see PWAs as the right direction for cross‑platform apps and a way around app‑store control; others see them as overhyped, fragile, and often worse than either native apps or plain websites.
  • Supporters highlight lower development cost (one codebase, web skills), instant global reach, kiosk/in‑house deployments, and “good enough” UX for many business apps.
  • Critics emphasize unreliable behavior, bad UX, JS bloat, and that many PWAs are just overengineered SPAs where a simple website would suffice.

Platform support and standards politics

  • Repeated theme: many showcased capabilities rely on Blink‑only APIs (Web Bluetooth, WebUSB, Shape Detection, Web Share Target, some Digital Goods flows).
  • Mozilla and Apple have explicitly rejected several of these on security, privacy, or fingerprinting grounds; some see this as justified, others as protectionism for app stores.
  • Concern that Google is effectively defining “the web” via Chromium, risking a de facto Chrome monopoly; counter‑argument is that Chromium is open source and still constrained by standards processes.
  • Firefox dropped desktop PWA/SSB support, which some see as a self‑inflicted wound.

Capabilities, use cases, and limitations

  • Concrete successes: internal PWAs deployed via MDM/Intune; camera‑heavy enterprise apps; media players; kiosk‑style setups; barcode scanning (with caveats).
  • Missing or weak areas: no standardized calendar API (workarounds via iCal/CalDAV), immature file system access (especially on mobile), limited or inconsistent Bluetooth/USB/serial, and historically poor iOS web push.
  • Some APIs exist but are buggy or only partially implemented (e.g., vibration on Firefox Android, file system and fullscreen camera access on mobile).

Installation, UX, and discoverability

  • iOS “Add to Home Screen” via the Share sheet is seen as non‑obvious and buried; Android’s install prompts are easier but can be spammy in theory.
  • PWAs installed per‑browser, inconsistent icon behavior (e.g., browser badges), and lack of share‑target support on iOS are recurring complaints.
  • Many users prefer browser tabs over separate “apps”; others like PWAs as standalone windows with taskbar entries and notifications.

Trust, monetization, and business angle

  • App stores are argued to provide a trust and payment layer users respond to (especially on iOS); PWAs need other patterns (subscriptions, web payments, Digital Goods APIs).
  • Some fear PWAs are a path to “ChromeOS everywhere”; others argue the bigger issue is escaping app‑store rent and gatekeeping.