The cheapest AI app to run is one where the user’s own machine does the work. Your server hands out files, the browser downloads a small model once, and every inference after that happens on the visitor’s GPU or CPU. You pay for static hosting. That’s it.

This used to be a demo trick. In 2026 it’s a reasonable way to ship a real tool. WebGPU now runs in Chrome, Edge, Safari 26 and up (iPhone and iPad included) and Firefox on Windows and Apple Silicon Macs. Transformers.js v4 runs vision, speech, embedding and classification models on WebGPU and falls back to WebAssembly when there’s no GPU path. The pieces are boring enough to build on.

The React Native state management ecosystem is the most frequently relitigated technical decision in mobile JavaScript development. Every twelve to eighteen months, a new library emerges, accumulates advocates, generates a wave of “why I switched from X to Y” blog posts, and joins the list of options that teams now have to evaluate. The list includes Redux, MobX, Zustand, Jotai, Recoil, TanStack Query, SWR, Context API, and several others with smaller followings. The churn produces the impression that state management is an unsolved problem requiring continuous reinvention.

React Native was announced by Facebook in 2015 with a promise that rewrote the calculus of mobile development: learn once, write anywhere. The promise was qualified from the start — React Native was never write once, run anywhere in the way that early web-based mobile frameworks had claimed to be — but it was credible enough to reshape how a generation of mobile teams made technology decisions.

Eleven years later, React Native is used in production by Microsoft, Shopify, Coinbase, and thousands of smaller organizations. It has survived the emergence of Flutter, the maturation of Kotlin Multiplatform, and a period of internal uncertainty at Meta when the framework’s future was genuinely in question. Its survival reflects something real about the problem it solves and the ecosystem it has built.