The Future: Native, PWA or Both?¶

In this site's analysis, the answer for most products in September 2026 is both, in a specific shape: a PWA as the canonical, linkable product, plus native code only where a named capability requires it. AI strengthens both sides of the old argument at once. Native platforms now hand apps a system language model and a direct line into the OS assistant, which the web can't match on iPhone or Android. The web, meanwhile, is the surface that agents, chat assistants and AI search can reach without an install, and AI coding tools make the extra native shell cheaper to build than it has ever been. This page lays out the evidence for each force, dates every platform claim, separates facts from forecasts, and ends with a decision framework by app type.

The question, stated precisely¶

"Native or PWA" hides at least five different architectures. The comparison on this page uses the same vocabulary as PWA vs Native vs Hybrid:

The question this page answers: given what AI changes, which of these should a team building a new product, or re-platforming an old one, choose as its default in late 2026?

Two ground rules for reading the rest:

1. Facts are dated and sourced. Every platform API name and status was checked against vendor documentation or Chrome Platform Status in September 2026. APIs in origin trials or previews are labeled as such.
2. Forecasts are labeled. The scenarios section is analysis, not fact. So is the bottom line. Where the evidence runs out, the page says so.

Forces pushing toward native¶

System models on the device¶

The most concrete AI advantage native apps have in 2026 is direct access to a model the operating system already ships.

