AI & the Future of Web Apps¶

AI changes four things about how you build and ship a Progressive Web App: where inference runs (on the device, through browser-provided models, WebGPU and WebNN, or in the cloud), who uses your app (people, and now agents acting for them), how people find it (app stores, search, and increasingly chat assistants), and what it costs to build each client (AI coding tools make both web and native code cheaper to write, but not cheaper to maintain or distribute). This section documents the web platform side of all four with the status of every API as of September 2026, and ends with an evidence-based analysis of whether the AI era favors native apps, PWAs, or both.

Key takeaways

Browsers now ship language models. Chrome's Translator, Language Detector and Summarizer APIs have been stable on desktop since Chrome 138, and the Prompt API since Chrome 148. They run on desktop only (the Gemini Nano-backed Summarizer and Prompt API also need capable hardware), and WebKit and Mozilla oppose the Prompt API, so every built-in AI feature is a progressive enhancement.
Native platforms expose more of the device's AI. Apple's Foundation Models framework (iOS 26+) and Android's ML Kit GenAI APIs on AICore give apps the system model on supported phones, tablets and Macs. The web has no equivalent on iOS or Android as of September 2026.
Cloud inference is platform-neutral. A PWA calls the same model APIs as a native app. Streaming, cost control, privacy and offline behavior are architecture questions, not platform questions.
Agents are a new kind of client. Browser agents operate your UI, chat assistants call your tools through the Model Context Protocol, and OS assistants call native app actions (App Intents on Apple platforms, AppFunctions on Android). WebMCP, in origin trial in Chrome 149–156, is the web's proposal for the same idea.
AI coding lowers build cost on both sides. It narrows the "one codebase is cheaper" argument for the web without removing it: store review, release trains, the long tail of old native versions and per-platform testing still cost what they cost.
In this section's analysis, the web's structural advantages grow, not shrink, with agents. URLs, zero-install access and instant updates are exactly what agents and chat assistants need. OS-level assistant integration and on-device models are where native still leads.

Why AI is a platform question, not just a feature¶

For most of the PWA era, the web-versus-native debate turned on a fixed list of capabilities: push, background execution, hardware access, installation, store presence. PWA vs Native vs Hybrid and When to Build a PWA treat that list in depth, and it hasn't gone away. AI adds three new dimensions to the comparison:

Access to models. A native app on a recent iPhone or Pixel can call the operating system's language model with a few lines of Swift or Kotlin, at no per-request cost and with no model download. A web app on the same phone cannot. On desktop Chrome it can, through the built-in AI APIs, and everywhere it can bring its own model through WebGPU or WebAssembly.
Reachability by software. Assistants and agents act on behalf of users. They reach native apps through OS intent systems and reach the web through URLs, HTML and, prospectively, WebMCP tools. What an agent can reach, it can recommend and operate.
The cost of building clients. When a coding agent can write a SwiftUI screen or a Kotlin repository class in minutes, the cost of maintaining separate native clients falls. It doesn't fall to zero, and it falls for web code too.

None of these points has a settled answer. The pages in this section give you the facts per platform and API, so you can decide for your own product, and the final page makes the argument explicitly.

On-device models in the browser¶

The web now has three layers for running models locally. They differ in who supplies the model, which hardware they reach and how far they are from being cross-browser.

Layer	What it is	Who supplies the model	Status (September 2026)
Built-in AI APIs	Task APIs (`Translator`, `LanguageDetector`, `Summarizer`, `Writer`, `Rewriter`, `Proofreader`) and the general `LanguageModel` (Prompt API)	The browser (Gemini Nano in Chrome; Phi-4-mini in Edge previews)	Translator, Language Detector, Summarizer stable in Chrome 138 desktop; Prompt API stable in Chrome 148 desktop; Writer, Rewriter and Proofreader in developer trial (behind flags) after their origin trials ended; none on Android or iOS
WebGPU	General GPU compute and rendering from JavaScript and WGSL	You, through a runtime such as Transformers.js, WebLLM or ONNX Runtime Web	Chromium 113+ desktop (Linux 144+), Chrome 121+ Android, Safari 26+, Firefox 141+ on Windows and 145+ on Apple silicon Macs
WebNN	A graph API that maps neural network operations to CPU, GPU or NPU through the operating system's ML stack	You, through a runtime or directly	W3C Candidate Recommendation Draft (September 10, 2026); behind a flag in Chromium; the Chrome origin trial announced for 147–149 was disabled in March 2026, and a new trial is listed for Chrome and Edge 156 (TBD)–160; no engine ships it by default

