Question 1

How does React Native's New Architecture with TurboModules and JavaScript Interface (JSI) eliminate the performance bottleneck of asynchronous JSON serialization over the legacy bridge, allowing synchronous C++ memory access between JavaScript and native code?

Accepted Answer

In the old architecture, every call from JS to native code went through "the bridge" - a single asynchronous, batched queue. Whatever you passed (numbers, objects, callbacks) got serialized to a JSON string, queued, sent to the native side, deserialized, processed, and the result made the same round trip back. That serialization step is the actual bottleneck - it's why even a trivial native call like reading a device setting was always async, and why high-frequency calls (scroll position, gesture coordinates) could flood the bridge and drop frames.

JSI removes the bridge for this purpose. It gives JavaScript a C++ API to hold direct references to native objects ("host objects") living in the same memory space as the JS engine. Calling a method on one is a normal C++ function call - no queue, no JSON, no thread hop unless the native side explicitly chooses to do async work. TurboModules build on this: a native module is a JSI host object lazily created only when JS first touches it, instead of every module eagerly instantiating at app launch like the old bridge did.

Concretely: under the old bridge, `NativeModules.Battery.getLevel()` had to return a Promise, because the call was queued and serialized even for a single float. With JSI, a TurboModule can expose `getLevelSync()` as a genuinely synchronous call, because JS is calling straight into C++ memory and getting the value back immediately - something that was structurally impossible before.

Question 2

You need to build a custom high-performance map marker component using React Native Fabric. Walk through writing the TypeScript component spec with Codegen, defining the C++ Shadow Node descriptor, and implementing the platform-specific native view managers on iOS and Android.

Accepted Answer

Fabric replaces the old "pass props through the bridge as JSON, native side interprets them loosely" model with a strongly-typed pipeline. You start by writing a Codegen spec: a TypeScript file describing the component's props and events using RN's typed primitives, which the build step reads to auto-generate matching C++, Objective-C++, and Java/Kotlin interfaces - so a typo or type mismatch fails at build time instead of silently no-oping at runtime.

```ts
// MapMarkerNativeComponent.ts
import type { ViewProps } from 'react-native';
import codegenNativeComponent from 'react-native/Libraries/Utilities/codegenNativeComponent';
import type { Double } from 'react-native/Libraries/Types/CodegenTypes';

export interface NativeProps extends ViewProps {
  latitude: Double;
  longitude: Double;
  onMarkerPress?: (event: { nativeEvent: { markerId: string } }) => void;
}

export default codegenNativeComponent<NativeProps>('MapMarkerView');
```

Codegen turns this into a C++ `ShadowNode` descriptor (a `MapMarkerViewShadowNode` extending `ConcreteViewShadowNode`) that participates in Fabric's Shadow Tree - the off-main-thread tree Fabric diffs and measures layout against, using Yoga. This is what makes Fabric faster than the old bridge-based UIManager: layout and diffing happen on a background thread against this C++ tree, and only the final mutations get committed to the actual platform views.

On each platform you then implement a view manager that maps the generated props onto a real native view: on iOS, a subclass of `RCTViewComponentView` overriding `updateProps` to set `latitude`/`longitude` on your `MKAnnotationView`/marker layer; on Android, a `ViewManager` (or the newer `ViewManagerDelegate` generated by Codegen) whose `@ReactProp` setters update your `MapView` marker. The Codegen-generated interfaces guarantee both native implementations receive exactly the props/types the TS spec declared.

Question 3

A custom native module broadcasts real-time BLE signal measurements to JavaScript via NativeEventEmitter. When components unmount and remount, duplicate listeners accumulate, causing severe memory leaks. How do you properly manage addListener and removeListeners lifecycles on both native and JS sides?

Accepted Answer

The leak happens because `emitter.addListener('BLEReading', cb)` returns a subscription object, and a lot of code forgets to call `.remove()` on it when the component unmounts - so every mount adds a new listener that lives forever, and every emitted event fires all of them, including ones attached to long-gone components.

The fix is symmetrical cleanup in a `useEffect`: subscribe on mount, and call `subscription.remove()` in the cleanup function so exactly one listener is alive per mounted component.

```jsx
useEffect(() => {
  const emitter = new NativeEventEmitter(NativeModules.BLEModule);
  const sub = emitter.addListener('BLEReading', (reading) => {
    setSignal(reading.rssi);
  });
  return () => sub.remove();
}, []);
```