Apple. The Foundation Models framework, available from iOS, iPadOS, macOS and visionOS 26 (watchOS 27), gives Swift code "direct access to the same on-device model that powers Apple Intelligence" (Apple's WWDC26 guide) through SystemLanguageModel and LanguageModelSession, with guided generation into Swift types (@Generable) and tool calling (Tool). At WWDC26 in June 2026 Apple extended it: multimodal prompts with image input, a PrivateCloudComputeLanguageModel class (iOS 27 and the other 27 releases) for server-side inference on Private Cloud Compute, and a language model protocol that lets the same session API call third-party models. Apple's WWDC26 guide says developers can "work with any language model, including Apple Foundation Models, cloud models like Claude and Gemini, or any other provider that conforms to the Language Model protocol", and that apps in the App Store Small Business Program with fewer than 2 million first-time downloads "can access the next generation of Apple Foundation Models running on Private Cloud Compute at no cloud API cost". iOS 27 also added Core AI, a framework for running your own models "across the CPU, GPU, and Neural Engine", alongside the long-standing Core ML.

Three constraints come with it. The system model is available only where the device and region support Apple Intelligence, so every call needs an availability check and a fallback. Apple updates the model "in routine OS updates", and its documentation lists three model versions so far (iOS 26.0–26.3, 26.4 and 27.0), which means your prompts can behave differently after an OS update you don't control. And none of it reaches web content: Safari exposes no Foundation Models API to JavaScript, and WebKit's standards position on Chrome's Prompt API is oppose. The one system AI feature web pages do get on Apple platforms is indirect: since Safari 18.1, Apple Intelligence's Writing Tools work on editable text in web pages, as they do in native text views (WebKit).

Android. Gemini Nano "runs in Android's AICore system service, which leverages device hardware to enable low inference latency and keeps the model up-to-date". Apps reach it through the ML Kit GenAI APIs: Summarization, Proofreading, Rewriting, Image Description and a general Prompt API in beta in September 2026, with Speech Recognition and structured output in alpha. Device support is a list of specific models (Pixel, Galaxy S, OnePlus, Xiaomi, OPPO and others), and the Prompt API depends on which Gemini Nano version a device carries. One constraint is easy to miss: ML Kit documents that "GenAI API inference is permitted only when the app is the top foreground application". The native advantage is foreground access to a shared model, not background inference.

What the web has instead. Chrome's Prompt API reaches Gemini Nano from web pages, but only on desktop: Chrome Platform Status lists "Prompt API on Android" as proposed, and the Prompt API documentation says Chrome for Android and iOS "are not yet supported". A PWA on a phone can bring its own model through WebGPU or WebAssembly, with the download, memory and storage costs that implies (see On-Device AI in the Browser).

OS assistants act through native app actions¶

The second force is the assistant built into the operating system. In 2026 both mobile platforms rebuilt theirs around language models, and both route third-party functionality through native declarations.

• Siri AI and App Intents. Apple released Siri AI with iOS 27 on September 14, 2026, on Apple Intelligence devices (iPhone 15 Pro and later on the phone side), describing it as having "personal context understanding, broad world knowledge, onscreen awareness, and even more systemwide app actions" (Apple Newsroom). It launched in beta in English, with five more languages announced for the following month, and Apple says it isn't initially available in the EU on iOS, iPadOS and watchOS, or in China. Apps participate through the App Intents framework: entity schemas "contribute your app's content to the Spotlight semantic index", intent schemas let people act on that content in natural language, and the new View Annotations API maps views to entities for onscreen awareness.
• Android AppFunctions. AppFunctions is "an Android platform API with an accompanying Jetpack library" that lets apps "behave like on device MCP servers, contributing functions that act as tools" for agents and assistants such as Gemini. It requires Android 16, is labeled an experimental preview, and Google's documentation says that "as of May 2026, AppFunctions integration with Gemini is in a private preview with trusted testers".

Neither platform documents a way for a web page, a Home Screen web app on iOS or a WebAPK on Android to declare these actions. A user can ask Siri to open a URL, and assistants can search the web, but "do the thing in my app" requires a native app on both mobile platforms. If being invoked by the OS assistant is central to your product, this is the strongest AI-specific argument for native code, though a thin shell (see PWA-first with a native shell) can supply it.

Background execution for AI workloads¶

Long-running inference, transcription, indexing a user's documents for semantic search, or syncing an agent's work while the app is closed all need background time. Native platforms offer more of it. iOS 26 added BGContinuedProcessingTask, "a task that starts in the foreground and can continue running in the background as needed", on top of the existing background task APIs. On the web, a service worker is terminated when idle and each event has a time limit; Background Sync, Periodic Background Sync and Background Fetch are Chromium-only, and iOS offers nothing but push (Background Capabilities). A PWA that transcribes a one-hour recording on an iPhone does it while the app is open, or sends the audio to a server.

The caveat from the previous section applies: Android's system model is foreground-only through ML Kit, so "background AI" on Android means your own model or a server call, and the advantage is background execution in general, not background access to Gemini Nano.

Store distribution and payment rules¶

Stores remain where many users look for apps, and they remain the only way into certain surfaces: the App Store, device management catalogs, and in some categories the default expectation of users. For AI products specifically, two store-related factors matter technically:

• Paid AI features inside store apps follow store payment rules. Unlocking digital features in an App Store app requires In-App Purchase outside the regions and programs where Apple allows alternatives; Play-distributed apps, including TWAs, follow Play's payments policy (Publishing to App Stores). A PWA served from your origin in a browser is outside both.
• Inference cost can be subsidized by the platform. Apple's no-cost Private Cloud Compute access for Small Business Program apps with fewer than 2 million first-time downloads, and the on-device models on both platforms, shift inference cost from your servers to the platform. A web app pays for its own cloud inference except where a browser's built-in model is available.

The iOS web ceiling¶

Finally, the constraints that already made iOS the deciding platform for most PWA decisions still hold, and AI doesn't loosen any of them. Every iOS browser uses WebKit for Home Screen web apps; there's no install prompt; push works only in Home Screen web apps; there's no background sync and no Bluetooth, USB, serial or NFC (iOS & iPadOS). WebKit has shipped WebGPU (Safari 26), which makes bring-your-own-model inference possible, but it has no built-in model API and opposes the one Chrome shipped. For an AI feature that must run locally on iPhone at native speed with a system model, the web is not an option in 2026.

Forces pushing toward the web¶

Built-in AI APIs in the browser¶

On desktop, the web gained system-model access in 2025 and 2026. Chrome Platform Status records the Translator, Language Detector and Summarizer APIs as shipped in Chrome 138 and the Prompt API as shipped on desktop in Chrome 148 (May 2026), with text, image and audio input and output constrained to a JSON Schema or regular expression. The Writer, Rewriter and Proofreader APIs are back in developer trial behind flags after their origin trials ended (Chrome 137–145 for Writer and Rewriter, 141–146 for Proofreader, per Chrome Platform Status). Microsoft Edge offers the same Prompt API as a developer preview in its Canary and Dev channels, backed by Phi-4-mini (Microsoft Learn).

The limits are as important as the capability:

The strategic point is not that these APIs replace native model access. They don't reach phones. It's that a desktop PWA can now offer private, zero-marginal-cost inference to Chrome desktop users whose hardware qualifies, without shipping a model, which removes one reason to build a desktop native app. On-Device AI in the Browser covers the APIs and their availability states.

WebGPU and WebNN: bring your own model, everywhere¶

When you need a specific model, or need to run on iOS and Android, the web's answer is to ship the model yourself. WebGPU is available in all three engines on at least some platforms: Chromium 113+ on desktop (Linux from 144), Chrome 121+ on Android, Safari 26+, and Firefox 141+ on Windows and 145+ on Apple silicon Macs. Runtimes such as Transformers.js, WebLLM and ONNX Runtime Web run models on it. The Web Neural Network API goes further by mapping model graphs to the operating system's ML stack, including NPUs where available; it's a W3C Candidate Recommendation Draft (September 10, 2026) with a positive Mozilla position and no WebKit signal. In Chromium it's behind a flag: an origin trial re-enabled for Chrome 147–149 was disabled again in March 2026 over release-blocking issues, and the WebNN project lists a new trial for Chrome and Edge 156 (TBD) to 160.

The costs are real. A small language model is hundreds of megabytes to several gigabytes; it counts against your origin's quota, can be evicted under storage pressure, and competes for memory with the rest of the page, which mobile browsers limit more tightly than native apps (Storage Quotas & Persistence). Bring-your-own-model is practical for small task models (classification, embeddings, speech, image segmentation) on phones, and for larger language models mainly on desktops.

Zero-install reach for agents and chat assistants¶

The web's oldest advantage, that a URL opens the app without an install, becomes more valuable when the one following the link is software. An agent in a browser, or a chat assistant with a browsing tool, can open any URL, read it and act on it. It can't install a native app, and it can reach a native app only through the actions the app declared to the OS on the user's own device.

Two developments in 2026 make web technology the UI layer that chat assistants and browser agents work with:

• MCP Apps. The MCP Apps extension, the Model Context Protocol's first official extension, went live on January 26, 2026 with support in Claude, Goose and VS Code Insiders, and in ChatGPT starting that week. A tool returns a ui:// resource containing HTML that the host renders "in sandboxed iframes with restricted permissions". The interactive UI that appears inside a chat assistant is a small web app, and a team with a PWA already has the components, design system and API client it needs to build one.
• WebMCP. WebMCP lets a page register tools with document.modelContext (imperatively in JavaScript) or declaratively on HTML forms so a browser agent calls a function with a schema instead of clicking through the UI. Chrome Platform Status lists its origin trial from Chrome 149 to 156 on desktop, Android and WebView, after a flag-only phase from Chrome 146; Edge runs its own trial. Early previews used navigator.modelContext, so feature-detect both. It's available only in origin-isolated documents and is gated by a tools Permissions Policy. WebKit and Mozilla have no published position.

The native equivalents, App Intents and AppFunctions, are more mature for OS assistants on phones. The web equivalents are more universal: they work for any agent in any browser that implements them, and the MCP route works in any assistant that supports the protocol, independent of the user's phone. AI Agents & the Web covers both.

URL-addressable content for AI search¶

AI answers in search engines and assistants are built from indexable content, and content inside a native app isn't indexable unless you maintain a parallel website. Google's documentation on AI features in Search states that pages need to be indexed and "eligible to be shown in Google Search with a snippet", and that "there are no additional requirements to appear in AI Overviews or AI Mode". It adds that you "don't need to create new machine readable files, AI text files, or markup". The implication for platform choice is direct: a server-rendered PWA is eligible for AI search on the same terms as for classic search (SEO for PWAs), and a native-only product is not. Proposals such as llms.txt exist, but Google explicitly says it doesn't need them; treat them as optional.

Instant updates for fast-moving AI features¶

AI features change faster than other features. Prompts get tuned weekly, model versions change under you, safety filters and tool definitions evolve, and a regression in model behavior needs a same-day fix. A PWA ships a fix with a deploy and reaches users on their next navigation, subject to your service worker update strategy (Updating Service Workers). A native app ships through review and waits for users to update. Native teams mitigate this by keeping prompts and model routing on the server, which works for cloud features but not for on-device prompts that run against a system model whose version is tied to the OS.

There's a subtle reversal here. With Apple's Foundation Models, the model itself changes with OS updates that you don't schedule, and Apple publishes guidance on "updating prompts for new model versions". With Chrome's built-in AI, the model changes with browser updates. Either way, an on-device AI feature needs evaluation tooling and a fast way to ship prompt changes, and the web's release model is the faster of the two.

Regulation opens distribution and engines, in two regions¶

The EU's Digital Markets Act and Japan's Mobile Software Competition Act changed the rules for iOS in their regions:

For PWAs, the effect is smaller than the headlines. Home Screen web apps run on WebKit everywhere, and Open Web Advocacy reported in June 2026 that no browser vendor had shipped an alternative engine to iOS users (Platform Support). EU Web Distribution distributes native apps from your website, not web apps. The more relevant development for AI may be the European Commission's first DMA review (April 28, 2026), whose Q&A lists "equal access of AI-based services to operating systems" among its AI themes and raises "whether certain AI services should potentially be designated as virtual assistants core platform service". If that leads to rules requiring OS assistant integration points to be open to third parties, it would affect native apps and AI services more directly than PWAs.

AI-generated code lowers cross-platform costs, for both sides¶

AI coding tools are a force in both directions, which is why the next section treats them separately. For the web, they make it cheaper to reach parity with native UX: generated components, accessibility fixes, service worker routes and test suites. For native, they make it cheaper to maintain a second and third client. Which effect dominates depends on which costs dominate your product.

How AI coding tools change the build-cost equation¶

Adoption is not in question. Stack Overflow's 2025 Developer Survey reported that 84% of respondents use or plan to use AI tools in their development process and that 51% of professional developers use them daily. Apple's Xcode 27 integrates agents from Anthropic, Google and OpenAI directly (Apple Newsroom). The productivity effect is less settled: METR's randomized study found that experienced open-source developers took 19% longer on tasks with early-2025 tools, and its February 2026 update found estimates pointing toward a speedup with later tools but described its own data as an "unreliable signal" because developers increasingly declined to work without AI. The same survey found that more developers distrust the accuracy of AI output (46%) than trust it (33%).

The honest model, then, is not "code is free" but "writing well-specified code is cheaper, and everything around it costs about what it did". Applied to the cost items that decide web versus native:

Two conclusions follow.

The marginal native client got cheaper, but the second and third codebases still carry fixed costs. In this site's assessment, a team that previously couldn't afford a native iOS app for one missing capability can now build a Capacitor shell with a couple of Swift plugins much faster than before; no published study measures that effect, so estimate it against your own team. A team maintaining three full clients still runs three release trains, three QA passes and two store relationships.

The cost argument for the web shifts from "cheaper to build" to "cheaper to run and faster to change". Instant updates, one test surface per engine rather than per OS version, no review queue and no version long tail are properties of the delivery model, and AI tools don't change them. For AI features, which change more often than most, those properties matter more than before.

Distribution shifts: stores, search, assistants and chat¶

Each route to users favors a different architecture. The table summarizes who each channel can reach in September 2026.

Three implications:

1. Most new AI channels are server-side or web-side. Chat assistants call your tools through MCP, which lives on your server and serves every client. Browser agents operate web UIs. Only OS assistants require native app code. Building for the new channels mostly means building good APIs and good web pages, which you need anyway.
2. The install becomes less of a gate. When an assistant answers a question with your content, or operates your checkout on the user's behalf, the user may never install anything. Products whose value can be delivered in one interaction are pulled toward the web; products whose value depends on a persistent presence on the device (notifications, widgets, background work, OS assistant actions) still benefit from an installed app.
3. Stores remain the default for some categories and some users. Nothing in 2026 suggests stores are becoming irrelevant. What's changing is that they are no longer the only place an app is discovered and operated.

Android adds one more consideration. Google's developer verification protections start on September 30, 2026 for users in Brazil, Indonesia, Singapore and Thailand who install apps from participating stores on certified devices running Android 7+, and Google says it will expand them globally to all apps on certified devices in 2027. Native Android apps, including those distributed outside Play, get an identity step; a PWA served from a browser isn't affected, and Google says Play registers 99% of apps automatically.

AI capability comparison: native vs PWA vs hybrid wrapper¶

The table compares AI-relevant capabilities across the three architectures. "Hybrid wrapper" means a Capacitor or custom WKWebView app on iOS and a TWA or Capacitor app on Android, where native plugin code can add platform features around your web content.

Support data as of September 2026. Check Chrome Platform Status, MDN and caniuse for live web data, and Apple's and Google's developer documentation for native APIs.

⚠️ entries are usable with the constraint named in the cell. 🧪 marks origin trials or experimental previews.

Read the table by rows that matter to you, not by counting checkmarks. A product whose only AI need is a cloud chat feature sees identical rows everywhere except distribution. A product that needs Siri to act on its content sees one row that decides the question.

Measuring which AI capabilities your users have¶

As with every other capability, decide on your users' browsers, not on global tables. The probe below records which web AI surfaces are present for your actual traffic, without triggering a model download or a permission prompt.

// Records which AI-related web capabilities exist for this visitor.
// Never calls create(): that could start a multi-gigabyte model download.
// availability() only reports state ("unavailable" | "downloadable" |
// "downloading" | "available").
async function availabilityOf(api, options) {
  try {
    if (!(api in self)) return "absent";
    return await self[api].availability(options);
  } catch (error) {
    // Unsupported options (for example, a language pair) reject rather than
    // returning "unavailable" in some versions; record the error name.
    return `error:${error.name}`;
  }
}

async function detectAiCapabilities() {
  const gpuAdapter = "gpu" in navigator
    ? await navigator.gpu.requestAdapter().catch(() => null)
    : null;

  return {
    // Built-in AI (Chrome desktop; Edge previews behind flags).
    languageModel: await availabilityOf("LanguageModel"),
    summarizer: await availabilityOf("Summarizer"),
    translatorEnDe: await availabilityOf("Translator", {
      sourceLanguage: "en",
      targetLanguage: "de",
    }),
    // Bring-your-own-model paths.
    webgpu: gpuAdapter !== null, // an adapter, not just the API, must exist
    webnn: "ml" in navigator, // behind a flag in Chromium (origin trial paused)
    // Agent surface.
    // origin trial, origin-isolated pages only; early previews used navigator.modelContext
    webmcp: "modelContext" in document || "modelContext" in navigator,
    // Context: installed or in a tab, so you can segment the results.
    standalone:
      navigator.standalone === true ||
      matchMedia("(display-mode: standalone)").matches ||
      matchMedia("(display-mode: fullscreen)").matches,
    deviceMemory: navigator.deviceMemory ?? null, // Chromium only, capped value
  };
}

export async function reportAiCapabilities(endpoint) {
  try {
    if (sessionStorage.getItem("ai-probe-sent")) return; // once per session
    const body = JSON.stringify({ ai: await detectAiCapabilities(), ts: Date.now() });
    if (!navigator.sendBeacon?.(endpoint, body)) {
      await fetch(endpoint, { method: "POST", body, keepalive: true });
    }
    sessionStorage.setItem("ai-probe-sent", "1");
  } catch (error) {
    console.debug("AI capability probe skipped", error); // storage can throw
  }
}

Join the results with your business metrics. If languageModel is "available" for a large share of your paying desktop users, built-in inference can carry real load. If it's "absent" for nearly all of your mobile traffic, as it will be in 2026, your mobile AI features run in the cloud or in a model you ship. When to Build a PWA has the general version of this probe.

Scenarios for 2027–2030¶

Four scenarios cover the plausible range. They aren't mutually exclusive; the most likely outcome in the view of this analysis is a mix, with different scenarios dominating in different product categories.

Scenario 1: The web gets an agent layer¶

WebMCP or a successor ships in Chromium stable after its origin trial, and at least one other engine implements it. Browser agents built into Chrome, Edge and other browsers prefer declared tools to UI automation, and sites that expose tools get more reliable agent traffic. Built-in model APIs spread to Chrome for Android. In this world, a well-built PWA is directly operable by the agents in the browser the user already has, and the web's reachability advantage compounds.

What it would mean for the decision: web-first becomes stronger for commerce, booking, content and productivity. Native remains necessary for OS assistant integration and device capabilities.

Scenario 2: OS assistants become the primary interface¶

Siri AI, Gemini on Android and their successors become the way many users start tasks on phones, and the assistants route those tasks through native app actions (App Intents, AppFunctions) and the platform vendors' own services. Web content is used as a knowledge source for answers but rarely as a destination. In this world, being invokable from the OS assistant becomes a distribution requirement for mobile products, the way being in the App Store was in 2012.

What it would mean for the decision: consumer mobile products need at least a thin native presence to be invokable. PWA-first with a native shell becomes the minimum for mobile-heavy consumer products; native-first gains for products whose core interactions are short, repeated, assistant-driven tasks.

Scenario 3: Chat assistants become app platforms¶

Chat assistants grow into distribution platforms with their own app directories, built on MCP and MCP Apps. Users complete tasks inside the assistant using embedded UIs from many vendors. In this world, the "app" is a set of server-side tools plus small web UIs, and neither a native app nor a full PWA is the primary surface for some categories.

What it would mean for the decision: investment shifts toward APIs, tool design and embeddable web components. Teams with a component-based web front end are best placed to reuse it. Native clients matter less for the tasks that move into assistants, and the web's role becomes the embedded UI technology rather than the destination.

Scenario 4: Fragmented status quo¶

Each engine and platform keeps its own AI surface: Chrome's built-in APIs stay Chromium-only, WebKit ships no model API, WebMCP stays in Chromium, and the OS assistants stay native-only. Regulation opens some integration points in the EU and Japan without changing global defaults. In this world, the 2026 decision framework below stays valid with incremental updates.

What it would mean for the decision: nothing changes structurally. PWA-first for reach, native where capabilities require it, and feature detection at every boundary.

Signals to watch¶

Put these on the same six-month review cycle that When to Build a PWA recommends for capability gaps.

A decision framework by app type¶

The framework extends the procedure in When to Build a PWA with the AI-specific questions from this page. Start with your must-have requirements, including AI ones, and your traffic split by platform.

flowchart TD
    A["List must-haves, including AI features, and platform traffic"] --> B{"Core value needs device hardware, background work or high-end GPU on mobile?"}
    B -- yes --> N["Native-first; add a PWA or website for reach and sharing"]
    B -- no --> C{"Must the OS assistant invoke the app, or must AI run on the phone's system model?"}
    C -- yes --> D{"Is that a core feature or one part of the product?"}
    D -- "core, used constantly" --> N
    D -- "one part" --> H["PWA-first plus a native shell that adds it"]
    C -- no --> E{"Is a store listing required?"}
    E -- "App Store" --> H
    E -- "Google Play or Microsoft Store only" --> T["PWA plus TWA or PWABuilder package"]
    E -- no --> P["PWA; cloud AI plus built-in AI as an enhancement"]
    H --> R["Review the signals every six months"]
    T --> R
    P --> R
    N --> R

The table applies the framework to seven common app types. "Default" is the architecture to start from absent a specific reason to deviate; the deciding factor is the requirement most likely to change that default.

Content and media¶

The web's case is strongest here and AI makes it stronger. AI search and assistants build answers from indexable pages, and Google states no special markup is needed beyond being indexable and snippet-eligible. Agents and chat assistants link to URLs. On-device AI features such as summaries and translation are enhancements, available through built-in APIs on desktop and cheaply from a server elsewhere. A native app adds value only for offline media downloads on iOS and for users who prefer store apps; When to Build a PWA covers that trade-off.

Commerce and booking¶

Commerce is where agents may change the most, because purchase and booking flows are the tasks agents are being built to complete. Protocols for agent-initiated payments, such as the Agentic Commerce Protocol and Google's Agent Payments Protocol, are server-side and client-neutral. The client-side question is whether an agent can operate your flow: semantic forms, accessible labels and stable URLs help every browser agent today, and WebMCP tools may help Chromium agents in the future. A native app remains valuable for repeat customers (notifications, widgets, wallet passes, and on iOS, Siri AI actions), which is why the default adds a native shell when mobile repeat purchase is central.

Productivity and SaaS¶

Desktop is where the web's AI story is strongest in 2026: built-in models on capable Chrome desktops, WebGPU everywhere, installed PWAs with file handling and window controls on Chromium (Desktop Platforms). AI features change fast and benefit from instant deploys. The pull toward native comes from iPhone users who want Siri to act on their documents, tasks or calendars; a Capacitor shell with App Intents in Swift covers that without a second UI.

AI-first assistants and companions¶

Products whose core is an assistant (a tutor, a coach, a personal agent) are the case where "both" is not a hedge but the architecture. The agent logic, memory and tools live on the server and serve every client. The web client gives reach, desktop presence, shareable conversations and an embeddable UI for chat platforms. The native clients give what the product depends on for daily use on phones: OS assistant hand-off, system model access for private or offline features, background audio, reliable notifications and widgets. Starting with only a PWA is reasonable to validate the product; plan the native clients early if daily mobile use is the goal.

Games¶

Casual, puzzle, word and social games are still web-friendly: instant play from a link or chat message is their growth mechanism, and AI features such as generated levels or hints run in the cloud or in small models on WebGPU. High-end 3D games stay native for GPU and memory headroom and store distribution. On-device language models for game characters are more practical natively on phones in 2026, because the web has no system model on mobile and shipping your own model to a phone browser is costly.

Enterprise and internal tools¶

Managed Chromium desktops are the best environment for web AI in 2026: administrators can force-install PWAs, control built-in AI through Chrome enterprise policies (Chrome Platform Status lists GenAILocalFoundationalModelSettings and BuiltInAIAPIsEnabled), and data residency often favors models you host yourself anyway. Native is needed mainly for mobile peripherals. Isolated Web Apps extend what managed web apps can reach on ChromeOS.

Device-heavy apps¶

When the product is a sensor, a wearable companion or a field device, AI doesn't change the answer: background execution, Bluetooth LE on iOS and OS health and home frameworks are native-only, and on-device inference over sensor data wants the NPU through Core ML, Core AI or Android's runtimes. Build native, and use a PWA or website for dashboards, sharing and desktop access.

PWA-first with a native shell¶

"PWA-first with a native shell" is the recommendation for the largest group of products, so it deserves a precise definition. The PWA is the product: one web codebase, deployed continuously, served at stable URLs, installable from the browser. Around it, you ship thin native apps whose job is to add the specific capabilities the web lacks on that platform:

• Android: a Trusted Web Activity for the Play listing, App Links and Play Billing. The web content runs in Chrome from your live origin, so the service worker, storage and updates are shared with the browser (Trusted Web Activities). A TWA is an ordinary Android project, so native features such as AppFunctions can in principle be added in Kotlin; they run in native code, not in your web content, and must call your backend rather than your page.
• iOS: a Capacitor app (or a custom Swift shell) that bundles your web build and adds native plugins: APNs push, widgets, share extensions, and for AI, App Intents for Siri AI and a plugin that calls Foundation Models. Bundle the web assets rather than loading your live site, both for App Review guideline 4.2 and so the app works offline (Publishing to App Stores).

The shell's AI plugin and the web code can share one routing layer, so the same feature uses the platform model inside the iOS app, the browser model on capable desktops, and the cloud everywhere else:

import { Capacitor, registerPlugin } from "@capacitor/core";

// Implemented natively in the shell: Swift calls Foundation Models,
// Kotlin calls ML Kit GenAI. Neither exists in the browser build.
interface OnDeviceModelPlugin {
  availability(): Promise<{ status: "available" | "unavailable" }>;
  summarize(options: { text: string }): Promise<{ summary: string }>;
}
const OnDeviceModel = registerPlugin<OnDeviceModelPlugin>("OnDeviceModel");

type Route = "native" | "built-in" | "cloud";

async function pickRoute(): Promise<Route> {
  // 1. Inside the native shell, prefer the platform's system model.
  if (Capacitor.isNativePlatform() && Capacitor.isPluginAvailable("OnDeviceModel")) {
    try {
      const { status } = await OnDeviceModel.availability();
      if (status === "available") return "native";
    } catch {
      // Plugin error: fall through to the web paths.
    }
  }
  // 2. In a browser with a built-in model that is already downloaded.
  //    (Types come from @types/dom-chromium-ai.)
  if ("Summarizer" in self) {
    try {
      // Only "available": "downloadable" would start a large download,
      // which should be the user's explicit choice, not a side effect.
      if ((await Summarizer.availability()) === "available") return "built-in";
    } catch {
      // Unsupported options or policy-disabled: use the cloud.
    }
  }
  // 3. Everywhere else.
  return "cloud";
}

export async function summarize(text: string, signal?: AbortSignal): Promise<string> {
  const route = await pickRoute();

  if (route === "native") {
    const { summary } = await OnDeviceModel.summarize({ text });
    return summary;
  }

  if (route === "built-in") {
    const summarizer = await Summarizer.create({
      type: "tldr",
      format: "plain-text",
      length: "short",
      signal,
    });
    try {
      return await summarizer.summarize(text, { signal });
    } finally {
      summarizer.destroy(); // release the model's memory
    }
  }

  // Cloud: your server holds the API key, enforces quotas and picks the model.
  const response = await fetch("/api/summarize", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ text }),
    signal,
  });
  if (!response.ok) throw new Error(`Summarize failed: ${response.status}`);
  const { summary } = (await response.json()) as { summary: string };
  return summary;
}