Support data as of September 2026. Check Chrome Platform Status, MDN and caniuse for live data.

The built-in models are the most convenient layer and the least portable. Chrome documents that the Prompt API needs Windows 10 or 11, macOS 13+, Linux or a Chromebook Plus, at least 22 GB of free space on the profile volume, and either a GPU with strictly more than 4 GB of VRAM or 16 GB of RAM with 4 CPU cores. Chrome for Android and iOS are "not yet supported". WebKit's standards position on the Prompt API is oppose and Mozilla's is negative, both citing interoperability among other concerns: two browsers shipping different models would give the same prompt different answers. Treat built-in AI as an enhancement that makes an existing feature cheaper or more private where it's available, with a cloud or non-AI fallback everywhere else. On-Device AI in the Browser covers each API, download and availability handling, and the bring-your-own-model runtimes, including the storage implications that Storage Quotas & Persistence and the Origin Private File System govern.

Cloud AI features in PWAs¶

Most AI features in production PWAs call hosted models, and here the web has no disadvantage: fetch() and streaming responses reach the same APIs a native app reaches, and the same backend serves both. What differs is the surrounding architecture:

Keys never ship to the client. Model calls go through your server or edge function, which holds credentials, enforces per-user quotas and strips data you don't want to send.
Streaming is the default UI. Token-by-token rendering over ReadableStream or server-sent events hides latency. Service workers must pass these responses through untouched rather than cache or buffer them (Streaming Responses).
Offline needs a policy. A PWA that works offline must decide what an AI feature does without a network: queue the request, fall back to an on-device model, or disable the control and say why (Offline UX & Fallbacks).
Hybrid routing is practical. Use a built-in or WebGPU model when it's available and the task is small (classification, short summaries, translation), and the cloud for everything else. The routing code is the same on every platform.

Cloud AI in PWAs builds these patterns with production code.

AI agents as a new client of your app¶

Until recently every client of a web app was either a person in a browser or a program you wrote. By 2026 there are three more:

Agent type	How it reaches your app	What it needs from you
Browser agents (built into or driving a browser)	Your rendered UI: DOM, accessibility tree, screenshots	Semantic HTML, accessible names, stable URLs, predictable forms
Chat assistants with tool use	Your API or an MCP server, sometimes with an embedded web UI	A tool surface with schemas; for UI, an HTML view that runs in a sandboxed iframe
OS assistants (Siri, Gemini on Android)	Native app actions declared through App Intents or AppFunctions	A native app; no web equivalent on iOS or Android as of September 2026

Two developments tie agents to the web platform specifically. The MCP Apps extension, the first official Model Context Protocol extension (January 26, 2026), lets a tool return an interactive HTML interface that the host renders in a sandboxed iframe, supported at launch by Claude, Goose and VS Code Insiders, with ChatGPT support starting the same week. The UI you ship into a chat assistant is a web app. And WebMCP, developed in the W3C Web Machine Learning Community Group, lets a page register tools through document.modelContext (early previews used navigator.modelContext) so a browser agent can call functions instead of guessing at buttons. Chrome Platform Status lists it behind a flag from Chrome 146 and an origin trial from Chrome 149 to 156 on desktop, Android and WebView; Microsoft Edge runs its own origin trial. Chrome Platform Status records no signal from WebKit or Mozilla.

Accessibility work pays twice here: the same semantic structure that screen readers use (Accessibility) is what agents that read the accessibility tree use. AI Agents & the Web covers agent-readable markup, WebMCP, MCP servers alongside a PWA, and the security model for letting software act for users.

How AI coding changes the cost of building native and web¶

The classic argument for a PWA over native clients is cost: one codebase, one release train, no store review. AI coding tools change the first term of that argument more than the others. Stack Overflow's 2025 Developer Survey reported that 84% of respondents use or plan to use AI tools in development and that 51% of professional developers use them daily, while more respondents distrusted the accuracy of AI output (46%) than trusted it (33%). Measured productivity effects are less clear than adoption: METR's randomized study of experienced open-source developers found that tasks took 19% longer with early-2025 tools, and its February 2026 follow-up reported estimates pointing toward a speedup with later tools while calling its own data an "unreliable signal" because of selection effects.

