Two different bets
React Native Paper is one of the most established component libraries in the React Native world. Maintained by Callstack — a team deep in the RN ecosystem — it gives you a faithful Material Design 3 implementation: buttons, cards, app bars, FABs, snackbars and the rest, with the MD3 theming model, light and dark variants, and dynamic color baked in. It runs on the web too, through react-native-web, but its centre of gravity is the phone, and its components are true native React Native components.
For teams building mobile-first products that want a recognised, polished design language without designing one from scratch, Paper is a sensible default. Material Design is well understood, the components behave the way users on Android expect, and the library has years of production hardening behind it. Theming flows through MD3 tokens, so you can recolor the system coherently and respect platform conventions. On the native side it is, unambiguously, the more mature and more native option.
Vireya reaches mobile a completely different way. Rather than authoring true 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. On top of that, Vireya is tokenized through a `--v-*` engine with `createTheme()`, bundles a charts library and pre-composed blocks, and — crucially — is not Material Design: its visual language is neutral and brandable, so it reads as your product, not a Google design spec.
The honest framing here is two different paths to native plus a difference in design language. Paper ships true React Native Material Design components — the more native and more mature mobile option today. Vireya keeps one web codebase and runs it in a WebView with a native bridge, trading some nativeness for web velocity and fewer store releases on dynamic screens, in a neutral brandable look. Vireya is early (v0.1.0) and its native bridge is still maturing, so if you specifically want true-native Material Design on mobile today, Paper is the safer bet — this is about fit, not just maturity.
Under the hood
Design language: Material Design 3 vs neutral tokens
Paper implements Material Design 3, so its components carry MD3's shapes, elevation, ripple and motion semantics, and its theming is expressed in Material's token vocabulary (color roles, surface tints, dynamic color). That's a feature if you want Material, and a constraint if you don't — diverging far from the Material look means fighting the system.
Vireya's design language is intentionally neutral and brandable. Components are styled through `--v-*` tokens with a tier-based palette, and `createTheme()` lets you recolor the whole system without inheriting any single vendor's aesthetic, so the result looks like your brand rather than Material.
Path to mobile: true React Native vs hybrid WebView
Paper is React Native first, and its components are true RN components: on a phone they render through the platform's own primitives, with native gestures and behaviour. Web support comes via react-native-web, which maps those RN primitives onto the DOM. This is the more native, more mature path to mobile today.
Vireya doesn't author React Native components at all. You build the UI once as a web app — static CSS Modules driven by tokens, no runtime style engine, RSC-friendly — and ship it to mobile inside a native WebView shell, with `@vireya/rpc` bridging to the native functions you need. You trade some nativeness for one codebase across web and mobile and the ability to push 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
Paper focuses on the Material component set; data visualisation and pre-built screen sections aren't part of the library, so you reach for separate charting and layout solutions.
Vireya bundles a charts library and pre-composed blocks beside the components, all sharing the same tokens, so dashboards and marketing surfaces stay consistent with the rest of the UI on both platforms.
Side by side
| Vireya | React Native Paper | |
|---|---|---|
| Primary target | Web-first, mobile via hybrid WebView | React Native (web via RN-web) |
| React Native | Hybrid WebView + typed bridge (one web codebase) | True React Native (native components) |
| Native maturity | Bridge maturing (Expo first) | Mature native components |
| Design language | Neutral, brandable tokens | Material Design 3 |
| Styling | CSS Modules + --v-* tokens (web) | React Native StyleSheet |
| Theming | Token engine, tier-based palette, light/dark | MD3 theming, dynamic color, light/dark |
| Charts & blocks | Bundled, same tokens | None |
| RSC / server web | Server-friendly on web | Not a server-web target |
| Accessibility | Radix + base-ui primitives (web) | RN accessibility + Material patterns |
| Maturity | Early (v0.1.0), actively built | Mature, Callstack-maintained |
Where React Native Paper shines
- It's a mature, faithful Material Design 3 implementation, so you get a recognised, polished design language without building one yourself.
- It's maintained by Callstack, a team with deep React Native expertise, and is production-tested across many shipping mobile apps.
- Its MD3 theming model handles light and dark, color roles and dynamic color coherently across the component set.
- TypeScript support is solid and the component coverage for mobile UI patterns is broad and well-documented.
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.
- Its visual language is neutral and brandable — you theme through `--v-*` tokens via `createTheme()` instead of conforming to Material Design 3 specs.
- It's web-first: static CSS Modules that are RSC-friendly, giving strong server-rendering ergonomics that an RN-first library doesn't prioritise, and the web UI is exactly what ships to mobile.
- A charts library and pre-composed blocks come bundled and share the components' tokens; Paper provides neither.
When to choose React Native Paper
- You're building a true React Native mobile app and want maximum nativeness today.
- You specifically want Material Design 3 from a mature, RN-first library with platform-correct behaviour.
- Material Design is your intended visual language and following its conventions is a goal, not a constraint.
- Mobile is the primary surface and native rendering matters more than web velocity.
When to choose Vireya
- You'd rather keep one web codebase and ship it to mobile as a hybrid native+WebView app than build a true React Native app.
- Web velocity and pushing dynamic screens without store releases matter more than maximum nativeness.
- You want a neutral, brandable look rather than Material Design.
- You want strong web ergonomics — static CSS Modules and RSC-friendly rendering — plus a charts library and blocks that share the components' tokens.
Switching from React Native Paper to Vireya
Moving from React Native Paper to Vireya changes two things at once: the path to mobile and the design language. On the mobile axis you're moving from true React Native components to a hybrid WebView-plus-bridge model — you stop authoring RN components and instead ship one web codebase into a native shell. That's a real architectural shift, not a component swap, so it's a decision to make deliberately: you accept less nativeness for one codebase and dynamic delivery, and for the most native screens Paper remains stronger today.
On the design axis, Paper's components embody Material Design 3, so moving to Vireya's neutral, tokenized components changes how the app looks by design — plan for a visual review, not a pixel-for-pixel port. Mechanically you replace Paper's MD3 theme with a Vireya theme defined once via `createTheme()`, mapping your colors and spacing onto `--v-*` tokens, and lean on Vireya's bundled blocks and charts for surfaces Paper never covered. The native bridge is still maturing, Expo first.
The bottom line
React Native Paper and Vireya both want one product on the phone, but they take different paths to native. Paper ships true React Native Material Design 3 components — the more native and more mature mobile option, years ahead in hardening, and the clear choice if mobile-first Material is your goal. Vireya keeps one web codebase and ships it to mobile as a hybrid native+WebView app with a typed bridge, in a neutral brandable look, with token-driven theming and bundled charts and blocks. If maximum nativeness and Material Design matter most today, Paper wins. If one web codebase, dynamic delivery and a neutral tokenized system matter more, Vireya is the better fit — provided you're comfortable with a younger project whose 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 React Native Paper directly.
Frequently asked questions
Is Vireya a React Native Paper alternative?
They reach mobile by different paths. Paper ships true React Native Material Design 3 components — the more native and more mature option today. Vireya keeps one web codebase and ships it to mobile as a hybrid native+WebView app with a typed bridge, in a neutral brandable look, with bundled charts and blocks. If you want true-native Material Design on mobile, Paper is the better fit.
Do Paper and Vireya reach mobile the same way?
No — this is the key distinction. Paper uses true React Native: its components are real native components rendering through the platform's primitives, and it's the more mature mobile option today. Vireya doesn't author React Native components; 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.
Is Vireya Material Design like Paper?
No. React Native Paper implements Material Design 3. Vireya is a neutral, brandable system themed through --v-* tokens — if you specifically want Material Design on mobile, Paper is the better fit.
Does Vireya include charts and blocks?
Yes — Vireya bundles a tokenized charts library and pre-composed blocks that share the components' tokens. React Native Paper focuses on the Material component set and includes neither.
Will my app look the same after migrating from Paper?
No, and intentionally so. Paper's components are Material Design 3; Vireya's are neutral and brandable. Migrating changes the visual language by design, so plan for a design review rather than a like-for-like port.
Which should I choose?
Choose React Native Paper if you want true React Native Material Design 3 from a mature, mobile-first, Callstack-maintained library. Choose Vireya if you'd rather keep one web codebase and ship it to mobile as a hybrid native+WebView app, with a neutral brandable look, token-driven theming, and bundled charts and blocks.