On the native side, the module should also implement `addListener`/`removeListeners` (required by `NativeEventEmitter` even if they're no-ops) and, more importantly, should stop the underlying BLE scan/observer when the last JS listener detaches (tracked via a listener count) rather than running it for the app's whole lifetime. Without that, you don't leak JS memory, but you do leak battery and a native resource that outlives any UI that cares about it.

Question 4

A native iOS module processes biometric authentication in a background queue and invokes a React Native JS callback directly from that background thread, causing intermittent crashes. Explain thread scheduling in React Native bridge modules and how to dispatch callbacks safely to the JS thread.

Accepted Answer

React Native (pre-Bridgeless) runs on several distinct threads: the JS thread (where your JS/Hermes VM executes), the main/UI thread (where native views actually render), and a pool of native module threads for module method execution, plus the shadow/layout thread. A JS callback captured from a native method is a bridge-managed object that expects to be invoked through the bridge's own dispatch mechanism, not from an arbitrary thread you happen to be on - calling it directly from a background GCD queue races with the bridge's internal bookkeeping and is exactly the kind of thing that produces intermittent, hard-to-reproduce crashes.

The fix is to hop back onto the correct queue before invoking the callback. Each `RCTBridgeModule` can declare its own `methodQueue`, but the JS callback itself still needs to be invoked in a way the bridge expects:

```objc
- (void)authenticateWithCallback:(RCTResponseSenderBlock)callback {
  [self.biometricQueue addOperationWithBlock:^{
    BOOL success = [self runBiometricCheck];
    dispatch_async(dispatch_get_main_queue(), ^{
      callback(@[success ? [NSNull null] : @"failed", @(success)]);
    });
  }];
}
```

The general rule: do the actual native work on whatever thread makes sense for it (background queue for anything blocking, like biometrics or disk I/O), but always marshal the final `callback`/`resolve`/`reject` invocation back onto the thread the bridge expects - which in practice, for most bridge callback invocations, is triggered through `dispatch_async` back to a bridge-safe queue rather than calling it inline from arbitrary background work.

Question 5

A drag-to-dismiss modal built with standard React state updates stutters because touch events are bottlenecked on a busy JavaScript thread. How do you refactor the gesture using react-native-gesture-handler and react-native-reanimated Shared Values and Worklets to run animations entirely on the UI thread at 120fps?

Accepted Answer

The stutter happens because `useState` + `PanResponder`-style gesture handling round-trips every touch move through the JS thread: native sends a touch event over the bridge, JS computes a new `top`/`translateY` value, calls `setState`, React re-renders, and the new style is shipped back to native - all before the next frame can paint. If the JS thread is busy (data fetching, list re-renders, anything), frames get dropped and the drag visibly lags behind your finger. Gesture Handler moves gesture *recognition* to the native side, and Reanimated moves the *animation values themselves* (Shared Values) onto the UI thread, connected via worklets - small JS functions that Reanimated's Babel plugin compiles to also run on the UI thread, in the UI thread's own JS runtime, with no bridge round trip per frame. ```jsx const translateY = useSharedValue(0); const gesture = Gesture.Pan() .onUpdate((e) => { translateY.value = e.translationY; }) .onEnd(() => { if (translateY.value > 150) translateY.value = withTiming(1000); else translateY.value = withSpring(0); }); const style = useAnimatedStyle(() => ({ transform: [{ translateY: translateY.value }], })); ``` Because `onUpdate` and `useAnimatedStyle` run as worklets on the UI thread, the modal's position updates every frame in lockstep with the touch, completely independent of whatever the JS thread is doing - which is what gets you a smooth 120fps drag on ProMotion displays even under JS thread pressure.

Question 6

Design an offline-first mobile data layer for a field inspection app using an embedded SQLite database (e.g., WatermelonDB or OP-SQLite) that handles offline CRUD operations, tracks dirty records, and performs delta-based synchronization with conflict resolution upon reconnecting.

Accepted Answer

The core idea is that the local SQLite database is the source of truth for the UI at all times - every read and write goes to it first, synchronously from the app's perspective, and the network is treated as a background replication target rather than something the UI waits on. Every writable table gets sync metadata columns: `_status` (`created`/`updated`/`synced`/`deleted`), `_changed` (which fields changed), and a `last_modified` timestamp or version counter, so you always know exactly which rows are "dirty" without scanning the whole table.

WatermelonDB gives you this model out of the box via its `synchronize()` API: it pulls a delta (`{ changes, timestamp }`) from your server since the last synced timestamp, applies remote changes locally, then pushes local rows still marked dirty. The server-side sync endpoint has to be delta-aware too - it should accept a `lastPulledAt` cursor and return only rows changed since then, not a full table dump, or sync cost grows unbounded as the dataset grows.

Conflict resolution needs an explicit strategy because the same inspection record can be edited offline on two devices before either syncs. A simple, defensible default is last-write-wins by field-level timestamp (not whole-record) so two people editing different fields on the same record don't clobber each other; anything needing correctness beyond that (e.g. a signature field that must never be silently overwritten) should be flagged for manual merge review rather than auto-resolved. The critical failure mode to design against is a push succeeding on the server but the local "mark as synced" update failing (app killed mid-sync) - which is why the local dirty flag should only clear after the server acknowledges, and a resumed sync should be idempotent against rows it already pushed.

Question 7

When an app initializes, reading user theme and auth tokens from AsyncStorage causes a visible UI flicker because the storage read is asynchronous. How do you integrate a synchronous native storage engine (e.g., MMKV) with a Zustand store to enable synchronous, zero-bridge state hydration before the initial render pass?

Accepted Answer

AsyncStorage is asynchronous by design (it's a Promise-based key-value store backed by native storage), so any read of it happens after your first render has already committed - which is exactly why apps flash a default/light theme for a frame before the persisted dark theme kicks in. MMKV, by contrast, is a native key-value store exposed through JSI, so reads and writes are genuinely synchronous C++ calls with no Promise and no bridge round trip - you can call `storage.getString('theme')` at module-eval time, before React even renders.

Wiring this into Zustand means skipping Zustand's usual async `persist` middleware flow (which itself introduces a rehydration delay) and instead reading MMKV synchronously as the store's initial state:

```js
import { MMKV } from 'react-native-mmkv';
import { create } from 'zustand';

const storage = new MMKV();

export const useThemeStore = create((set) => ({
  theme: storage.getString('theme') ?? 'light',
  setTheme: (theme) => {
    storage.set('theme', theme);
    set({ theme });
  },
}));
```

Because `storage.getString('theme')` resolves synchronously at store-creation time (before any component mounts), the very first render already has the correct persisted theme - there's no "flash of default state" window to fix, because the wrong state never gets rendered in the first place.

Question 8

A user clicks an email deep link to an order detail screen while the app is in the background. How do you configure React Navigation linking prefixes, state serialization, and custom action handling so that pressing the back button navigates up the hierarchy rather than exiting the app?

Accepted Answer

React Navigation's `linking` config maps a URL pattern to a navigation state tree, not just a single screen - which is the key thing to get right here. If you only map the deep link to the `OrderDetail` screen directly, React Navigation pushes it as the sole entry in the stack, so there's nothing to go "back" to and the back button (or gesture) exits the app.

```js
const linking = {
  prefixes: ['myapp://', 'https://myapp.com'],
  config: {
    screens: {
      Home: 'home',
      Orders: {
        screens: {
          OrderList: 'orders',
          OrderDetail: 'orders/:orderId',
        },
      },
    },
  },
};
```

With `OrderDetail` nested under an `Orders` stack, React Navigation reconstructs the *whole* navigation state when resolving the deep link - `[Home, Orders/OrderList, Orders/OrderDetail]` - not just the leaf screen, so pressing back takes you to `OrderList`, then `Home`, before finally exiting. For cases where you want a custom hierarchy that doesn't match the URL structure (e.g. always inserting `Home` underneath any deep link regardless of what the URL implies), you override `getStateFromPath` to build that state tree yourself instead of relying on the default config-based resolution.

Question 9

Explain how the Hermes JavaScript engine improves React Native startup performance and reduces memory usage through ahead-of-time (AOT) bytecode compilation, and how Hermes handles garbage collection under low-memory Android environments compared to JavaScriptCore.

Accepted Answer

With JavaScriptCore, your JS bundle ships as source text (or a minified blob of it) and gets parsed and JIT-compiled on the device at app startup - every launch repeats that parse/compile work. Hermes instead compiles your bundle to bytecode at build time on your CI machine, and ships that bytecode in the app binary. At runtime, the device just loads and interprets already-compiled bytecode, skipping the parse-and-compile step entirely - which is the main reason Hermes apps show a measurably faster time-to-interactive, especially on low-end Android hardware where JIT compilation is slow.

On memory, Hermes was purpose-built for mobile constraints rather than adapted from a desktop-browser engine: it uses a generational, mostly non-moving garbage collector tuned to keep heap overhead small, and it can start executing without holding the full parsed AST or an internal JIT-compiled representation in memory the way a JIT engine does. JSC, being built for desktop/Safari's JIT-heavy workloads, tends to hold more memory for its optimizing compiler's bookkeeping - real overhead on a low-RAM Android device where the OS aggressively kills backgrounded apps under memory pressure.

In practice you enable this with one flag (`hermesEnabled: true` in `android/app/build.gradle`, and it's the default on iOS since RN 0.70+), and you can inspect the difference yourself by comparing `adb shell dumpsys meminfo <package>` between a JSC build and a Hermes build of the same app on the same device.

Question 10

Migrating a heterogeneous feed from FlatList to a recycler-backed list library causes blank white cells to flash during rapid scrolling. How do you diagnose estimated-item-size misconfigurations, implement item recycling keys, and eliminate heavy re-renders inside list cells?

Accepted Answer

Recycler-backed lists like FlashList pre-measure and lay out cells based on an estimated size (`estimatedItemSize`), then recycle the underlying native view components as you scroll rather than mounting/unmounting a new one per row like FlatList does. Blank cells during fast scroll almost always mean the estimate is badly wrong for at least one item type - the recycler scrolls past faster than it can render new content into a reused view, so you briefly see the empty recycled shell before it repaints. The fix has three parts. First, set `estimatedItemSize` close to your actual average row height (measure it with the Dev Menu's layout inspector or a one-off `onLayout` log) rather than guessing; for a heterogeneous feed with genuinely different card types, use `overrideItemLayout` to give per-type size hints instead of one global estimate. Second, give each item type a stable `getItemType` value so the recycler pools views by type and never tries to recycle a text-only card's view into a media card's slot. Third, memoize the row renderer (`React.memo` on the cell component, plus stable callbacks via `useCallback`) so scrolling doesn't trigger expensive re-renders that compete with the recycler for frame time - a heavy re-render inside a cell is often what's actually starving the recycler and causing the blank flash, not the size estimate alone. ```jsx } estimatedItemSize={180} getItemType={(item) => item.type} /> ```

Question 11

Your React Native JS bundle size has reached 18MB, causing slow app cold starts on low-end devices. How do you use a Metro bundle visualizer to identify bloat, configure dynamic imports (React.lazy), and enable inline requires to defer module execution until needed?

Accepted Answer

An 18MB bundle is almost never one giant feature - it's usually a handful of oversized dependencies (a moment.js-style date library pulling in every locale, an icon font library bundling every icon, a chart library) that get pulled in transitively and never trimmed. The first step is visibility: run `npx react-native-bundle-visualizer` (or Metro's own `--stats` output through `source-map-explorer`), which renders a treemap of what's actually inside the bundle by size - this is how you find, concretely, "this one icon library is 3MB because it ships every font weight."

Once you know the big offenders, two independent levers help. `React.lazy` + `Suspense` (RN supports this since 0.70+ works via Metro's dynamic `import()` support) defers loading a whole screen's module graph until it's actually navigated to, rather than parsing/executing it at app boot - useful for rarely-visited screens like "Settings" or "Help." Separately, `inlineRequires` (set in `metro.config.js`) rewrites top-level `require()` calls into inline, lazy ones, so a module imported at the top of a file only actually executes the first time something in that file uses it - this alone commonly cuts cold-start time meaningfully because a lot of imported code (analytics SDKs, rarely-used utils) never needs to run at launch at all.

```js
// metro.config.js
module.exports = {
  transformer: {
    getTransformOptions: async () => ({
      transform: { inlineRequires: true },
    }),
  },
};
```

Note inline requires and bundle *size* are separate problems - inline requires speeds up startup by deferring execution, but the treemap is what tells you which dependencies to actually replace or code-split to shrink the download itself.

Question 12

During an animation, the native UI thread runs at a steady 60fps, but touch inputs feel completely unresponsive. How do you profile the React Native JavaScript thread using the Performance Monitor and React DevTools Profiler to isolate JS event loop blocking from native frame drops?

Accepted Answer

This split symptom - smooth animation, unresponsive touch - is the classic signature of a blocked JS thread with an unrelated native-driven animation still running fine, because native-driven animations (via `useNativeDriver: true`, or anything Reanimated-worklet-based) execute entirely on the UI thread and don't need the JS thread at all to keep animating. Touch handling, on the other hand, ultimately needs to reach your JS event handlers (`onPress`, gesture callbacks that aren't pure worklets) - if the JS thread is busy, those handlers just queue up and never fire until it frees up.

RN's in-app Performance Monitor (shake gesture / dev menu) shows two separate FPS counters - "UI" and "JS" - specifically so you can tell these apart at a glance: UI pinned at 60 with JS dropping to single digits confirms the animation is native-driven while something else is monopolizing JS.

To find *what's* blocking JS, open the React DevTools Profiler, record while reproducing the lag, and look at the flame graph for unusually wide commits - a long, unbroken bar usually points to an expensive re-render (an unmemoized component re-rendering on every state tick, a large list re-rendering fully, or a synchronous computation like JSON.parse-ing a big payload) sitting directly in the render path. The fix is whatever that flame graph reveals - typically `React.memo`/`useMemo` on the offending subtree, moving heavy computation off the render path (or off-thread entirely via a worklet or `InteractionManager.runAfterInteractions`), not touching the animation code at all, since the animation was never the actual problem.

Question 13

A form screen using KeyboardAvoidingView with padding behavior works seamlessly on iOS, but double-pads input fields on Android. Explain the interaction between React Native's KeyboardAvoidingView and Android's native soft-input window mode (adjustResize vs adjustPan), and how to implement cross-platform keyboard handling.

Accepted Answer

On Android, the OS itself already has a mechanism for handling the keyboard covering content: the activity's `windowSoftInputMode`. With `adjustResize` (React Native's default in most templates), Android shrinks the app window's visible area when the keyboard opens, which already pushes your content up - the OS is doing the same job `KeyboardAvoidingView`'s `padding` behavior tries to do in JS. Add `KeyboardAvoidingView behavior="padding"` on top of that and you get double compensation: Android resizes the window AND RN adds extra bottom padding, so fields get pushed up further than needed. iOS has no equivalent OS-level behavior - the window never resizes for the keyboard - so `KeyboardAvoidingView` is doing necessary work there that Android's `adjustResize` already handles natively. The standard fix is to only apply the `padding` behavior on iOS, and let Android's `adjustResize` handle it alone: ```jsx ``` And confirm `android:windowSoftInputMode="adjustResize"` is set on the activity in `AndroidManifest.xml` (it's `adjustPan` by default on bare RN in some setups, which shifts the whole screen instead of resizing it, and needs different handling entirely since content isn't actually resized under it).

Question 14

A card component styled with iOS shadow offset/radius properties renders without any drop shadow on Android, while adding Android elevation creates unexpected background clipping and dark borders on transparent child views. How do you standardize cross-platform drop shadows?

Accepted Answer

`shadowColor`/`shadowOffset`/`shadowOpacity`/`shadowRadius` are pure iOS APIs under the hood (they map to CALayer shadow properties) - Android's native view system has no equivalent concept, which is why they silently do nothing there. Android instead has `elevation`, which simulates depth via Material Design's lighting model, but elevation only works correctly when the view has an opaque background - on a transparent or rounded-corner view, Android's shadow-casting algorithm clips to the view's bounding box, producing the dark border/clipping artifact you're seeing, because the shadow gets drawn using the view's rectangular silhouette rather than its visually rounded shape.

The standard cross-platform approach is a `Platform.select` that applies the right property set per platform, combined with making sure the shadowed view itself has a solid background color (not transparent) so Android's elevation renders cleanly:

```js
const cardShadow = Platform.select({
  ios: {
    shadowColor: '#000',
    shadowOffset: { width: 0, height: 2 },
    shadowOpacity: 0.15,
    shadowRadius: 4,
  },
  android: { elevation: 4 },
});

<View style={[styles.card, { backgroundColor: '#fff' }, cardShadow]} />
```

For cases needing pixel-identical shadows on both platforms (e.g. a design system that can't tolerate Material's elevation look), a library like `react-native-shadow-2` renders the shadow as an actual SVG/view layer instead of relying on either native primitive, at the cost of an extra wrapper view.

Question 15

A custom sticky bottom navigation bar is partially obscured by the Android gesture navigation bar and overlaps the Dynamic Island on iOS during landscape orientation changes. How do you properly leverage a safe-area-context library to handle dynamic window insets across orientation transitions?

Accepted Answer

The safe area isn't a fixed value - it changes with orientation (the notch/Dynamic Island moves to a side inset in landscape, not a top inset) and with system UI mode (Android's 3-button nav bar takes more space at the bottom than the gesture-only pill). Hardcoding a padding value like `paddingBottom: 34` (iOS's portrait home-indicator inset) breaks the moment the device rotates or the user has a different Android nav mode, which is exactly the bug you're seeing. `react-native-safe-area-context` fixes this by exposing insets as live, orientation-reactive values through `useSafeAreaInsets()`, wrapped by a `SafeAreaProvider` at the app root that listens for native layout/insets changes and re-renders consumers when they change: ```jsx function BottomNav() { const insets = useSafeAreaInsets(); return ( {/* nav items */} ); } ``` Including `insets.left`/`insets.right` matters specifically for your landscape case - in landscape, the notch/Dynamic Island's safe area shows up as a *side* inset, not a bottom one, so a bottom-bar that only ever pads `insets.bottom` will still get clipped by the side notch when rotated. Using `SafeAreaView` with an explicit `edges={['bottom', 'left', 'right']}` prop (rather than the default all-edges) is the equivalent shorthand when you don't need the raw inset numbers.

Question 16

Pressing the Android hardware back button when a modal bottom sheet is open inside a nested stack navigator unexpectedly exits the entire application. How do you manage hardware BackHandler event subscriptions and prioritize event consumption across nested UI layers?

Accepted Answer

Android's `BackHandler` dispatches the back-press event to registered listeners in reverse order of registration (most-recently-added first), and any listener can "consume" the event by returning `true` from its handler, which stops it from propagating further - including to React Navigation's own default back handling, and ultimately to the OS's default (exit/backgrounding) behavior. If your bottom sheet doesn't register its own listener, the back press falls straight through to whatever's next in line, and if that's the root stack navigator with nothing left to pop, it exits the app instead of just closing the sheet.

The fix is for the bottom sheet to register its own `BackHandler` listener while it's open, consume the event to close itself, and unregister on unmount so it doesn't keep intercepting back presses after it's gone:

```jsx
useEffect(() => {
  if (!isSheetOpen) return;
  const onBackPress = () => {
    closeSheet();
    return true; // consumed - stops propagation
  };
  const sub = BackHandler.addEventListener('hardwareBackPress', onBackPress);
  return () => sub.remove();
}, [isSheetOpen]);
```

Because this listener is registered *after* (and therefore takes priority over) the navigator's own listener, as long as it's only active while the sheet is genuinely open, the back press closes the sheet first and only falls through to stack-pop/app-exit behavior on a subsequent press once the sheet has already closed and unregistered its listener.

Question 17

Custom brand typography rendered in Text components displays with clipped descenders and vertical misalignment on Android, but renders cleanly on iOS. Explain how Android's font-padding behavior and baseline metrics cause this and how to normalize text rendering across platforms.

Accepted Answer

Android's text rendering system reserves extra vertical space above and below each line by default - this is `includeFontPadding`, and it's meant to guarantee room for accent marks and certain scripts' ascenders/descenders across arbitrary fonts, using metrics baked into the font file itself. Custom brand fonts often have unusual metadata for their ascent/descent/line-gap values (many are exported from design tools without properly configured vertical metrics), and Android's font-padding calculation can then either clip a descender that falls outside the font's declared metrics or add visible extra space that misaligns the text against sibling elements. iOS doesn't have this extra-padding concept at all - it renders text tightly according to Core Text's line metrics, which is why the same font looks fine there. The standard normalization is disabling Android's extra padding and being explicit about line height and vertical alignment instead of relying on either platform's default spacing: ```jsx Sample text ``` `includeFontPadding={false}` alone can still leave descenders clipped if the font's own metrics are genuinely too tight for the declared `lineHeight` - in that case the actual fix is on the asset side: re-exporting the font file with corrected vertical metrics (ascent/descent covering the full glyph set), since no amount of RN-side style tweaking can compensate for a font file that under-declares its own descender depth.

Question 18

What is React Native, and how fundamentally does it differ from writing a React web app?

Accepted Answer

React Native is a framework for building mobile apps using React's component model and JavaScript, but instead of rendering to the browser DOM, it renders to real native platform widgets - a `` becomes a `UIView` on iOS or an `android.view.View` on Android, a `` becomes a native text label, and so on. You write components, use hooks, manage state, and structure your app the same way you would in React for the web - the mental model transfers almost entirely. The difference is entirely in what sits below the component layer: there's no HTML, no CSS, no browser, and no DOM APIs. Styling uses a JS object subset of Flexbox (via `StyleSheet.create`, not CSS files), there's no `

`/``, and platform APIs (camera, GPS, push notifications) are accessed through native modules rather than Web APIs. For example, `

` on the web becomes `` in RN - conceptually identical, but a genuinely different underlying primitive, not a polyfill of the DOM one.

Question 19

What's the practical difference between React Native and Flutter, and when would you pick one over the other?

Accepted Answer

React Native renders using the platform's own native UI components (a button is a real native button), and the app logic is JavaScript/TypeScript running on Hermes or JSC. Flutter takes the opposite approach: it draws every pixel itself using its own Skia-based rendering engine, so a Flutter button isn't a native button at all - it's a shape Flutter painted to look like one, in Dart.

This has real consequences. RN apps automatically pick up platform look-and-feel changes (a new OS-level widget style) for free since they use real native views; Flutter apps look pixel-identical across OS versions because Flutter isn't using OS widgets at all, which is a strength for design consistency but means Flutter has to manually re-implement platform conventions (like iOS's exact scroll bounce physics) rather than getting them automatically.

In practice, teams already invested in a React/JS/TS codebase and web engineering culture lean RN because of direct code and skill reuse; teams that want maximum control over exact rendering across every device, or are starting fresh with no existing JS investment, often lean Flutter. Both compile to genuinely native (non-webview) apps - the "which is faster" debate is mostly settled by workload specifics, not a blanket winner.

Question 20

Explain the component lifecycle in a functional React Native component and how `useEffect` replaces the old class lifecycle methods.

Accepted Answer

Class components had explicit lifecycle methods - `componentDidMount` (runs once after first render), `componentDidUpdate` (runs after every re-render), and `componentWillUnmount` (runs on removal) - each a separate method you had to remember to keep in sync with each other (e.g. subscribing in `componentDidMount` and forgetting to unsubscribe in `componentWillUnmount` was a classic leak). Functional components use `useEffect` to unify all three into one construct built around a dependency array.

An effect with `[]` runs once, right after the first render - equivalent to `componentDidMount`. An effect with dependencies (`[userId]`) re-runs whenever any of those values change between renders - covering the `componentDidUpdate` case, but scoped precisely to the values that matter instead of running on every update. The function an effect *returns* is its cleanup, called before the effect re-runs and on unmount - covering `componentWillUnmount`.

```jsx
useEffect(() => {
  const sub = api.subscribeToUser(userId, setUser);
  return () => sub.unsubscribe(); // cleanup: old effect's teardown + final unmount
}, [userId]);
```

This single hook replacing three separate lifecycle methods is why bugs like "subscribed to the old userId after a prop changed" became much rarer - the dependency array forces you to declare what the effect actually depends on, and the cleanup always pairs with the specific effect run it belongs to.

Question 21

What's the difference between FlatList and ScrollView, and when should you never use ScrollView for a data list?

Accepted Answer

`ScrollView` renders all of its children up front, all at once, regardless of whether they're currently visible on screen. For a handful of items that's fine, but for a list of, say, 500 user records, `ScrollView` mounts all 500 rows' components and native views immediately - which is slow to render initially and consumes memory proportional to the full dataset, whether or not the user ever scrolls that far. `FlatList` only renders the items currently visible plus a small buffer window (`windowSize`), and unmounts rows that scroll far enough off-screen, using `virtualization` to keep both render time and memory roughly constant regardless of list length. It requires a `keyExtractor` and `renderItem` rather than JSX children, which is the trade-off for that efficiency. ```jsx item.id} renderItem={({ item }) => } /> ``` The rule of thumb: use `ScrollView` for a small, fixed, known-bounded set of content (a settings screen with a dozen static sections); use `FlatList` (or `FlashList` for even better recycling performance) for anything that's a genuine "list of data" whose length could realistically grow - feeds, search results, chat messages, contact lists.

Question 22

How do you set up navigation in a React Native app with React Navigation, and what's the difference between a stack, tab, and drawer navigator?

Accepted Answer

React Navigation models navigation as a tree of "navigators," each managing a different UI pattern for moving between screens, and you compose them by nesting one inside another. A stack navigator pushes new screens on top of a history stack (like browser history) with back navigation popping the top screen off - the natural fit for drill-down flows like a list screen leading to a detail screen. A tab navigator shows a persistent bottom (or top) bar with a fixed set of top-level destinations, where switching tabs doesn't push/pop history the same way. A drawer navigator hides its options behind a slide-out side panel, typically used for less-frequent top-level destinations. ```jsx function App() { return ( ); } function HomeStack() { return ( ); } ``` A very common real app shape, as above, nests a stack navigator inside each tab - so tapping into a post from the Home tab pushes onto that tab's own stack, and switching to the Profile tab doesn't lose your place in the Home tab's stack.

Question 23

What's the difference between using Expo and the bare React Native CLI, and how do you decide which to start a new project with?

Accepted Answer

Expo is a toolchain and set of managed services built on top of React Native: it provides a curated set of pre-built native modules (camera, notifications, file system, etc.) that work without writing any native code yourself, a build service (EAS Build) that compiles your app in the cloud so you don't need Xcode/Android Studio installed locally to produce a build, and a dev client (Expo Go, or a custom dev client) for fast iteration. The bare React Native CLI gives you the raw framework with an `ios/` and `android/` folder you own directly, and you add exactly the native modules and build tooling you choose.

The practical trade-off: Expo gets you to a working app faster and handles a lot of native-build complexity for you, but you're constrained to what Expo's SDK (or a compatible "config plugin") supports unless you eject to bare workflow or use a custom dev client. Bare RN gives full control - any native SDK, any native code you want to write - at the cost of managing native project files, native dependency conflicts, and Xcode/Gradle build issues yourself.

Modern Expo ("Expo with Dev Client"/EAS) has narrowed this gap a lot - you can add arbitrary native modules via config plugins without fully ejecting - so for a new project in 2026, starting with Expo is the more common default, and dropping to bare (or using Expo's "prebuild" to generate the native folders) is reserved for apps that need something Expo's plugin ecosystem genuinely can't cover.

Question 24

How does StyleSheet.create work in React Native, and why is it preferred over passing plain inline style objects?

Accepted Answer

`StyleSheet.create({...})` takes an object of style definitions and returns an object where each key maps to either the same style object back, or (historically, and still on the old architecture) an integer ID that React Native's native side can look up instead of re-serializing the whole style object on every render. The point isn't magic optimization so much as encouraging a pattern: styles get defined once, outside the render function, instead of being recreated as new object literals on every single render. ```jsx const styles = StyleSheet.create({ card: { padding: 16, borderRadius: 8, backgroundColor: '#fff' }, }); ``` Compare that to `` written inline in JSX - that object literal is a brand-new object reference on every render, which defeats reference-equality checks (`React.memo`, `shouldComponentUpdate`) that would otherwise let a child bail out of re-rendering when nothing actually changed. `StyleSheet.create` also gives you compile-time validation of style properties in TypeScript/Flow and a slightly better dev experience (named style errors point back to the sheet), which plain object literals scattered through JSX don't.

Question 25

What's the default flex direction in React Native, and how does that differ from CSS Flexbox on the web?

Accepted Answer

React Native's default `flexDirection` is `column` - children stack vertically by default. Standard CSS Flexbox on the web defaults to `row` - children lay out horizontally by default, unless you explicitly set `flex-direction: column`. This is a genuinely common source of confusion for developers coming from web CSS, because a layout that "just works" as a row on the web silently becomes a vertical stack in RN unless you add `flexDirection: 'row'` explicitly. ```jsx // Renders as a vertical stack in RN by default - would be horizontal in web CSS One Two // Explicit row, to match what CSS's default would give you One Two ``` This default difference exists because RN's layout engine, Yoga, was designed to match the ergonomics of typical mobile screen layouts (which are usually vertically stacked lists/sections) rather than mirroring the web's flexbox spec exactly - it implements the Flexbox algorithm itself faithfully, just with a different chosen default for this one property.

Question 26

How do you make an API call in React Native and properly handle loading and error states?

Accepted Answer

React Native ships the standard `fetch` API (and `XMLHttpRequest` underneath it) as a global, so you don't need a special RN-specific networking library just to hit an HTTP endpoint - though many apps add `axios` for its interceptors and simpler error shape. The important part for real apps isn't the fetch call itself, it's tracking three distinct UI states explicitly: loading, error, and success/data - and making sure every code path actually reaches one of them.

```jsx
function useUser(userId) {
  const [state, setState] = useState({ status: 'loading', data: null, error: null });

useEffect(() => {
    let cancelled = false;
    setState({ status: 'loading', data: null, error: null });
    fetch(`https://api.example.com/users/${userId}`)
      .then((res) => {
        if (!res.ok) throw new Error(`HTTP ${res.status}`);
        return res.json();
      })
      .then((data) => !cancelled && setState({ status: 'success', data, error: null }))
      .catch((error) => !cancelled && setState({ status: 'error', data: null, error }));
    return () => { cancelled = true; };
  }, [userId]);

