Build for web. Ship a hybrid mobile app.

One UI, web and native

Most teams that need both a website and a mobile app end up building the interface twice: once for the web, once in React Native or fully native code. Two codebases, two toolchains, two backlogs — and a UI that slowly drifts apart between them.

Vireya takes the hybrid path instead. You build your interface once with Vireya's tokenized React components and blocks, and that same web app runs inside a native WebView shell on mobile. Dynamic screens — product lists, detail pages, cart, settings, content — render from the web you already shipped. The result is one UI codebase that reaches the browser and the app stores.

The Mobile Bridge pattern, proven at scale

This isn't a novel gamble. It's the pattern Shopify documented as its Mobile Bridge: native WebViews that feel native because the slow parts are made fast and the critical parts stay native. Large commerce apps such as Mercado Livre and Magazine Luiza run the same way — dynamic, frequently-changing screens render in WebViews, while payments, the camera, sensors and push notifications run natively. It lets them ship faster, update screens without waiting on app-store review, and scale to products with hundreds of dynamic views.

Vireya brings that architecture to a design system: the velocity of the web for the screens that change constantly, native code for the capabilities that have to be native, and one consistent UI across both. (Those companies prove the pattern works at scale — they are not Vireya users.)

How it works

• You build a web app with Vireya components, blocks and a charts library, all driven by --v-* design tokens.
• A native shell loads it in a WebView — an Expo / React Native host today via @vireya/platform-expo, with desktop platforms (Tauri, Electron) planned.
• A typed bridge connects the two. @vireya/rpc is a tRPC-inspired, bidirectional channel over postMessage and injected JS, so the web can call native functions — payments, sensors, push — with end-to-end types.
• The theme follows. The same tokens and components render on web and in the WebView, and the palette can propagate to the native shell, so the product stays visually consistent.

Why hybrid, honestly

Hybrid isn't always the right call, and Vireya is honest about the trade-off. If your app is animation-heavy, deeply native, or its core value is raw per-frame performance, a true React Native library like Tamagui, gluestack-ui or React Native Paper may serve you better. Where hybrid shines is content- and commerce-style apps with many dynamic screens, where one codebase, web velocity and store-free updates outweigh squeezing out the last of native performance.

Vireya is early (v0.1.0) and the native bridge is maturing — Expo first — so this is the architecture the system is built around, not a finished one-click export. If that direction fits how you want to ship, it's the part of Vireya most worth watching.

Where to go next

See why teams choose Vireya, how theming and tokens stay consistent across surfaces, the best approach for React Native and web, or browse the live blocks and charts.

Frequently asked questions

What is a hybrid app in Vireya's sense?

A hybrid app is a native mobile shell that hosts your web UI inside a WebView, with a typed bridge connecting the two. Dynamic screens — lists, detail pages, cart, settings — render from the web you already built, while critical functions like payments, sensors and push run natively. You ship one UI codebase instead of maintaining separate web and native apps.

How is this different from React Native?

React Native rebuilds your interface in native components, which maximises nativeness but means a second UI codebase and toolchain. Vireya keeps a single web codebase and delivers it to mobile through a WebView plus a native bridge. You trade some raw nativeness for web velocity, one codebase, and the ability to update dynamic screens without an app-store release.

Which companies use the hybrid WebView approach?

The pattern is proven at scale. Shopify documented its Mobile Bridge approach for native WebViews, and large commerce apps such as Mercado Livre and Magazine Luiza render dynamic screens in WebViews while keeping payments and device features native. Vireya brings that architecture to a tokenized design system. (These companies validate the pattern; they are not Vireya users.)

Can I really turn a web app into a mobile app in minutes?

The model is designed for exactly that: point a native shell at your Vireya web app and wire the bridge through a platform adapter. The native bridge is maturing — Expo is the first supported platform via @vireya/platform-expo, with desktop targets planned — so treat it as the architecture Vireya is built around rather than a finished one-click export today.

Do my components and theme stay consistent across web and mobile?

Yes — that's the point of one codebase. The same --v-* design tokens, components and blocks render on the web and inside the native WebView, and the theme can propagate to the native shell, so your product looks and behaves the same on every surface.