React Native Performance Crisis: Solving 190% CPU Usage
Article Summary
Matt Sellars from Motion watched their React Native calendar screen peg CPU at 190%. The culprit? View bridges tripling rendering overhead between JS and native code.
Motion started with React Native for the usual startup reasons: shared codebase, small team, fast iteration. But as their calendar app grew, performance collapsed on heavy screens. Even with native-capable engineers and aggressive optimization attempts, the architecture hit a wall.
Key Takeaways
- Calendar screen dropped from 190% CPU to just 5% after native rewrite
- DateTime parsing and React Query caching helped but couldn't fix core rendering bottleneck
- Hybrid approach: build features in React Native first, convert to native based on usage
- LLMs now translate Swift to Kotlin effectively for cross-platform native development
Motion's solution: prototype fast in React Native, then selectively rewrite performance-critical screens in native code for a 97% CPU reduction.
About This Article
Motion's React Native calendar rendered 4 days at once to enable smooth swiping, but the constant JS-to-native bridge crossings caused CPU usage to spike uncontrollably during app startup and navigation.
Matt Sellars' team converted just the calendar screen to native Swift and Kotlin code while keeping the rest of the app in React Native. This let them optimize the performance bottleneck without rewriting the entire app.
The native calendar screen cut CPU usage from 190% down to 5%. It shows that a hybrid approach works well. You can prototype in React Native first, then convert the screens that need it to native code. This gives you both fast iteration and real native performance.