return state;
}
```

The `cancelled` flag matters specifically on mobile: users navigate away from screens quickly, and without it, a slow response arriving after the component unmounted would call `setState` on a component that no longer exists - not a crash in modern React, but a wasted state update and a common source of "why did stale data flash briefly" bugs when a fast re-navigation races an in-flight request.

Question 27

What is AsyncStorage, and what are its practical limitations that push larger apps toward alternatives like MMKV or SQLite?

Accepted Answer

`AsyncStorage` is React Native's simplest persistent key-value store - a Promise-based API for storing strings against string keys, backed by SQLite on Android and a flat file (or `NSUserDefaults`-adjacent mechanism, depending on version) on iOS. It's fine for small amounts of data: a theme preference, an auth token, a "has seen onboarding" flag.

It starts to hurt at scale for a few concrete reasons: every operation is async, which forces a Promise/await dance even for tiny reads (contributing to startup-flicker issues, since you can't read it synchronously before first render); there's no built-in querying - you can only get/set whole values by exact key, so anything list-like requires you to serialize/deserialize a JSON blob yourself and re-write the whole blob on any change; and its underlying storage isn't optimized for high write frequency, so apps hammering it (e.g. persisting state on every keystroke) can see real performance drops as the stored data grows.

MMKV solves the sync-read and raw-throughput problems (it's a native, JSI-backed key-value store, genuinely synchronous, benchmarked meaningfully faster than AsyncStorage for both reads and writes) but is still key-value, not queryable. For anything relational or requiring real queries/joins/indexes (offline-first apps with complex data models), a real embedded database like WatermelonDB or OP-SQLite is the appropriate next step up, not a bigger AsyncStorage blob.

Question 28

How do you implement push notifications in a React Native app, and what's the difference between local and remote notifications?

Accepted Answer

A local notification is scheduled and fired entirely on-device - no server or network involved, e.g. a reminder set for "2 hours from now" using `notifee` or `expo-notifications`'s local scheduling API. A remote (push) notification originates from a server, which sends a payload to Apple's APNs or Google's FCM, which in turn delivers it to the specific device - this is what you need for things like "a new message arrived" that the server, not the device, knows about first.

Setting up remote push requires wiring three layers: the app requests notification permission and registers with the platform's push service to get a device token (`messaging().getToken()` with `@react-native-firebase/messaging`, for example); your backend stores that token against the user and calls FCM's (or APNs directly) send API with the token and payload when it wants to notify them; and the app handles the incoming notification differently depending on app state - foreground (you typically show your own in-app banner, since the OS won't auto-display a system notification while the app is open), background (the OS shows the system notification tray entry automatically), and killed (a background handler, e.g. `messaging().setBackgroundMessageHandler`, still needs to run to process data-only payloads even with the app not running).

```js
import messaging from '@react-native-firebase/messaging';

