skip to content

For a React Native product adding a web version, how do you decide between sharing the UI through React Native Web and building a separate web app?

level: principalimportance: should knowfreq 30%

answer

  1. count the native-only features first
  2. app-like versus content-like
  3. share logic even when UI splits
  4. per-screen platform files as a middle path
  5. who owns the web design system

basics

~10 s

Share UI through React Native Web when the web product is app-like and most screens use portable components; build web UI separately when it is content-led, SEO-led or native-feature-heavy, and share logic either way.

solid answer

~50 s

It is a judgement call, and I would make it from evidence. First inventory native-only features (camera, push, biometrics, background work, platform navigation): if they dominate, the web gets a different product anyway. Then classify the web surface: an **app-like** tool behind a login fits React Native Web well, while a **content-heavy, SEO-led** site wants semantic HTML, CSS and web routing that React Native's primitives only approximate. Consider the team: shared UI means one design system in React Native styles; a separate app lets web specialists use their own tooling. The usual answer is a spectrum, not a binary: share business logic, API clients, state and validation in packages; share most screens through React Native Web; override the few that diverge with `.web.tsx` files; and split entirely only when the web product is truly different. Revisit when the ratio of overrides to shared screens grows.

go deeper

for a junior

Recall that React Native Web lets a React Native app run in a browser, and that not every feature or screen carries over.

for a middle

Describe the options, from full sharing to shared logic with separate UI, and when .web.tsx overrides are enough.

for a senior

Bring evidence: the native-only feature inventory, the surface type, SEO and accessibility needs, and the cost of overrides in an existing codebase.

for a principal

Own the trade-off: team structure, design-system ownership, bundle and SEO budgets, and the signals that should trigger changing the strategy.

## Why there is no single right answer Adding a web version to a React Native product can mean anything from "the same app in a browser tab" to "a marketing site plus a lightweight account page". **React Native Web** makes sharing UI possible; it does not make it free. The decision trades reuse against how well the result fits the web, and the right answer depends on the product, the team and the roadmap. ## The evidence to gather first 1. **Native-only feature share.** List what has no web implementation or a weak one: camera and scanning, push notifications, biometrics, background tasks, platform navigation patterns, native modules the team wrote. If most screens depend on them, the web product is different by nature. 2. **Surface type.** - *App-like* (dashboards, editors, messaging behind a login): React Native Web's component model fits; SEO does not matter; users expect app behaviour. - *Content-like* (landing pages, articles, catalogues): semantic HTML, links, CSS layouts, fast first paint and crawlability dominate; React Native primitives reach them only partly (for example through `href` and `role` props). 3. **Team skills and ownership.** Shared UI means the web team writes React Native styles and components, with no selectors, media queries or `className`. A separate app lets web specialists use CSS, their component libraries and their testing tools. 4. **Design system.** One design system across platforms is a strong argument for sharing; a web brand that must look different argues the other way. 5. **Performance and bundle budget.** Shared screens bring React Native's abstractions into the web bundle; a content site may need a leaner stack. ## The options as a spectrum | Approach | Shares | Best when | |---|---|---| | Full sharing via React Native Web | UI, navigation, logic | app-like web, one design system, few native-only features | | Shared with overrides | most screens; `.web.tsx` for the divergent ones | a handful of screens differ (camera, maps, payments) | | Shared logic, separate UI | hooks, state, API clients, validation, types | content-led or SEO-led web, a web-specialist team | | Fully separate | nothing but the backend | different products that happen to share a brand | Most teams land in the middle two rows. Sharing **logic** (data fetching, state, validation, domain types) is almost always worth it because it carries no platform assumptions. ## A worked example A field-service app has job lists, a job detail screen, photo capture, barcode scanning, offline sync and push notifications. The company wants office staff to review jobs in a browser. - The office surface is **app-like and behind a login**: lists, details, filters. These screens are good sharing candidates. - Capture, scanning, offline sync and push are **native-only or irrelevant** in the office: the web version shows photos and scan results but does not create them, so those screens get `.web.tsx` variants or are left out of web navigation. - SEO is irrelevant; accessibility for keyboard users matters, so shared components must use `role` and labels properly. The resulting plan: shared logic packages, shared list and detail screens through React Native Web, web-specific variants for the capture flows, and a review point after the first release to count overrides. ## Signals that the choice needs revisiting - The number of `.web.tsx` overrides keeps growing relative to shared screens. - Web accessibility or SEO audits keep failing on generated markup. - Web engineers spend more time working around React Native's model than building features. - Or the reverse: two teams keep reimplementing the same screens and drifting apart. ## Tools that change the calculus - **Expo** supports web as a first-class target, including static rendering for SEO, and its SDK packages declare which platforms they support, which makes the inventory in step 1 cheaper. - **Platform files** allow a per-screen escape hatch without forking the app. - React Native Web is optional even in an Expo project: web-only screens can use React DOM elements directly. ## How to present it State the evidence you would collect, the spectrum of options, a default ("share logic always, share UI where the surface is app-like, override per screen, split only for genuinely different products") and the metrics that would make you change course. An interviewer is judging the reasoning, not a specific answer.

  • In a shared React Native and web codebase, what is almost always worth sharing even if the UI is built separately?
    Business logic that carries no platform assumptions: API clients, data fetching and caching, state management, validation rules, domain types and formatting. It lives in packages both apps import, so behaviour stays consistent while each UI fits its platform.
  • What metric would tell you that a React Native Web sharing strategy is failing?
    A rising ratio of `.web.tsx` overrides and web-only workarounds to shared screens, persistent web accessibility or SEO audit failures on generated markup, or web features consistently taking longer than their native counterparts. Any of these says the shared layer costs more than it saves.

saying these in an interview costs you the question

  • React Native Web means the web app needs no web-specific work.
  • Sharing UI is always cheaper than building the web separately.
  • If the UI is built separately, nothing should be shared.
  • SEO-heavy marketing pages are the ideal fit for React Native Web.
  • The decision is made once and never revisited.