Day 68: Trade-offs Analysis: Native vs Cross-Platform Performance
Give a nuanced, evidence-based answer to "why not just build native" that acknowledges real performance gaps without overselling them.
Study
Concepts
Where the performance gap is real vs where it has closed
Fully native (Swift/SwiftUI, Kotlin/Jetpack Compose) has direct, zero-abstraction access to platform APIs and rendering — for extremely performance-sensitive work (custom camera pipelines, complex real-time graphics/games, heavy on-device ML inference), it retains a genuine edge. But for the vast majority of typical app UI — lists, forms, navigation, standard animations — the New Architecture (Days 32-33: JSI, Fabric, TurboModules) has closed most of the historical gap that made classic React Native visibly janky; a well-built RN app today is not meaningfully distinguishable from native by most users for typical product UI.
The honest framing for an interview: performance is not a single axis — RN/cross-platform trades a SMALL amount of peak performance ceiling for a LARGE amount of development velocity (one team, one codebase, faster iteration, shared business logic between platforms) — the right choice depends on whether the product's differentiator IS raw performance (a game, a pro video-editing tool) or is something else (a business app where time-to-market and team efficiency matter more).
A structured way to answer this in an interview
Name the actual dimensions: startup time (Hermes has narrowed this significantly, Day 39), animation/gesture smoothness (Reanimated 3's UI-thread worklets, Day 38, address the historical weak point directly), bundle size (native apps avoid shipping a JS engine + bundle, a real fixed cost RN pays), and engineering velocity (one RN team vs two native teams, faster cross-platform feature parity). A strong answer states a concrete recommendation ("for this product, I would choose RN because X, Y, Z, and revisit only if profiling reveals a SPECIFIC bottleneck the New Architecture cannot address") rather than a hedge-everything non-answer.
See It
Visualizations
Visualization
Native vs React Native (New Architecture), by dimension
| Fully Native | React Native (New Arch) | |
|---|---|---|
| Typical UI (lists, forms, nav) | Excellent | Excellent — gap mostly closed |
| Complex real-time graphics/games | Best choice | Possible, but native/engine-based tools usually still win |
| Startup time | Fastest | Much improved with Hermes, still a small gap |
| Gesture/animation smoothness | Native by default | Near-native with Reanimated 3 worklets |
| Dev velocity (2 platforms) | Two codebases, two teams | One codebase, one team, shared logic |
| Bundle/binary size | Smaller, no JS engine shipped | Larger — ships Hermes + JS bundle |
Build It
Code Examples
A concrete answer template, stated as reasoning
"For a typical product app (lists, forms, checkout, profile, feed),
I'd choose React Native on the New Architecture:
- The UI performance gap for standard interactions has mostly closed
since Fabric/JSI/Reanimated 3 landed.
- One team ships both platforms with shared business logic, which
matters more for iteration speed than the residual performance gap.
- I'd measure real user metrics (startup time, frame drops via the
RN Perf Monitor, crash-free rate) post-launch rather than assume
a problem exists.
I would revisit this ONLY if profiling reveals a specific,
unsolvable-in-RN bottleneck — e.g. a custom camera pipeline or
real-time 3D rendering — and even then, I'd consider a native MODULE
for just that feature (Day 35) before rewriting the whole app natively."Remember
Key Takeaways
- The performance gap is real for extreme cases (games, custom camera/ML pipelines) but has mostly closed for typical product UI on the New Architecture.
- Frame the tradeoff honestly as performance ceiling vs development velocity, not "RN is slow" vs "RN is exactly as fast as native".
- Cite the specific mechanisms (JSI, Fabric, Hermes, Reanimated 3 worklets) that closed the historical gap — this signals real understanding, not opinion.
- A native module (Day 35) for one specific bottleneck is usually a better fix than abandoning cross-platform for the whole app.
- State a concrete recommendation with reasoning, rather than an unhelpful "it depends" with no follow-through.
Do It
Practice
- 1Write your own one-paragraph answer template (like the example above) for a DIFFERENT product type (a social feed app, a fintech trading app).
- 2Research one real production app that migrated from native to RN (or vice versa) and summarize their stated reasoning in 3 sentences.
- 3List two specific RN Perf Monitor / profiling metrics (Day 40) you would track post-launch to validate or challenge this recommendation.