Two different bets
gluestack-ui set out to solve a real pain: most React component libraries stop at the browser, and most React Native libraries stop at the phone, so teams shipping to both ended up maintaining two UI stacks. gluestack answers that with genuinely universal components — real React Native components that render on native and, via React Native Web, on the browser too — from a single API, styled with NativeWind, Tailwind's utility model brought to React Native. You bring the components into your project with a CLI, so the source lands in your repo and is yours to edit.
That combination is genuinely appealing, and on the native side gluestack is the more mature, more native option today: its components are real RN components, so you get true native rendering and the platform's own primitives. If your team already thinks in Tailwind classes, NativeWind lets you carry that vocabulary onto native without learning a second styling system, and the copy-paste delivery means there's no package abstraction between you and the markup.
Vireya makes a fundamentally different bet about how to reach mobile. Rather than authoring real React Native components, you keep one web codebase and ship it to mobile as a hybrid native app: the web UI runs inside a native WebView shell, and a typed RPC bridge (`@vireya/rpc`) wires the native functions you actually need — payments, sensors, push. It's the Mobile Bridge pattern Shopify documented and that commerce apps like Mercado Livre and Magazine Luiza adopted. You trade some nativeness for web velocity and far fewer store releases on dynamic screens. On the web itself Vireya ships as a versioned `@vireya/*` package styled with static CSS Modules driven by `--v-*` tokens — no Tailwind, no runtime style engine — and bundles a theming engine, pre-composed blocks and a charts library that gluestack doesn't.
So this is two different paths to mobile, not the same path. gluestack rewrites the UI as native components; Vireya keeps the web UI and runs it in a WebView with a native bridge. Be clear-eyed: gluestack is the more native and more mature mobile option right now, and Vireya's native bridge is still maturing. The Vireya bet pays off when web velocity and dynamic delivery matter more than maximum nativeness. Vireya is early (v0.1.0), so weigh trajectory and philosophy, not feature-count parity.
Under the hood
Distribution: copy-paste source vs a versioned package
gluestack-ui is installed through a CLI that writes component source into your project. The components you copy are yours to edit, and there's no shared package the components themselves depend on at runtime. The flip side is that upstream fixes and new variants don't flow to you automatically — you re-run the CLI and reconcile against any edits you've made, in every project that copied the code.
Vireya is imported from `@vireya/*` with per-component subpaths, so you bundle only what you use and you upgrade the whole hybrid system through `pnpm upgrade`. You give up owning the source to fork freely; in return, maintenance is centralised and versioned across web and native at once.
Styling: NativeWind utilities vs tokenized CSS Modules
gluestack styles with NativeWind, which compiles Tailwind utility classes down to React Native styles on native and to CSS on the web. Your design lives in class strings and your Tailwind/NativeWind config, and re-theming means editing utilities or the theme across the components you copied.
Vireya ships static CSS Modules where every value resolves to a `--v-*` token. There is no Tailwind dependency and no runtime CSS-in-JS. You re-theme by changing token values once through `createTheme()`, and components, blocks and charts all follow on both platforms.
Path to mobile: true React Native vs hybrid WebView
gluestack's mobile story is true React Native: its components are real RN components, so on a phone they render through the platform's own primitives. The UI is genuinely native, with native gestures and rendering — this is the more native, more mature option today.
Vireya takes the hybrid route instead. You don't rewrite the UI in React Native; you keep one web codebase and run it inside a native WebView shell, with `@vireya/rpc` bridging to native functions. You give up some nativeness in exchange for shipping one codebase to web and mobile and pushing dynamic screens without a store release — the Mobile Bridge pattern Shopify documented and apps like Mercado Livre and Magazine Luiza use. The bridge is still maturing (Expo first via `@vireya/platform-expo`).
Scope: components vs components + blocks + charts
gluestack focuses on the universal component layer; dashboards, data visualisation and pre-built sections are left for you to assemble or source elsewhere.
Vireya bundles pre-composed blocks and a charts library beside the components, all driven by the same tokens, so a marketing page and a dashboard stay visually consistent without stitching separate libraries together.
Side by side
| Vireya | gluestack-ui | |
|---|---|---|
| Distribution | Versioned npm package | Copy-paste via CLI |
| Updates | Upgrade the dependency | Re-run CLI / maintain owned source |
| Styling | CSS Modules + --v-* tokens, no Tailwind | NativeWind (Tailwind for RN + web) |
| Theming | Token engine, tier-based palette, light/dark | NativeWind / Tailwind config |
| Charts & blocks | Bundled, same tokens | None |
| React Native | Hybrid WebView + typed bridge (one web codebase) | True React Native (native components) |
| Accessibility | Radix + base-ui primitives (web) | WAI-ARIA patterns / RN accessibility |
| Native maturity | Bridge maturing (Expo first) | Established native components |
| Maturity | Early (v0.1.0), actively built | Established, evolving rapidly |
Where gluestack-ui shines
- It delivers genuinely universal React Native and web components from one API, so a hybrid app can share a single UI surface instead of maintaining two stacks.
- NativeWind gives teams already fluent in Tailwind a familiar utility-class workflow that carries unchanged onto native.
- Copy-paste delivery means you own the component source outright, with no version lock-in and freedom to diverge any component.
- Modular per-component installs keep the bundle lean, and it supports modern Next.js and React Server Components.
What Vireya does differently
- It reaches mobile a different way: instead of authoring true React Native components, Vireya keeps one web codebase and ships it to mobile as a hybrid native+WebView app with a typed bridge — trading some nativeness for web velocity and fewer store releases on dynamic screens.
- It arrives as a versioned package — fixes and new components reach you through an upgrade, not by re-running a CLI and merging diffs in each repo.
- Theming is one `--v-*` token layer applied through `createTheme()`, rather than NativeWind utilities and a Tailwind config you maintain per project.
- A charts library and pre-composed blocks come in the box and share the components' tokens; gluestack ships neither.
- There's no Tailwind or NativeWind in the pipeline and no runtime style engine — styling is static CSS Modules, with accessibility on the web built on Radix and base-ui primitives.
When to choose gluestack-ui
- You want true React Native components and maximum nativeness on the phone, today.
- Your team already lives in Tailwind via NativeWind and wants that vocabulary on native.
- Owning the component source with no version lock-in is a priority.
- You prefer modular, per-component copy-paste installs over a shared dependency.
When to choose Vireya
- You'd rather keep one web codebase and ship it to mobile as a hybrid native+WebView app than rewrite the UI in React Native.
- Web velocity and pushing dynamic screens without store releases matter more than maximum nativeness.
- You'd rather theme through `--v-*` tokens than NativeWind utilities and a Tailwind config.
- You want a charts library and pre-composed blocks included and sharing one token vocabulary.
Switching from gluestack-ui to Vireya
Moving from gluestack-ui to Vireya is more than a delivery swap, because the path to mobile changes too. gluestack gives you true React Native components; Vireya has you keep one web codebase and run it inside a native WebView shell with a typed bridge. So a migration means deciding the hybrid trade-off is right for you — accepting less nativeness in exchange for one codebase and dynamic delivery — not just switching import sources. On the web you stop copying source via the CLI and import from `@vireya/*`, with fixes arriving through upgrades.
The styling shift is the other part to plan for: NativeWind utility classes and your Tailwind config give way to `--v-*` tokens set once through `createTheme()`. Teams typically map their palette and spacing to tokens first, then migrate surface by surface, leaning on Vireya's bundled blocks and charts to replace pieces gluestack didn't cover. Note the native bridge is still maturing, so for the most native screens gluestack remains the stronger option today.
The bottom line
gluestack-ui and Vireya both want one UI across web and mobile, but they take different paths to get there. gluestack ships true React Native components — the more native and more mature mobile option today — styled with NativeWind and owned as copy-paste source. Vireya keeps one web codebase and ships it to mobile as a hybrid native+WebView app with a typed bridge, trading some nativeness for web velocity and dynamic delivery, plus token-driven theming and bundled charts and blocks. If maximum nativeness on the phone is the priority right now, gluestack is the safer bet. If one web codebase, dynamic screens and a tokenized system matter more, Vireya is the better fit — accepting that its native bridge is still maturing.
Still deciding? Read why teams choose Vireya, see how theming works, or browse the live blocks and charts showcases. You can also see other comparisons, browse UI library alternatives and the best library by use case, or read about gluestack-ui directly.
Frequently asked questions
Is Vireya a gluestack-ui alternative?
They solve the same goal — one UI across web and mobile — by different paths. gluestack ships true React Native components styled with NativeWind, copy-paste. Vireya keeps one web codebase and ships it to mobile as a hybrid native+WebView app with a typed bridge, plus a --v-* token engine and bundled charts and blocks. If you want maximum nativeness today, gluestack is more mature.
Do gluestack and Vireya reach mobile the same way?
No — this is the key distinction. gluestack uses true React Native: its components are real native components, so you get genuinely native rendering, and it's the more mature mobile option today. Vireya doesn't rewrite the UI in React Native; it keeps one web codebase and runs it inside a native WebView shell with a typed @vireya/rpc bridge (the Mobile Bridge pattern Shopify documented, used by apps like Mercado Livre and Magazine Luiza). You trade some nativeness for web velocity and fewer store releases on dynamic screens. Vireya's bridge is still maturing.
Does Vireya use NativeWind or Tailwind like gluestack?
No. gluestack styles with NativeWind, Tailwind's utility model for React Native and web. Vireya ships static CSS Modules driven by --v-* tokens, with no Tailwind dependency and no runtime style engine.
Does Vireya copy source into my project like gluestack?
No. gluestack writes component source into your repo via a CLI. Vireya is consumed from @vireya/* packages with per-component subpaths, so improvements arrive through upgrades rather than re-running a CLI and reconciling diffs.
Is it hard to migrate from gluestack-ui to Vireya?
The bigger decision is the path to mobile: you're moving from true React Native components to a hybrid WebView-plus-bridge model, accepting less nativeness for one web codebase and dynamic delivery. On the web the work is replacing CLI-copied source with package imports and converting NativeWind utilities to --v-* tokens via createTheme(). The two can coexist, so teams migrate surface by surface — and for the most native screens gluestack remains stronger today.
Which should I choose?
Choose gluestack if you want true React Native components and maximum nativeness today, Tailwind-via-NativeWind styling, and source ownership. Choose Vireya if you'd rather keep one web codebase and ship it to mobile as a hybrid native+WebView app, with token-driven theming without Tailwind and bundled charts and blocks.