Middle React Native Developer — React Native interview questions

Walk through what actually happens when JS calls a native method, old architecture vs. new.

On the old bridge, the call gets serialized to JSON, queued, batched, sent across to the native side asynchronously, executed, and the result serialized back — every hop costs time, and nothing is synchronous. With JSI, a TurboModule is a real C++ object that JS holds a direct reference to; calling a method invokes it through a C++ binding with no JSON serialization and no queue, and it can be synchronous when that is what is needed. The trade-off is complexity — writing a TurboModule properly means dealing with codegen and C++, where an old-style bridge module was closer to plain JS-adjacent glue code.

A `FlatList` with a few hundred rows is dropping frames on scroll — how do you approach it?

Profile first — the Flipper/React DevTools profiler or the perf monitor tells you whether the cost is in JS (re-renders, heavy renderItem) or in the native thread (layout, images). Then check the basics: stable keyExtractor, React.memo on the row so a parent state change does not cascade into every row, and no inline arrow functions or object literals passed as props to the row. If layout thrash is the issue, getItemLayout avoids a measurement pass per item, and if the list itself is the bottleneck at scale, swapping to FlashList is often the pragmatic fix over hand-tuning FlatList further.

A feature needs a capability React Native does not expose — how do you get to native code, and what has to be duplicated?

You write a native module — a Swift/Objective-C implementation for iOS and a Kotlin/Java implementation for Android — exposing the same method signature on both sides, because JS calls one JS-facing API that has to resolve to a real implementation on whichever platform it is running on. Skipping one platform means the app crashes or silently no-ops there, so the two implementations need to genuinely do the same thing, not just share a name. Testing means running on both a real device or simulator per platform, not just trusting that "it built."

How do you handle deep links reliably, including from a cold start?

Register the URL scheme or universal link/app link in native config (Info.plist / AndroidManifest.xml) and in the navigator's linking config, mapping URL patterns to screens and params. The tricky part is the cold start — if the app was not running, Linking.getInitialURL() has to be checked on launch and used to set the initial navigation state, because the Linking event listener alone only catches links that arrive while the app is already open. Universal links additionally need the associated-domains / assetlinks.json files hosted on your domain so the OS trusts the app to handle that URL instead of opening a browser.

What is the difference between an OTA update and a store release, and when can you use which?

An OTA update (CodePush, Expo Updates) pushes a new JS bundle to installed apps directly, without app store review, and users get it on next app launch or a background check — good for JS-only bug fixes and content changes. Anything that touches native code — a new native module, a permission addition, a native dependency bump — is not in the JS bundle at all, so OTA cannot ship it; it needs a real build and store submission. Apple's guidelines explicitly restrict OTA to not "significantly change the app's primary purpose," so a team that leans on OTA for anything beyond quick fixes risks the store account, not just the update.