Different models produce different summaries, so evaluate each route against the same test set, and tell users when output comes from a smaller on-device model if quality differs noticeably. Cloud AI in PWAs covers the server side of the /api/summarize endpoint.

When the shell is the wrong choice: if the native features would be used constantly and define the product (an assistant that lives in Siri, a fitness app that runs in the background), the shell grows into a native app with a web view in the corner. At that point, build native UI for the core flows and keep the web for reach and desktop, as the AI-first and device-heavy rows of the table recommend. PWA vs Native vs Hybrid compares the hybrid strategies in more depth.

Common pitfalls¶

• Treating "AI" as one requirement. Cloud inference, on-device inference, OS assistant integration and agent reachability have different answers per platform. Split them before deciding.
• Choosing native for a cloud AI feature. If the model runs on your server, a PWA calls it exactly as a native app does. Native earns its cost through the device and OS rows of the capability table, not the cloud row.
• Choosing the web for a system-model feature on phones. In 2026, no mobile browser exposes a system language model to web pages. Shipping your own model to phones works only for small models.
• Building on origin trials. WebMCP and WebNN are experiments with end dates. Use them to learn and to gain an edge where they work, not as the foundation of a product that must work everywhere.
• Ignoring prompt drift. Apple and Chrome both update their on-device models on their own schedules. Keep evaluations running against every model you route to, and keep prompts where you can change them quickly.
• Assuming AI coding tools remove maintenance. They reduce the cost of writing code. Review, device testing, store compliance and version support remain, and they scale with the number of clients.
• Forgetting that agents need the same things people do. Semantic HTML, accessible names, stable URLs and predictable forms help agents and humans; agent-specific tricks that degrade human UX cost more than they return.

