Going From React to React Native: What Transfers and What Doesn't

When our healthcare platform needed a mobile app, the reasoning was obvious: the team knows React, React Native is React, therefore the team knows React Native. That syllogism is about 60% true — and the missing 40% is exactly where the schedule risk lives. Having shipped the app, here's the honest transfer report for React developers eyeing mobile.

What I assumed (and what the assumption got right)

The pitch is "learn once, write anywhere," and the core of it holds. Components, props, state, hooks, context — identical. Your mental model of UI as a function of state, your data-fetching patterns, your TypeScript — all of it transfers untouched. Our usePatientData hooks moved from the web portal to the app almost verbatim, and that's not a small thing: the hard-won knowledge (state architecture, API contracts, error handling) carried over completely.

What doesn't transfer is everything that touches the platform. Which turns out to be more than you'd think.

What transferred easily

• Component thinking and hooks. A React developer reads a React Native codebase on day one. JSX, composition, custom hooks — same language, same idioms.
• State management. Context, Zustand, Redux — all identical. Our state layer was shared code between web and mobile from day one.
• The ecosystem's shape. Navigation, forms, data fetching all have dominant libraries with React-familiar APIs (React Navigation feels like a cousin of your router). You're never lost, just occasionally surprised.

What didn't: the platform 40%

Styling is a dialect, not the same language. There's no CSS — no cascade, no inheritance, no pseudo-classes, no hover. Styles are JavaScript objects, everything is Flexbox (defaulting to flex-direction: column), and units are unitless density- independent pixels:

// Not CSS — no classes, no cascade, flexbox-only
const styles = StyleSheet.create({
  card: {
    flexDirection: 'row',
    alignItems: 'center',
    padding: 16,
    borderRadius: 8,
    // no boxShadow — shadows are platform-specific (elevation on Android)
  },
});

If your web styling instincts lean on the cascade and global styles, expect friction; if you already think in flexbox and component-scoped styles, it's a week of adjustment.

Native modules are a new competency. The moment you need something beyond the core — camera, biometrics, push notifications, secure storage (all four, for a healthcare app) — you're linking native modules, editing platform config, and debugging build errors in Xcode and Gradle. This is the part that's nothing like web development, and it's where our estimates slipped most. Budget real time for the native toolchain, especially iOS signing and store review.

Performance tuning is different in kind. The JS thread and the UI thread are separate; a heavy computation doesn't just jank scrolling — it can freeze gesture response entirely. Long lists must be virtualized (FlatList, not map), animations should run on the UI thread (Reanimated), and low-end Android devices — a large share of our patient base — punish laziness that a desktop browser forgives.

Platform gotchas worth knowing upfront

• There is no DOM. No document, no window, no DOM-based libraries. Anything in your shared code that touches them needs abstraction.
• Debugging is heavier. Better than it was (Flipper, Hermes tooling), still not Chrome DevTools on your markup.
• Releases go through app stores. Web deploy discipline ("ship it now, fix it in an hour") doesn't exist; review cycles change how you plan releases and hotfixes.
• Every device is different. Notches, back gestures, keyboard behavior, safe areas — test on real hardware early, especially cheap Android hardware.

Advice for making the jump

Start with Expo — it defers the native toolchain until you genuinely need it, which for many apps is never. Share your logic layer (hooks, state, API clients) between web and mobile but not your components — a good mobile UI is not a squeezed web UI. And treat the first month as learning a dialect: you speak React fluently, but mobile has its own idioms, and the developers who struggle are the ones who insist it's "just React."

It's 60% just React. Respect the other 40% and the transition is one of the highest- leverage moves a web developer can make — one skill set, two platforms, and (for us) one team shipping a patient portal and its app.