Edward Lee
React NativeMobileEngineering

5 Things Web Developers Get Wrong About React Native

After two years shipping a production React Native app, here's what I wish I'd known coming from a web background.

April 17, 2026
5 min read
0 comments

I came to React Native from a React web background and made every predictable mistake. Two years and one production app later, here's what I'd tell myself on day one.

1. The bridge is not free

On the web, calling a JS function that touches the DOM is cheap — the browser batches and optimizes it. In React Native (pre-Fabric), every JS-to-native call crosses the bridge. Doing this in a tight loop, especially in animation callbacks, will drop frames.

The fix: push anything animation-related into Animated or react-native-reanimated so it runs natively, off the JS thread. If you're still writing setState inside an onScroll handler, you're already in trouble.

2. ScrollView is not overflow: scroll

On the web, overflow: scroll is lazy — the browser only renders what's in the viewport. ScrollView in React Native renders everything. Mount a list of 200 items in a ScrollView and you'll render 200 items upfront.

Use FlatList or FlashList for any list longer than ~20 items. FlashList from Shopify is particularly good — it recycles cells and is meaningfully faster than FlatList on long lists.

3. Flexbox defaults are different

React Native uses Yoga for layout, which is mostly CSS Flexbox but with key differences:

  • flexDirection defaults to column, not row
  • position: fixed doesn't exist — use position: absolute with careful parent containment
  • % units work only if the parent has an explicit dimension

I wasted days debugging layouts that would have taken 10 minutes on the web because I kept forgetting these defaults.

4. Metro is not Webpack

Metro doesn't support all the things Webpack/Vite do out of the box. No built-in SVG support, no barrel file tree-shaking, quirky behavior with certain CommonJS modules.

Always check bundle size with react-native-bundle-visualizer before your first production build. We shipped 3MB of unused i18n locale data for six months before catching it.

5. iOS and Android are genuinely different products

Sharing logic is great. Sharing UI wholesale is often a mistake. iOS users expect swipe-to-go-back, bottom tab bars, and haptic feedback on actions. Android users expect the back button to work predictably and material-style ripples on touchables.

We spent two sprints retrofitting Android-specific behaviors we'd ignored during initial development. Building the platform differences in from the start would have cost half the time.


React Native is good, and it gets better every release. But it rewards people who understand the native layer, not just the JS surface. Spend a week reading the React Native architecture docs — it'll pay back in debugging time alone.

Enjoyed this post?

Comments

Loading comments…

Press Enter to send · Shift+Enter for new line