The bottom line¶

This section is this site's analysis of the evidence above, not a vendor commitment or a measured outcome. For most products in September 2026, build a PWA as the canonical product, and add native code only where a named capability requires it, most often as a thin shell (a TWA on Android, a Capacitor or Swift app on iOS). The web is where agents, chat assistants, AI search and links can reach you without an install, where AI features can change daily, and where one codebase covers desktop, where the web's built-in AI is strongest. Native code is justified by specific rows of the capability table: the OS assistant must invoke you, a system model must run on the user's phone, work must continue in the background, or the product depends on hardware. When those rows describe the core of the product, as for device-heavy apps, high-end games and AI assistants built for daily mobile use, go native-first and keep the web for reach.

AI coding tools make the native shell cheaper than it has been, which tilts the decision toward "both" rather than toward native alone: the build cost of an extra client falls, while the costs of review, stores, testing and old versions that come with each additional native client stay the same. Which of the four scenarios dominates by 2030 is unknown. The signals table tells you what to watch, and the architecture recommended here, a web core with native edges and server-side tools, is the one this analysis expects to hold up best across all four, because each scenario rewards at least one of its parts.

Further reading¶

On this site

• AI & the Future of Web Apps: the section overview
• On-Device AI in the Browser: built-in AI APIs, WebGPU, WebNN and model caching
• Cloud AI in PWAs: server proxies, streaming and offline policies for AI features
• AI Agents & the Web: agent-readable markup, WebMCP and MCP
• PWA vs Native vs Hybrid: the architecture comparison this page extends
• When to Build a PWA: the capability checklist and scenario analyses
• Publishing to App Stores: TWA, Microsoft Store and App Store wrappers
• Platform Support: the September 2026 matrix and the iOS engine rules

External references

• Foundation Models, Core AI and App Intents, Apple Developer
• WWDC26 Apple Intelligence guide, Apple Developer
• Gemini Nano, AppFunctions and ML Kit GenAI APIs, Google
• Built-in AI APIs, The Prompt API and WebMCP, Chrome for Developers
• Web Neural Network API, W3C
• MCP Apps, Model Context Protocol blog
• AI features and your website, Google Search Central
• DMA Review Q&A, European Commission, and Apple: alternative browser engines