async function registerForPush() {
  const authStatus = await messaging().requestPermission();
  if (authStatus === messaging.AuthorizationStatus.AUTHORIZED) {
    const token = await messaging().getToken();
    await api.saveDeviceToken(token); // send to your backend
  }
}
```

iOS requires an additional APNs certificate/key configured in your Apple Developer account and linked to your Firebase project (if using FCM) before remote push will actually deliver - a step that trips up a lot of first-time setups because the local notification permission prompt can succeed while remote delivery still silently fails without it.

Question 29

What's the difference between a controlled and uncontrolled TextInput in React Native?

Accepted Answer

A controlled `TextInput` has its `value` driven entirely by React state - you pass `value={text}` and update that state in `onChangeText`, so React is the single source of truth for what's displayed, and the input can never show something your state doesn't know about. An uncontrolled input has no `value` prop at all (or uses `defaultValue` only for the initial value) - the native text field manages its own internal text state, and you only find out what's in it when you explicitly read it (via a ref, or on submit). ```jsx // Controlled const [text, setText] = useState(''); // Uncontrolled const inputRef = useRef(null); // later: inputRef.current.setNativeProps({ text: '...' }) or read via a submit handler ``` Controlled is the far more common pattern in RN because it lets you do live validation, formatting-as-you-type, or character limits directly off state - but it comes with a real performance cost on every keystroke re-rendering the component tree above the input, which matters for something like a chat app with a complex message-composer UI where uncontrolled (or a debounced controlled pattern) can genuinely help.

