WebGPU now available for testing in Safari Technology Preview

Apple’s move to enable WebGPU in Safari Technology Preview is seen as a sign it is accelerating WebKit development and preparing to compete more seriously with Chromium-based browsers, especially as EU rules may force it to allow alternative engines on iOS. Commenters expect WebGPU to unlock browser-based 3D graphics, gaming, and even on-device AI workloads, while debating whether this strengthens or undermines Apple’s App Store-centric model and the long-term role of native apps versus PWAs. There is also scrutiny of WebGPU’s security and performance implications, and of Apple’s strong influence on the standard’s design, which closely tracks its Metal API and favors a textual shader language (WGSL) over SPIR-V bytecode.

Apple’s WebKit Strategy and Browser Competition

  • Several commenters feel Apple is investing more in WebKit, closing the feature gap with Chromium and often leading on some JS/CSS capabilities.
  • Many link this to looming regulation (e.g., being forced to allow other engines on iOS) and Apple’s desire to avoid a Blink monoculture and dependence on Google.
  • Some argue Safari improvements are evolutionary rather than a sudden acceleration; awareness may simply be higher now.

PWAs vs Native Apps and App Store Dynamics

  • Debate over whether web apps will meaningfully displace native apps:
    • Pro-PWA side: PWAs increasingly match native capabilities (service workers, push, sensors, location), and many mainstream apps could be “just websites.”
    • Skeptical side: performance, complex UI controls, animations, and missing APIs keep PWAs inferior; iOS is where the money is, so developers will keep building native apps.
  • Monetization concerns: PWAs make one-off paid apps harder, pushing toward subscriptions or ads; some lament loss of simple, paid, offline-capable tools.
  • Some see stronger PWA/WebGPU support as a strategic hedge for Apple in antitrust and App Store regulation debates.

WebGPU Design, Metal Influence, and Implementations

  • WebGPU’s API is widely noted as very similar to Apple’s Metal; some see this as deliberate influence through standards bodies.
  • There was early, removed Safari support for an older Apple-style proposal before the current standard.
  • Disagreement over shader design history:
    • One side stresses Apple’s opposition to SPIR-V/binary IR and preference for text languages, influencing the adoption of WGSL.
    • Others note broader concerns (portability, security, shader compilation pain) and argue it wasn’t “Apple vs everyone else.”

Safari Quality, Bugs, and Release Cadence

  • Mixed experiences: some say Safari works fine and sites usually fail due to Chrome-only APIs; others report Safari-specific bugs (especially SVG, PWAs, wake lock, dark mode, z-index rendering).
  • Safari is partially decoupled from major OS releases, with significant web-platform updates in minor OS versions; still, iOS PWAs are described as fragile and sometimes regressing.

Security, Permissions, and Resource Use

  • Some worry WebGPU enlarges the attack surface and undermines prior timing-based mitigations; others ask for concrete evidence and see it as incremental risk.
  • Proposals to gate WebGPU behind a permission dialog (like camera/location), mainly to protect against battery drain and sketchy sites; others note it’s hard to explain “GPU access” clearly to users.

Ecosystem and Use Cases

  • Interest in:
    • Running LLMs and models like Whisper in the browser with WebGPU.
    • WebGPU as a cross-platform OpenGL successor via libraries like Dawn/wgpu, and possibly as a system framework on Apple platforms.
    • Better WebKit-based browsers on Linux (Epiphany/GNOME Web discussed, with sandboxing/memory and WebRTC gaps).
    • WebXR support, including on iPhone and Vision Pro, though future availability on phones is unclear.
  • Some hope WebGPU will help move Electron-style desktop apps and games to the web; others are unconvinced the web will ever fully match native.