What that means for platform choice:

Writing code gets cheaper on both sides, including platform-specific code that used to require a specialist. Porting a screen from React to SwiftUI is the kind of well-specified translation task these tools handle well.
Everything that isn't writing code costs the same. App Review, Play policy compliance, annual SDK and Xcode minimums, crash triage on device models you don't own, per-platform QA, and supporting old app versions in your API don't shrink because code is generated faster. When to Build a PWA lists the recurring costs of each side.
Review becomes the bottleneck. Three generated codebases need three times the review, and reviewers need platform expertise to catch platform-specific bugs.

The net effect is that the extra native client becomes a smaller investment, which makes "PWA plus a thin native shell" and "PWA plus a native companion for one capability" cheaper strategies than they were. The future analysis works through the arithmetic.

Distribution: stores, search, assistants and chat¶

App stores, web search and links were the three routes to users for fifteen years. AI adds two: answers in AI search results and chat assistants, and apps embedded inside chat products. The web has a structural advantage in both, because an assistant can cite, open and operate a URL without an install, while it can only reach a native app the user already has, and through whatever actions the app has declared to the OS. Native apps keep the advantages they had: store discovery, store billing, and the OS assistant integrations on each platform. Publishing to App Stores covers how a PWA gets into stores anyway, and SEO for PWAs covers the indexing that AI search builds on.

Regulation changes the store side at the margins. The EU's Digital Markets Act and Japan's Mobile Software Competition Act allow alternative browser engines and alternative app distribution on iOS in those regions, but Home Screen web apps still run on WebKit everywhere (Platform Support). The European Commission's first DMA review, published April 28, 2026, listed "equal access of AI-based services to operating systems" among five AI-related themes, which may matter more for AI-era distribution than the browser-engine rules did.

What stays the same¶

It's easy to overstate the change. The foundations of a PWA are unaffected by AI:

A service worker still decides whether your app loads offline and how fast repeat visits are (Service Workers).
iOS still has no install prompt, no background sync and no hardware APIs (iOS & iPadOS).
Push, badging and OS integration still differ per engine (Platform Support).
The decision procedure in When to Build a PWA still applies: list must-have capabilities, map them to platform support for your traffic, and choose the lightest architecture that covers them. AI adds rows to that checklist; it doesn't replace it.

Pages in this section¶

Read them in order if you're new to AI on the web. The first three are implementation references; the last is analysis.

On-Device AI in the Browser

The built-in AI APIs (Prompt, Summarizer, Translator, Language Detector, Writer, Rewriter, Proofreader), hardware requirements and availability states, WebGPU and WebNN, and bring-your-own-model runtimes with model caching in OPFS.

On-Device AI
Cloud AI in PWAs

Calling hosted models from a PWA: server-side proxies, streaming UI, service worker rules for AI endpoints, offline queues, cost and rate limits, privacy, and hybrid on-device/cloud routing.

Cloud AI
AI Agents & the Web

Browser agents, chat assistants and OS assistants as clients of your app: agent-readable markup, WebMCP, MCP servers and MCP Apps, authentication and consent for delegated actions.

AI Agents
The Future: Native, PWA or Both?

An evidence-based analysis of the forces pushing toward native and toward the web, a dated capability comparison, labeled 2027–2030 scenarios, and a decision framework by app type.

The Future

Common pitfalls¶

Designing for built-in AI as if it were universal. It exists in desktop Chromium on capable hardware only. Build the feature so that it works without it, then use it to reduce latency, cost or data sent to a server.
Treating the model download as free. A built-in model is a multi-gigabyte, one-time download that the browser manages; a WebGPU model you bring is your download, counted against your origin's quota and subject to eviction.
Ignoring agents until they show up in your analytics. Agent traffic looks like odd human traffic until you look for it. Semantic markup and stable URLs cost little and help people as well.
Choosing native "because of AI" without naming the capability. If the requirement is a cloud model, the web has it. If it's the OS model on iPhone, Siri integration or background inference, native does. Write the requirement down and check it against the tables in the future analysis.
Assuming AI-generated code makes maintenance free. Generated clients still need review, testing on real devices, store compliance and version support.