Question 30

What tools do you use to debug a React Native app, and how does remote JS debugging differ from using Flipper or the new React DevTools?

Accepted Answer

"Remote JS debugging" (the old Chrome DevTools-based approach, `Debug JS Remotely`) actually runs your app's JavaScript inside Chrome's V8 engine on your desktop, not inside Hermes/JSC on the device, and proxies results back - which is powerful for stepping through code and setting breakpoints, but means what you're debugging isn't really running on the same JS engine as production, and it noticeably slows the app down (every JS execution round-trips to the desktop). This approach has been effectively deprecated/removed in newer RN versions in favor of tools that inspect the actual on-device runtime.

Flipper (RN's official desktop debugging platform for a long time) connects to the running app over a socket and gives you a real native + JS combined view: network request inspection, a layout inspector for the native view hierarchy, and plugins for things like AsyncStorage/MMKV contents, all against the app actually running on-device or in a simulator - not a proxied V8 environment.

The newer built-in React Native DevTools (bundled since RN 0.73+, launched via the dev menu) connects directly to Hermes's own debugger protocol, giving you real breakpoints, the Components tree, and the Profiler flame graph against the actual Hermes runtime the app ships with - which is generally the recommended default now, since it debugs the real engine instead of a substitute one, and doesn't require standing up a separate Flipper desktop app and plugin ecosystem.

Question 31

What is CodePush (or a similar OTA update service), and what categories of changes can and can't be shipped this way without going through app store review?

Accepted Answer

CodePush-style over-the-air (OTA) updates let you push a new JS bundle (plus any static JS-side assets) directly to installed apps, bypassing the App Store/Play Store review cycle entirely - the app checks in with the OTA server on launch (or periodically), downloads a new bundle if one's available, and swaps it in, either immediately or on next restart. This is genuinely useful for shipping a bug fix or copy change within minutes instead of waiting days for store review.

The hard boundary is: OTA can only update JavaScript and JS-bundled assets (images, fonts referenced from JS). It cannot ship any change to native code - a new native module, an updated native SDK version, a change to `Info.plist`/`AndroidManifest.xml`, or a React Native version bump itself, since all of that lives in the compiled native binary that the store already approved and that OTA has no mechanism to replace. Apple's App Store guidelines also explicitly prohibit using OTA updates to change the app's fundamental purpose/functionality in ways not reviewed - a legitimate bug-fix/content update is fine, but using OTA to silently swap in entirely different app behavior post-review is a policy violation that can get an app pulled.

In practice, teams use OTA for genuine emergency fixes and minor UI/logic tweaks, while anything touching a native dependency, permission, or app capability still has to go through a real app store release with its normal review timeline.

Question 32

What are the main techniques for optimizing React Native app startup (cold start) time?

Accepted Answer

Startup time breaks down into a few measurable phases, and each has its own lever. Native app launch (before any JS runs at all) is affected by how much native initialization code runs eagerly - lazy-initializing SDKs (analytics, crash reporting) instead of doing it in `application:didFinishLaunching`/`Application.onCreate` defers work off the critical path. JS bundle load/parse time is reduced by using Hermes (ships precompiled bytecode instead of parsing source at runtime) and by enabling `inlineRequires` in Metro so modules only execute when actually used rather than all at once during the initial `require` graph walk.

Actual React render time to first meaningful paint benefits from deferring non-critical work: wrapping expensive but non-visual initialization (analytics setup, background data prefetch) in `InteractionManager.runAfterInteractions` so it runs after the first frame is already painted and interactive, rather than blocking it. Reducing what's imported at the top level of your entry file matters too - importing a big library (e.g. a full charting library) at the app's root `App.js` forces it to load before the first screen can render, even if that library is only used on a screen three navigations deep.

Measuring, not guessing, is important here: the RN Performance Monitor and native profiling tools (Xcode Instruments' Time Profiler, Android Studio Profiler) show you where time is actually going, and "enable Hermes + inlineRequires + lazy-init non-critical native SDKs" covers the majority of real-world cold-start wins before you need anything more exotic.

Question 33

What's the difference between the legacy Animated API and Reanimated, and why would you choose one over the other?

Accepted Answer

The legacy `Animated` API (built into core React Native) lets you declare animations in JS that, with `useNativeDriver: true`, get serialized once and handed off to the native side to actually run frame-by-frame - so the animation itself doesn't need the JS thread ticking every frame, only its *setup*. The catch is `useNativeDriver` only supports a limited set of properties (mostly transforms and opacity) because those are the ones that can be expressed as a static declarative animation the native driver can run without asking JS anything mid-flight - you can't native-drive something like animating `height` or `backgroundColor` this way (well, `backgroundColor` actually can with native driver on newer RN, but layout properties like `width`/`height`/`flex` still can't, since they require Yoga to re-run layout, which is JS-thread-adjacent work).

Reanimated takes a fundamentally different approach: your animation *logic itself* (not just its declaration) runs on the UI thread, as compiled "worklets" - meaning you can write genuinely dynamic, interactive, gesture-driven animation code (read a shared value, branch on it, combine multiple values) and have all of that execute at 60-120fps on the UI thread, not just play back a pre-declared timeline.

```jsx
// Legacy Animated - can only native-drive a fixed transform/opacity animation
Animated.timing(fadeAnim, { toValue: 1, duration: 300, useNativeDriver: true }).start();

// Reanimated - worklet runs actual logic on the UI thread
const opacity = useSharedValue(0);
const style = useAnimatedStyle(() => ({ opacity: withTiming(opacity.value) }));
```

In practice: simple fade/scale/slide transitions are fine with legacy `Animated`; anything gesture-driven, interruptible, or involving real per-frame logic (drag-to-dismiss, a physics-based swipe, chained interdependent animations) is what Reanimated exists for.

Question 34

How do you implement deep linking and universal links in a React Native app so that tapping a link opens the app directly to specific content?

Accepted Answer

There are two related but distinct mechanisms, both needed for a complete setup. A custom URL scheme (`myapp://product/123`) is the simpler one - any app can register a scheme in `Info.plist`/`AndroidManifest.xml`, and tapping such a link opens the app if installed, but the browser has no way to fall back gracefully if it isn't (it just fails silently or shows an error). Universal Links (iOS) / App Links (Android) use regular `https://` URLs instead, verified via a domain-hosted file (`apple-app-site-association` for iOS, `assetlinks.json` for Android) that proves you own the domain - so the same `https://myapp.com/product/123` link opens the app if installed, and falls back to the actual website if not, which is the better user experience and what most production apps use. On the RN side, both funnel through the same `linking` config passed to `NavigationContainer`, mapping URL paths to screens: ```js const linking = { prefixes: ['myapp://', 'https://myapp.com'], config: { screens: { ProductDetail: 'product/:id' } }, }; ... ``` The part that trips people up isn't the RN config, it's the platform-side domain verification: the `apple-app-site-association` file has to be served over HTTPS with no redirects and the correct content-type, and the app's associated domains entitlement has to list the exact domain - a misconfigured one silently falls back to opening the link in the browser instead of the app, with no error thrown anywhere in your RN code to hint why.

Question 35

What tools and libraries are commonly used for testing a React Native app, and what does each layer of the testing pyramid cover?

Accepted Answer

At the unit/logic level, Jest (RN's default test runner, preconfigured in every RN CLI/Expo project) tests pure functions, hooks, and reducers in isolation - fast, no device or simulator needed. One layer up, React Native Testing Library renders components in a simulated environment and lets you assert on what a user would actually see/interact with (`getByText`, `fireEvent.press`) rather than testing internal implementation details like component state directly - this is the layer that catches "does this component render the right thing given these props" bugs.

```jsx
test('shows error message on invalid email', () => {
  const { getByPlaceholderText, getByText } = render(<LoginForm />);
  fireEvent.changeText(getByPlaceholderText('Email'), 'not-an-email');
  fireEvent.press(getByText('Submit'));
  expect(getByText('Please enter a valid email')).toBeTruthy();
});
```

At the top of the pyramid, Detox (or Maestro, increasingly popular for its simpler YAML-based flows) runs true end-to-end tests against a real compiled app on a simulator/emulator or physical device - tapping through actual screens, verifying real navigation, real native module behavior, catching things unit/component tests structurally can't (a broken native build, a permission dialog blocking a flow). E2E tests are the slowest and most brittle layer, so the practical guidance is the usual pyramid shape: many fast Jest unit tests, a solid layer of component tests, and a smaller number of E2E tests covering only the most critical user flows (login, checkout, core feature happy path).

Question 36

Explain the Yoga layout engine's role in React Native, and why it's necessary rather than just using the platform's native layout system directly.

Accepted Answer

Yoga is a standalone, cross-platform C++ implementation of the Flexbox layout algorithm that React Native embeds on both iOS and Android. Neither platform's native layout system speaks Flexbox natively - iOS's Auto Layout uses constraints, and Android's traditional layout system uses XML-based layout params (LinearLayout weights, RelativeLayout rules) - so without Yoga, RN would either have to pick one platform's layout paradigm and awkwardly translate it to the other, or make you write layout twice.

Instead, Yoga computes layout once, in platform-agnostic C++, from the exact same Flexbox style props (`flex`, `justifyContent`, `alignItems`, etc.) regardless of which OS is running - it produces a tree of final `{x, y, width, height}` rectangles, and each platform's native renderer just places its actual views at those computed positions. This is precisely why RN's Flexbox behaves identically across iOS and Android for a given style, even though neither platform has Flexbox as a native concept at all - the consistency comes from Yoga being the single source of truth for the math, not from either OS's layout system.

A subtlety worth knowing: Yoga is a close-but-not-100%-identical implementation of the CSS Flexbox spec - a handful of edge cases and defaults differ (like the `flexDirection: column` default already covered elsewhere), which is a small but real reason "looks right in a web Flexbox playground" doesn't always translate exactly to RN without adjustment.

Question 37

Before the New Architecture, React Native ran on three (or more) separate threads. Name them and explain what would happen if a heavy synchronous computation ran on each one.

Accepted Answer

The legacy architecture's threading model has, at minimum: the JS thread (runs your JS/Hermes VM - all your component logic, state updates, and event handlers), the Shadow/layout thread (computes Yoga layout off the main thread so layout math doesn't block rendering), the main/UI thread (the platform's actual UI thread - where native views are created, updated, and drawn to screen, same as any native iOS/Android app's main thread), and a pool of native module threads for native module method execution that don't specify their own queue.

A heavy synchronous computation on the JS thread (say, sorting a 50,000-item array inline in a render) blocks every pending state update, every touch handler, and every bridge message coming from native - the whole JS side of the app freezes, though native-driven animations already in flight keep running since they don't need JS. The same heavy work accidentally run on the main/UI thread (e.g. a native module doing disk I/O synchronously without dispatching off-thread) blocks actual screen rendering and touch delivery at the OS level - this is what produces the platform's own "app not responding"/frozen-UI symptoms, distinct from a frozen JS thread, because the UI thread is what iOS/Android use to detect an unresponsive app.

This is exactly the practical reason RN pushes you toward `InteractionManager.runAfterInteractions` for JS-thread-heavy work and toward background dispatch queues for native-module work that touches disk/network - each thread has a specific job, and blocking any one of them produces a different, identifiable class of user-visible freeze.

Question 38

What is "Bridgeless mode" in React Native's New Architecture, and how does it change the app's startup sequence compared to the legacy bridge?

Accepted Answer

Bridgeless mode is the New Architecture's default runtime mode (as of RN 0.74+) where the legacy async bridge object is never instantiated at all - not "faster," but structurally absent. Under the old architecture, even a TurboModules-enabled app still had a bridge object created at startup for backward compatibility and for anything not yet migrated to JSI; Bridgeless removes that object entirely, so every native interaction genuinely has to go through JSI (TurboModules for methods, Fabric for UI) with no legacy fallback path available.

This changes the startup sequence concretely: instead of the bridge eagerly setting up its message queue and (in older RN versions) eagerly instantiating every registered native module at boot, Bridgeless mode's `ReactInstance` sets up the JS runtime and hands it direct JSI bindings, with TurboModules lazily created only on first access - which is part of why Bridgeless apps show measurably faster startup than even TurboModules-on-legacy-bridge apps, since there's no bridge object initialization overhead at all, not just less of it.

The practical implication for library authors and app developers is that any native module still written against the old bridge-only APIs (`RCTBridgeModule` without a TurboModule spec) either needs the Interop Layer to keep functioning, or a genuine migration to a TurboModule/Fabric component - Bridgeless mode is the point where "my library still uses the old native module pattern" stops being a performance footnote and starts being a hard compatibility requirement.

Question 39

What is autolinking in React Native, and how does react-native.config.js let you customize or opt a specific native dependency out of it?

Accepted Answer

Before autolinking (pre-0.60), adding a native module meant manually editing native project files - dragging a `.xcodeproj` reference into your iOS project, editing `settings.gradle` and `MainApplication.java` on Android - for every single native dependency, which was tedious and a common source of "forgot a step" build errors. Autolinking automates this: the RN CLI scans your `package.json` dependencies for packages that declare native code (via a `react-native.config.js` in the library itself, or convention-based detection), and generates the native linking code automatically as part of the build (a generated `PackageList.java` on Android, a CocoaPods podspec resolution on iOS) - you just `npm/pnpm install` the package and it's linked.

Sometimes you need to override this - a monorepo where a native module lives in a workspace package with a nonstandard path, a library you want to exclude from autolinking because you're linking a forked/patched version manually, or a platform you want to skip linking on entirely. `react-native.config.js` at your project root is where you declare those exceptions:

```js
module.exports = {
  dependencies: {
    'some-native-lib': {
      platforms: { android: null }, // skip autolinking this lib on Android
    },
  },
};
```

Setting a platform to `null` here tells the CLI to skip autolinking that dependency for that platform entirely, which is the standard escape hatch when a native module needs custom manual integration instead of the default automatic one.

Question 40

What's the difference between RCTEventEmitter and NativeEventEmitter on iOS, and why does React Native have two separate event-emitting mechanisms?

Accepted Answer

`RCTEventEmitter` is the base class native modules subclass to *send* events into the JS side of the bridge - it's the native-side sender, providing methods like `sendEventWithName:body:` that a module calls when something happens natively (a Bluetooth reading arrives, a location update fires) that JS needs to know about. `NativeEventEmitter` is the JS-side counterpart - the class your JavaScript code instantiates (wrapping a specific native module) to *subscribe* to those events with `.addListener()`, as covered in the BLE listener-leak question above.

They're separate because they live on opposite sides of the native/JS boundary and serve genuinely different roles: `RCTEventEmitter` is Objective-C/Swift code that a native module author extends to define what events exist and when they fire; `NativeEventEmitter` is JavaScript code any consumer of that module uses to react to them. A native module subclassing `RCTEventEmitter` must also implement `supportedEvents` (declaring which event names it can emit) and `startObserving`/`stopObserving` (called automatically when the first JS listener attaches / the last one detaches) - which is exactly the hook point for starting/stopping an expensive native observer (like a BLE scan) only while something on the JS side actually cares about its output, rather than running it for the module's entire lifetime.

Question 41

What are "Static View Configs" in the Fabric renderer, and how do they reduce the native/JS coordination cost at app startup compared to the legacy UIManager?

Accepted Answer

Under the legacy architecture's `UIManager`, each native component's view configuration (its supported props, their types, default values, and event names) was computed and shipped across the bridge at runtime, as part of app initialization - the native side would send its full component registry over as a serialized bridge message, and JS had to receive and process it before it could render any native views, adding real, measurable startup latency proportional to how many native component types your app registers (which grows with every third-party UI library you add).

Static View Configs, part of the Fabric/New Architecture Codegen pipeline, move this from a runtime bridge exchange to a build-time artifact: because Codegen already generates the component's prop/event schema from its TypeScript spec at build time (see the earlier TurboModules Codegen example), that same schema can be baked into the native binary as a static, compile-time-known config rather than something computed and transmitted at every app launch. JS reads the same static schema locally, generated from the identical spec, with no cross-thread message needed to learn what props a native component accepts.

The net effect is startup cost for view config resolution goes from "proportional to the number of registered native components, paid every app launch via a bridge round trip" to "effectively zero at runtime, since it's already compiled in" - a genuinely structural improvement, not just a faster version of the same mechanism, which is part of why apps with many third-party native UI libraries see a disproportionately large startup improvement moving to Fabric.

Question 42

How does the Codegen tool in React Native's New Architecture generate type-safe native interfaces from a JS/TypeScript spec file, and what problem does this solve compared to the old NativeModules pattern?

Accepted Answer

Under the legacy `NativeModules` pattern, a JS call like `NativeModules.MyModule.doThing(arg)` had no compile-time connection to the actual native implementation at all - the native method's name, argument types, and return shape were just conventions both sides had to independently get right, and a mismatch (native expects a number, JS sends a string) wasn't caught until runtime, often manifesting as a crash or a silently wrong value deep in native code, far from the JS call site that actually caused it. Codegen fixes this by making the TypeScript (or Flow) spec file the single source of truth, parsed at build time to generate matching native interface code in each platform's language: ```ts // NativeMyModule.ts import type { TurboModule } from 'react-native'; import { TurboModuleRegistry } from 'react-native'; export interface Spec extends TurboModule { doThing(arg: string): Promise; } export default TurboModuleRegistry.getEnforcing('MyModule'); ``` From this one file, Codegen generates a C++ abstract base class (and matching Objective-C++/Java/Kotlin protocol/interface) that your actual native implementation must conform to - so if the native side implements `doThing` with the wrong argument type or forgets to implement it at all, that's now a *build-time* compile error on the native side, not a runtime surprise. This is the core value: the contract between JS and native is enforced by the compiler on both sides, generated from one spec, instead of trusted by convention across two independently-written implementations.

Question 43

What is the Interop Layer in React Native's New Architecture, and when would you actually need it?

Accepted Answer

The Interop Layer is a compatibility shim that lets native modules and native UI components written against the *old* architecture's APIs (`RCTBridgeModule`, legacy `ViewManager` without a Fabric component descriptor) keep functioning when the app has otherwise adopted Fabric/TurboModules - it translates calls between the new Fabric/TurboModule system and the old-style native code, so you don't need every single third-party native dependency to have already migrated before you can turn on the New Architecture.

You need it, in practice, whenever your app has at least one native dependency that hasn't yet shipped a New Architecture-compatible version - which, during the ecosystem's migration period, was extremely common; a lot of real apps enabled the New Architecture with the Interop Layer quietly bridging one or two not-yet-migrated libraries while everything else ran on genuine Fabric/TurboModules directly.

The trade-off is that anything running through the Interop Layer doesn't get the New Architecture's performance benefits for that specific component/module - it's still doing the old-style bridge-shaped communication under a compatibility wrapper, just coexisting inside an otherwise New Architecture app. It's a migration bridge (pun intended) meant to be temporary per-dependency: the real fix, long-term, is the library itself shipping a proper Fabric component / TurboModule spec, at which point that specific dependency no longer needs the Interop Layer at all.

Question 44

Explain React Native's gesture responder system - how do onStartShouldSetResponder and onMoveShouldSetResponder negotiate which of several nested touchable views actually handles a touch?

Accepted Answer

When a touch happens on screen, React Native doesn't just deliver it to whatever view is at the top of the visual stack - it runs a negotiation process up the view hierarchy asking each view (from the touched leaf up toward the root, roughly) whether it wants to "become the responder" for this touch sequence. `onStartShouldSetResponder` is called on touch-down for each view in that chain, and any view returning `true` is a candidate; `onMoveShouldSetResponder` asks the same question again as the finger moves, which is how a view that didn't claim the touch on press (a scroll view, say) can still claim it partway through if the movement pattern looks like a scroll rather than a tap.

Only one view ultimately "wins" and becomes the active responder for that gesture, receiving `onResponderMove`/`onResponderRelease` for its duration - this is exactly the mechanism behind classic conflicts like "a button inside a horizontally-scrolling carousel sometimes doesn't register a tap, and sometimes eats the scroll gesture instead," because both the button and the ScrollView are legitimately competing for the same touch, and which one wins depends on this negotiation's specific timing and thresholds.

`react-native-gesture-handler` exists largely because this negotiation, done manually via the raw responder system, is genuinely hard to get right for anything beyond simple cases - it replaces this ad hoc per-touch negotiation with an explicit, declarative gesture composition API (`Gesture.Race`, `Gesture.Simultaneous`, `.requireExternalGestureToFail()`) where you state the priority/relationship between competing gestures directly, instead of relying on the responder system's implicit resolution order.

Question 45

What's the difference between Pressable and the older TouchableOpacity/TouchableHighlight, and why is Pressable now the recommended default?

Accepted Answer

`TouchableOpacity` and `TouchableHighlight` are older, single-purpose components: each hardcodes one specific visual feedback style (fading opacity, or a highlight-color flash) as its entire API surface - if you wanted a custom pressed-state visual (a scale animation, a different background color, a ripple), you had to work around the component's built-in behavior rather than configure it. `Pressable` instead exposes the raw press-state lifecycle (`onPressIn`, `onPressOut`, `onPress`, `onLongPress`) and lets you render whatever visual feedback you want, including a function-as-style pattern that receives the current pressed state directly: ```jsx [styles.button, pressed && styles.buttonPressed]} > Submit ``` Beyond styling flexibility, `Pressable` also exposes finer-grained gesture-adjacent config the older Touchables didn't - `hitSlop` for expanding the tappable area beyond the visual bounds, `pressRetentionOffset`, and `delayLongPress` - and it's built on the newer Pressability internals that the RN team has continued to invest in, while the older Touchable components are effectively in maintenance mode. This is why current RN documentation and most component libraries default to `Pressable` for new code, reserving `TouchableOpacity` mainly for existing code that already relies on its specific default fade behavior.

Question 46

Why can excessive console.log calls measurably degrade performance in a React Native app, and where does that cost actually come from?

Accepted Answer

On the legacy architecture, every `console.log` call in JS isn't free even though it looks like a no-op debug statement - RN's console methods are patched to also forward the log message across the bridge to native (so it shows up in Xcode's console / Logcat / Metro's terminal output), which means each call goes through the same serialize-and-queue mechanism as any other bridge message. A tight loop or a per-frame log statement (logging every scroll event's offset, for instance) can genuinely flood the bridge with messages fast enough to compete with real app messages for bridge bandwidth and add up to visible frame drops - not because `console.log` itself is slow in isolation, but because of what it triggers on every call.

Remote JS debugging (running JS in Chrome via the old debug-remotely flow) makes this dramatically worse, because every log call round-trips to the desktop browser's console over a WebSocket rather than a same-device bridge hop - which is part of why apps that felt totally smooth normally would stutter badly specifically while remote debugging was enabled, confusing people into thinking their app had a real perf bug that was actually an artifact of the debugging connection itself.

On the New Architecture with JSI, this specific mechanism changes shape (JSI calls are direct, not bridge-serialized), but the broader principle still holds in production builds - logging in hot paths (render functions, per-frame callbacks, list item renders) is still wasted work that should be stripped or gated behind a dev-only flag (`if (__DEV__)`), both for the direct cost and because most bundlers/minifiers won't strip `console.log` calls automatically unless explicitly configured to.

Question 47

How does Hermes bytecode precompilation interact with Metro's bundling pipeline, and at what point in the build does JS source actually become Hermes bytecode?

Accepted Answer

Metro's job is bundling and transforming - it resolves your module graph, applies Babel transforms (JSX to `React.createElement` calls, TypeScript stripping, etc.), and produces a single JS bundle file, exactly as it did before Hermes existed. Hermes compilation is a separate, subsequent step: after Metro produces that final JS bundle, the Hermes compiler (`hermesc`) takes that bundle as input and compiles it to Hermes bytecode (`.hbc`), which is what actually gets embedded into the app binary - on Android this happens automatically as part of the Gradle build (`bundleReleaseJsAndAssets` task chain invoking `hermesc` on Metro's output), and on iOS as a build phase script in the Xcode project.

This two-step separation matters for a few practical reasons: source maps have to account for *two* transformation steps (JS source → Metro's bundled/transformed output → Hermes bytecode), which is why Hermes-enabled crash reporting setups (Sentry, Bugsnag) need to upload and correctly chain both the Metro source map and a Hermes-specific source map to get a real stack trace back to your original source lines - getting only one of these right still leaves you looking at unreadable bytecode offsets in a crash report.

It also means Hermes compilation is a release/build-time-only step during normal development - in dev mode with Metro's dev server, JS is typically served as source (or dev-mode bytecode) directly to the Hermes runtime running on-device, and the full AOT precompilation pipeline is really a release-build optimization, not something you're paying for on every Fast Refresh during development.

Question 48

React Native doesn't have a real browser DOM. How does its reconciliation process map React's virtual tree onto actual native views, and what role does the Shadow Tree play in that?

Accepted Answer

In React DOM, reconciliation ultimately produces DOM mutations - `appendChild`, `setAttribute`, and so on, against a tree the browser already understands natively. React Native has no such native tree to mutate directly in that sense; instead, React's reconciler (the same Fiber algorithm used for web) produces a tree of RN-specific "host component" instances (`View`, `Text`, `Image` etc.), and that tree gets mirrored into a separate C++ structure called the Shadow Tree, which is what actually gets measured and laid out (via Yoga) off the main thread.

Once Yoga computes final positions/sizes for every node in the Shadow Tree, Fabric "commits" that computed layout by generating a minimal list of mutations (create this view, update that view's props, move this one) and applies them to the real native view hierarchy on the main/UI thread - conceptually parallel to how React DOM diffs and patches the real DOM, just with an extra layout-computation stage in between because native views don't have CSS's layout engine built in the way a browser does.

The practical benefit of this three-tree design (React Fiber tree → Shadow Tree → actual native views) is that expensive work - reconciliation and layout computation - happens off the main thread entirely, and only the final, minimal set of real native view mutations touches the main thread, which is what keeps native rendering smooth even when a lot of React-level re-rendering and layout recalculation is happening underneath.

Question 49

A useEffect subscribes to a timer or event listener but the component can unmount while it's still pending, causing a "can't perform a state update on an unmounted component" warning or a memory leak. How do you fix this correctly with hooks?

Accepted Answer

The bug happens because the callback passed to `setInterval`, an event listener, or a pending network request holds a closure over `setState`, and nothing tells that callback the component it belongs to no longer exists - so when it eventually fires, it happily calls `setState` on a component React has already torn down, which is either a wasted no-op warning or, worse, a real leak if the underlying subscription/timer itself is never cleared and keeps running indefinitely in the background.

The fix is always the same shape: whatever `useEffect` sets up, its cleanup function (the value it returns) has to tear back down - clear the interval, remove the listener, or set a `cancelled`/`isMounted`-style guard flag before calling `setState` from an async callback that might resolve after unmount.

```jsx
useEffect(() => {
  const id = setInterval(() => setTick((t) => t + 1), 1000);
  return () => clearInterval(id); // stops the timer, prevents the leaked callback entirely
}, []);
```

For a subscription-style API rather than a timer, the pattern is identical: capture what `addListener`/`subscribe` returns, and call its corresponding remove/unsubscribe method in the cleanup - the general rule being that anything a `useEffect` starts, its cleanup function is responsible for stopping, with no exceptions for "but it's probably fine."

Question 50

What's the practical difference between a native platform permission being denied and being permanently denied ("don't ask again") on Android, and how should a React Native app handle each case?

Accepted Answer

When a user denies a runtime permission (camera, location, notifications) the first or second time, the app can still call `request` again later and the OS will show the system permission dialog again - a normal "not granted yet" state you can recover from by just asking again at a better moment (e.g. right when the user taps a feature that needs it, rather than on app launch). But after a user denies a permission enough times (Android's exact threshold varies by version, and it also happens automatically if they check "don't ask again"), Android moves it to a permanently-denied state where calling `request` again does nothing - it resolves immediately with "denied" and never shows the system dialog again, silently.

React Native's permission libraries (`react-native-permissions` is the common one) expose this distinction explicitly through result values like `RESULTS.DENIED` (can ask again) versus `RESULTS.BLOCKED` (permanently denied, can't ask again programmatically) - code that only checks a boolean "granted or not" and calls `request()` again in a loop will just keep silently failing once a user hits `BLOCKED`, with no dialog ever appearing and no obvious reason why from the user's side.

```js
const result = await request(PERMISSIONS.ANDROID.CAMERA);
if (result === RESULTS.BLOCKED) {
  // requesting again does nothing - the only path forward is app settings
  Alert.alert('Camera needed', 'Enable it in Settings.', [
    { text: 'Open Settings', onPress: () => Linking.openSettings() },
  ]);
}
```

The correct handling is checking for `BLOCKED` specifically and, only in that case, directing the user to `Linking.openSettings()` to change it manually - re-requesting is the right move for `DENIED`, but a dead end for `BLOCKED`.

React Native Interview Questions & Answers

Ready to practice these live?