React Native interview questions

What is the difference between props and state in React Native?

Props are read-only data passed down from a parent component and owned by whoever passes them; state is local to a component and can change over time via useState or useReducer. A component that receives the same props twice with no state change should render the same output — that is what makes props predictable to reason about. Passing setters down as props ("lifting state up") is the standard way for a child to trigger a state change it does not own.

What is JSX and what does it actually compile to?

JSX is syntactic sugar for React.createElement calls — <View style={styles.box}>{text}</View> becomes a nested tree of element objects, not real DOM nodes, since there is no DOM on native. Babel's transform turns the tags into function calls before the JS ever runs, so JSX is a build-time convenience, not a runtime feature. In React Native those element objects eventually describe a native view hierarchy instead of HTML.

What do `useState` and `useEffect` do, and when does the effect run?

useState gives a component a piece of state and a setter that triggers a re-render when called; useEffect runs a side effect after the render commits, and only re-runs when something in its dependency array changed. Forgetting a dependency is the most common source of stale closures — the effect keeps referencing the value from the render it was created in. An empty dependency array means "run once on mount," and no array at all means "run after every render."

How does styling work in React Native, and why does Flexbox behave differently than on the web?

There is no CSS — styles are JS objects created with StyleSheet.create, mapped to native view properties under the hood. Flexbox is the layout engine, but flexDirection defaults to column instead of row, there is no CSS cascade, and units are unitless density-independent pixels rather than px/em/rem. Percentage-based widths, flex: 1 to fill remaining space, and justifyContent/alignItems for alignment cover most real layouts.

How does navigation work with React Navigation, and what does deep linking add?

React Navigation models the app as a tree of navigators — stack, tab, drawer — each screen registered with a name, and navigation.navigate('Screen', params) moves between them while keeping a history stack for the back gesture. Deep linking maps an external URL scheme or universal link to a specific screen and params, so a push notification or a web link can drop the user directly into, say, an order-detail screen instead of the app's home. Getting it right means handling both a cold start (app not running) and a warm resume from a link.

What is the bridge, and how does it differ from JSI and the New Architecture?

In the old architecture, JS and native code do not share memory — they talk through the bridge, an asynchronous, batched, JSON-serialized message queue, which means every native call has serialization cost and latency. JSI (JavaScript Interface) replaces that with direct C++ bindings, letting JS hold references to native objects and call their methods synchronously, no serialization required. The New Architecture builds on JSI: TurboModules replace native modules, and Fabric replaces the old UI manager, both able to talk to native code directly instead of queuing through the bridge.

How do you keep a long `FlatList` from getting janky?

Give every item a stable keyExtractor, memoize the row component with React.memo so a parent re-render does not re-render every row, and avoid inline function and object literals in renderItem since a new reference every render defeats memoization. getItemLayout skips a measurement pass when row height is fixed, and windowSize/initialNumToRender/removeClippedSubviews trade memory for scroll smoothness. For very large or complex lists, FlashList from Shopify solves the same problem with less tuning.

What are the real differences between building for iOS and Android in React Native?

Safe areas, keyboard behavior, and shadow styling (shadow* props on iOS vs. elevation on Android) diverge enough that pixel-perfect parity needs platform-specific code via Platform.select or .ios.js/.android.js file extensions. Permissions, push notification setup, and background task limits follow each platform's own rules — Android's background execution limits and iOS's stricter App Store review are different constraints, not just different APIs. A native module written for one platform needs a real counterpart in Swift/Objective-C and Kotlin/Java before it works on both.

How does a release actually ship — what do Metro, OTA updates and store review have to do with each other?

Metro bundles and serves the JS during development and packages it into the app binary for release; it is not part of what ships to users, only the build tool. OTA update services like CodePush or Expo Updates push a new JS bundle directly to installed apps without an App Store or Play Store review, which is fast for bug fixes but explicitly disallowed for anything that changes native code or crosses what the store considers "not just content." Native changes — a new native module, a permission, an SDK bump — always require a full build and a new store submission, so a team ships two speeds: OTA for JS-only fixes, store releases for anything native.