115 React Native Interview Questions and Answers (2026)

Both make elements tappable, but TouchableOpacity is an older, single-purpose component that just fades opacity on press, while Pressable is the newer, more flexible primitive that exposes rich press states and lets you define any feedback you want.

• TouchableOpacity:

  • Wraps children and reduces their opacity while pressed; simple but limited to that one visual effect.

  • Part of the older Touchable family (TouchableHighlight, TouchableWithoutFeedback).

• Pressable:

  • The modern, recommended API with broader detection: onPressIn, onLongPress, onPressOut, plus hitSlop and pressRetentionOffset.

  • Accepts a function for style and children that receives a pressed flag, so you control feedback fully.

• Guidance: Prefer Pressable for new code; TouchableOpacity is fine for a quick opacity effect and still widely used.

React Native doesn't render to the DOM, so HTML tags like div and span don't exist; instead you use RN components like View and Text, which map to real native views on each platform.

• There is no browser or DOM: HTML elements are a web concept; RN targets native UI toolkits, so the tag names simply aren't defined.

• View is the layout primitive: It's the RN equivalent of a non-scrolling container div, supporting flexbox layout, styling, and touch handling.

• Under the hood it becomes a native view:

  • A View is backed by UIView on iOS and android.view.ViewGroup on Android.

  • Your JSX describes a virtual tree; RN's renderer (Fabric) reconciles it and instructs the native side to create/update the corresponding native views.

• Text is special: Unlike the web, raw strings must be inside a Text component (there's no anonymous text node like span).

A controlled TextInput has its value driven by React state (the state is the source of truth), while an uncontrolled input lets the native field manage its own text and you read it only via callbacks or refs.

• Controlled:

  • You pass value and update it in onChangeText; the displayed text always reflects state.

  • Enables validation, formatting, and clearing the field programmatically.

• Uncontrolled:

  • You omit value (optionally set defaultValue) and read text on events or through a ref; the native input holds the state.

  • Less re-rendering, useful for simple or performance-sensitive fields.

• Practical note: Controlled inputs are the common React pattern; watch for cursor/typing lag if state updates are heavy or async.

The Image component displays images from local bundles or remote URLs, and resizeMode controls how the image is scaled to fit the dimensions of its frame.

• Sources differ by type:

  • Local assets use require('./img.png') and get bundled with known dimensions.

  • Remote images use { uri: 'https://...' } and require explicit width/height since size isn't known upfront.

• resizeMode options:

  • cover: scale to fill the frame, cropping overflow (default).

  • contain: scale so the whole image fits, possibly leaving empty space.

  • stretch: fill the frame, distorting aspect ratio.

  • center: center at native size, no scaling.

  • repeat: tile the image to fill the frame.

• Behind the scenes: It maps to the platform's native image view and handles caching; remote images load asynchronously with onLoad/onError events.

React Native maps components to native views, and strings aren't valid native view children: only Text (which maps to a native text primitive) knows how to lay out and render glyphs.

• Components map to native views:

  • A View maps to a container (UIView/android.view.View) that has no concept of drawing text.

  • A Text maps to a native text node that handles font, glyph shaping, and line breaking.

• Different layout model: Views use flexbox layout; text uses text layout, and nested Text flows inline rather than as flex boxes.

• Enforced early: Putting a raw string in a View throws "Text strings must be rendered within a <Text> component".

You wire a RefreshControl into a scrollable list via its refreshControl prop (or the onRefresh/refreshing props on FlatList): it renders the native spinner and calls your handler when the user pulls down.

• Role of RefreshControl:

  • It's the platform-native pull-to-refresh indicator, not a custom JS animation.

  • Driven by two things: a boolean refreshing (show/hide spinner) and an onRefresh callback.

• You own the state: Set refreshing to true when the fetch starts and back to false when it resolves, or the spinner never dismisses.

• FlatList shortcut: Pass onRefresh and refreshing directly and it builds the RefreshControl for you.

The StatusBar component is a declarative interface to the native OS status bar (clock, battery, signal): you set its style, background, and visibility, and multiple mounted StatusBar components merge with the last-mounted winning.

• Key props:

  • barStyle: controls text/icon color (light-content, dark-content).

  • backgroundColor (Android only) and hidden to show/hide it.

  • translucent (Android) lets content draw behind the bar.

• Per-screen control:

  • Because it's declarative, render a StatusBar inside each screen so it updates as you navigate; the last mounted one applies.

  • With React Navigation, re-apply on focus (e.g. useFocusEffect) so returning to a screen restores its style.

• Imperative API: Static methods like StatusBar.setBarStyle() exist for one-off changes outside render.

ScrollView renders all its children at once, while FlatList virtualizes: it only renders items near the viewport and recycles the rest, so use ScrollView for small, finite content and FlatList for long or unbounded lists.

• ScrollView:

  • Mounts every child immediately, regardless of visibility.

  • Simple and fine for a handful of items (a form, a few cards); memory grows with content.

• FlatList:

  • Built on VirtualizedList: renders a window of items and unmounts off-screen ones.

  • Takes data + renderItem, plus built-ins like keyExtractor, separators, headers, and pull-to-refresh.

• Rule of thumb:

  • Fixed, small, non-scrolling-heavy content: ScrollView.

  • Long, dynamic, or data-driven lists: FlatList to keep memory and render cost bounded.

  • Never nest a large FlatList inside a ScrollView of the same axis: it loses virtualization.

Use SectionList when your data is grouped into labeled sections with headers (contacts by letter, settings groups, a menu by category): it virtualizes both rows and section headers, which a FlatList can't do cleanly.

• When to prefer it:

  • Data has natural groups needing sticky or repeating headers per group.

  • You want renderSectionHeader and stickySectionHeadersEnabled without manually flattening data.

• Data shape: Instead of a flat array it takes sections: an array of objects, each with its own data array (and optional per-section fields like a title).

You pass parameters as the second argument to navigation.navigate('Screen', { ... }) and read them on the destination via the route.params object (or the useRoute() hook). Params should be small, serializable identifiers.

• Sending params:

  • navigate('Profile', { userId: 42 }) passes data forward.

  • Use navigation.setParams(...) to update the current screen's params.

  • To send data back, pass a callback param or use navigate back to the previous route with new params.

• Reading params:

  • Class/props style: route.params.userId from the route prop.

  • Hooks style: const { userId } = useRoute().params.

  • Provide defaults with initialParams on <Stack.Screen>.

• Best practices:

  • Pass IDs, not large objects; params should be serializable (no functions ideally) so deep linking and state persistence work.

  • Fetch the full entity on the destination using the ID, or read it from global state.

They are three navigator types with different UX and mental models: Stack is a history stack you push/pop through, Tabs switch between sibling sections via a tab bar, and Drawer reveals a side menu of destinations. You compose them (often nesting) to model your app's structure.

• Stack navigator:

  • LIFO history: push adds a screen, goBack/pop removes it, with slide transitions and a back button.

  • Use for drill-down flows: list to detail, multi-step forms, checkout.

• Tab navigator:

  • Bottom (or top) tab bar switching between parallel, top-level sections that each keep their own state.

  • Use for primary app areas: Home, Search, Profile.

• Drawer navigator:

  • Slide-in side panel listing destinations, good when there are many sections or secondary items.

  • Use for account settings, less-frequent destinations, or content-heavy apps.

• They compose: Common pattern: a Tab navigator where each tab contains its own Stack, so navigation history is per-tab.

AsyncStorage is a simple, unencrypted, asynchronous, string-only key-value store, and those very traits become limitations for anything beyond small, non-sensitive persisted state.

• Performance: Asynchronous and bridge-based, so every access is a Promise and throughput is limited for frequent or bulk operations.

• Data model:

  • Stores only strings, so objects must be JSON.stringify/JSON.parse'd manually.

  • No querying, filtering, or relations: it's flat key-value only.

• Security: Not encrypted, so it's unsuitable for tokens, credentials, or sensitive data (use secure storage instead).

• Capacity: Meant for small amounts of data; on Android it has historically had size limits and isn't intended for large datasets.

• Takeaway: fine for small, non-sensitive config, but reach for MMKV (speed) or SQLite/WatermelonDB (structure) as needs grow.

AppState reports whether your app is active, background, or inactive, so you can react to foreground/background transitions: pause media when leaving, resume or refresh when returning.

• The states:

  • active: app in foreground and receiving events.

  • background: app running behind another app or on the home screen.

  • inactive: iOS-only transitional state (incoming call, multitasking, notification shade).

• How you subscribe:

  • Add a listener with AppState.addEventListener('change', handler) and remove it on cleanup.

  • Compare the previous state to the new one via a ref to detect a true background→active transition.

• Typical uses:

  • On leaving active: pause video, stop timers, save draft state.

  • On returning to active: refetch data, resume playback, revalidate the session/token.

All three re-run your app after a code change, but they differ in how much state they preserve. Fast Refresh is the modern default that keeps component state while updating; Hot Reloading and Live Reloading are the older mechanisms it replaced.

• Live Reloading (oldest):

  • Reloads the entire app on save, like refreshing a browser page.

  • All in-memory state is lost every time.

• Hot Reloading (legacy): Injected only changed modules to preserve state, but was fragile and often failed to update correctly.

• Fast Refresh (current, default since RN 0.61):

  • Combines the best of both: preserves component state for function components and Hooks while applying edits instantly.

  • Automatically does a full reload when it can't safely patch (e.g. editing outside a component, syntax errors that then resolve).

  • Recovers gracefully from redbox errors once you fix the code.

React Native's Metro bundler resolves platform-specific extensions automatically: when you import a module, it picks the .ios.js file on iOS and .android.js on Android, letting you swap implementations without changing import statements.

• How resolution works:

  • You import without the extension (import Button from './Button').

  • Metro looks for Button.ios.js / Button.android.js first, then falls back to Button.js.

• When to use it:

  • The two platforms need substantially different implementations (native modules, layout, or third-party APIs).

  • Keeps the calling code identical and clean across the app.

• Also supported: .native.js (shared between iOS/Android but distinct from web in a React Native Web setup).

• Trade-off: heavy duplication is a smell: prefer inline Platform.select for small differences and reserve file splitting for genuinely divergent code.

Platform.select takes an object keyed by platform (ios, android, default) and returns the value matching the current platform: it's a clean, declarative way to pick a value inline, especially inside style objects.

• How it works:

  • It reads Platform.OS and returns the matching key's value, falling back to default if the platform key is missing.

  • The return value can be anything: a style, a number, even a component or function.

• When it beats an if check:

  • Inside expressions where statements aren't allowed (style objects, JSX props, default arguments).

  • More readable and compact for value selection than an if/ternary chain.

• When a plain conditional is better:

  • Branching logic or side effects (running different code paths), not just picking a value.

  • Note: all branches in the object are evaluated, so avoid it if a branch is expensive to construct.

An OTA update changes only the JavaScript bundle/assets of an already-installed app without going through app review, while a Store update ships a new native binary that must be reviewed and installed via the App Store or Play Store.

• Scope of change:

  • OTA: JS, UI, styling, assets only.

  • Store: native code, new native modules, permissions, SDK/OS target changes, icons.

• Speed and review:

  • OTA: near-instant, no review, applied on next app launch.

  • Store: subject to Apple/Google review and staged rollout, takes hours to days.

• Delivery:

  • OTA: fetched from an update server, gated by runtimeVersion/channel.

  • Store: user downloads a full new binary.

• Use each for:

  • OTA: quick bug fixes, copy/UI tweaks, hotfixes.

  • Store: anything touching native code or requiring review.

Yoga is React Native's cross-platform layout engine: a C-based implementation of Flexbox that takes your style props and computes the position and size of every view, then hands those values to the native layout system.

• What Yoga is:

  • A portable C/C++ library that implements the Flexbox algorithm identically on iOS and Android, so layout is consistent across platforms.

  • It is layout-only: it knows nothing about colors, text, or drawing.

• How the translation works:

  • Your JS style props (flexDirection, justifyContent, padding) are set on a Yoga node mirroring the view tree.

  • Yoga runs the Flexbox calculation and produces concrete geometry: absolute x, y, width, height for each node.

  • Those frames are applied to the real native views (UIView on iOS, android.view.View on Android).

• Why it matters:

  • Layout is decoupled from the JS thread's business logic and can run on the shadow/layout thread, keeping the UI responsive.

  • One engine means the same style produces the same layout everywhere, reducing platform divergence.

React Native uses Flexbox as the primary layout system with a few opinionated defaults that differ from the web, chosen to make mobile column layouts the common case.

• Default flexDirection is column, not row: Web defaults to row; mobile screens are tall, so column is the sensible default.

• No layout units, only density-independent numbers: There is no px, em, or % for most props; you pass unitless numbers (percentages are supported as strings for some props).

• Flexbox is the only layout model: No CSS Grid, no floats, no display: block; everything is Flexbox or absolute positioning.

• Small default differences:

  • Every View behaves like display: flex by default; flex takes a single number rather than the full flex-grow/shrink/basis shorthand.

  • Only relative and absolute positioning exist (no fixed or sticky).

Density-independent pixels (dp/dip) are an abstract unit that stays visually consistent across screens of different pixel densities: React Native's layout numbers are in these units, and the OS multiplies them by the device's scale factor to get physical pixels.

• The problem they solve: A raw pixel is tiny on a high-density phone and large on a low-density one, so hardcoding pixels would make UI shrink or grow unpredictably.

• How the numbers map:

  • A style value like width: 100 means 100 dp; physical pixels = dp × device pixel ratio (e.g. 2x or 3x).

  • You read the ratio via PixelRatio.get() and query screen size with Dimensions.get('window') or the useWindowDimensions() hook.

• Snapping to real pixels:

  • Use PixelRatio.roundToNearestPixel() to avoid blurry edges from fractional dp values.

  • For images, provide @2x and @3x assets so the correct resolution loads per density.

Prefer StyleSheet.create for static styles: it lets React Native register the style once and pass a stable ID, whereas inline object literals allocate a new object on every render and can defeat memoization.

• Inline styles:

  • A new object is created each render, so a child receiving it via style sees a changed prop and may re-render unnecessarily.

  • Fine for genuinely dynamic values (a computed width or animated color) that must change per render.

• StyleSheet.create:

  • Returns numeric IDs referencing styles registered once; the object is stable across renders, which helps React.memo and reduces bridge traffic historically.

  • Also enables validation and clearer, reusable style definitions.

• Practical rule:

  • Keep static styles in StyleSheet.create and merge dynamic bits with an array: style={[styles.box, { width }]}.

  • In modern architecture the difference is smaller than it once was, but the memoization and readability benefits remain.

React Native has no media queries, so responsiveness comes from runtime measurement plus Flexbox: you read the current dimensions and orientation and compute sizes relative to them rather than declaring breakpoints in a stylesheet.

• Measure at runtime:

  • Use useWindowDimensions() (re-renders on rotation/resize) instead of a one-time Dimensions.get.

  • Branch on width/height or aspect ratio to switch layouts, mimicking breakpoints in JS.

• Let Flexbox do proportional work: Use flex, percentage widths, and flexWrap so content adapts without hardcoded sizes.

• Respect safe areas and platform:

  • Wrap content in SafeAreaView / use safe-area insets for notches and system bars.

  • Use Platform.select for platform-specific tweaks.

• Libraries: Helpers like react-native-responsive-screen or scaling utilities standardize proportional sizing across devices.

React Native has essentially no style inheritance: styles apply only to the component you set them on, unlike CSS where properties like color and font-size cascade from parents to descendants.

• No cascade:

  • Setting a text style on a View does not affect child Text elements; each component styles itself.

  • There are no selectors, specificity, or global stylesheets to cascade from.

• The one exception: nested Text: A Text nested inside another Text does inherit font properties from its parent Text.

• How you get reuse instead:

  • Compose styles explicitly with arrays: style={[base, override]} (later entries win).

  • Build shared theme objects or wrapper components (e.g. a custom AppText) to propagate typography deliberately.

React Native renders real, platform-native UI widgets driven by JavaScript, whereas Cordova/Ionic render an HTML/CSS web app inside a full-screen WebView (a browser embedded in the app).

• React Native = native components:

  • A View becomes a real UIView (iOS) or android.view.View (Android), so scrolling, gestures, and animations use the platform's own rendering.

  • JS runs in a separate engine and communicates with native UI (historically over the bridge, now via JSI/Fabric).

• Cordova/Ionic = WebView: The entire UI is a web page; native access happens through plugins that expose device APIs to JavaScript.

• Performance and feel: Native rendering gives smoother 60fps interactions and a truly platform-native look; WebView UI can feel less native and lag on complex screens.

• Trade-off: WebView frameworks reuse web skills and code most directly, but RN gives better performance and access to native components at the cost of a native build toolchain.

React Native ships a real installable native app with full device access and native performance, while a PWA is a web app that runs in the browser with instant delivery and no app store, but limited native capability.

• Distribution:

  • PWA: served from a URL, no app store review, instant updates.

  • RN: distributed via App Store/Play Store (discoverability, but review delays and store rules).

• Device capability:

  • RN has deep access (Bluetooth, background tasks, rich push, camera, secure storage).

  • PWA is sandboxed by the browser; iOS in particular restricts push, background work, and hardware APIs.

• Performance and UX: RN renders native widgets for a more native feel; PWAs depend on browser performance.

• Development cost:

  • PWA: one web codebase, cheapest to ship and maintain.

  • RN: native builds, store accounts, and platform quirks add overhead.

• Rule of thumb: Choose PWA for reach, quick iteration, and content-driven apps; choose RN when you need native performance, hardware, or store presence.

Modal renders its content in a native overlay above the rest of the app, and while the core API is the same, iOS and Android differ in presentation style, back-button handling, and animation defaults.

• How it works:

  • You control it with the visible prop; animationType (slide, fade, none) sets the transition.

  • It presents natively over the current screen rather than inside the normal view hierarchy.

• Android specifics:

  • The hardware/gesture back button triggers onRequestClose, so that prop is effectively required.

  • statusBarTranslucent affects whether it draws under the status bar.

• iOS specifics: presentationStyle (fullScreen, pageSheet, formSheet, overFullScreen) controls the sheet-style presentation; there's no hardware back button.

• Practical note: Always handle onRequestClose for Android parity, and many teams prefer library modals for more consistent cross-platform styling.

getItemLayout tells the list the exact height (and offset) of each item ahead of time, so it can skip on-the-fly measurement: this makes scrolling smoother and enables reliable jumps like scrollToIndex.

• What it returns: An object { length, offset, index } where length is the item size and offset its position from the start.

• Why it helps:

  • Without it the list must render and measure cells to know their positions, causing layout work and sometimes blank areas.

  • With it the list computes total content size and any item's position by math, so scrollToIndex and windowing are instant and accurate.

• Constraint: Only usable when item heights are fixed/known; wrong values cause misaligned scrolling.

keyExtractor gives each item a stable identity so React can match rendered components to data across updates; if keys aren't stable (like array indices), React reuses the wrong component instances on a re-order, causing wasted re-renders and stale/misplaced state.

• Keys drive reconciliation:

  • React uses the key to decide whether to reuse, move, or unmount a component when the list changes.

  • A stable unique id (item.id) lets React move an existing instance instead of rebuilding it.

• Why index keys break on re-order:

  • The key describes a position, not an item, so after reordering the same key points to different data.

  • React thinks the component at index 0 is unchanged and just updates props, so internal state (text input, animations, selection) sticks to the wrong row.

  • It also defeats efficient moves, forcing more re-renders than necessary.

• Rule: Always derive the key from stable data identity, not from index, for any list that can reorder, insert, or delete.

Clipped subviews (via the removeClippedSubviews prop) is an optimization that detaches off-screen child views from the native view hierarchy while keeping them mounted, reducing the number of live native views the OS must track.

• What it does:

  • Views scrolled outside the visible bounds are removed from the native view tree and re-attached when they come back.

  • This lowers native memory/rendering pressure for long lists with many complex rows.

• How it differs from windowing:

  • Windowing (VirtualizedList) unmounts the JS components entirely; clipping only detaches the native view while the component stays mounted.

  • They're complementary layers of optimization.

• Caveats: Enabled by default in VirtualizedList on Android; enabling it can occasionally cause blank/missing content or touch issues, so test.

Choppy FlatList scrolling usually means the JS thread is doing too much work per frame during render or scroll: fix it by making item rendering cheap, stable, and virtualization-friendly.

• Memoize item rendering: Wrap the row in React.memo and pass a stable renderItem (defined outside render or via useCallback) so items don't re-render on every parent update.

• Provide stable keys: Use a real unique keyExtractor: avoid array index so React can reuse rows instead of remounting them.

• Give the list size hints: If rows are fixed height, implement getItemLayout so it can skip measuring and jump to offsets instantly.

• Tune virtualization windows: Lower windowSize, maxToRenderPerBatch, and initialNumToRender to render fewer cells per frame; enable removeClippedSubviews to detach offscreen rows.

• Make each cell cheap: Flatten deep view trees, avoid heavy inline work, and cache/resize images: expensive layout or image decode per row causes dropped frames.

• Move work off the JS thread: Do filtering/sorting outside renderItem, and if it's still choppy consider FlashList for recycling.

You rarely use VirtualizedList directly: it's the low-level base that FlatList and SectionList are built on. Reach for it only when your data isn't a plain array and you need custom access to items.

• Non-array or unusual data sources: It exposes getItem and getItemCount so you can back the list with an immutable structure, a map, or a windowed data store instead of a JS array.

• Custom virtualization behavior: When you need finer control over how items are read and counted than FlatList's array-based API allows.

• Default to FlatList: For normal array data, FlatList gives you the same virtualization plus conveniences (keyExtractor, separators, headers), so prefer it and drop to VirtualizedList only when those get in the way.

Choose FlashList when FlatList is still choppy with large or complex lists: it reuses (recycles) a small pool of view instances instead of mounting/unmounting a component per row, which is far cheaper on the JS thread and memory.

• What cell recycling means: When a row scrolls offscreen, its view isn't destroyed: it's repositioned and re-bound with new data for the row scrolling into view, so you keep a fixed number of cells regardless of list length.

• FlatList vs FlashList: FlatList virtualizes but still mounts/unmounts real components as you scroll; FlashList recycles them, giving smoother scroll and lower memory on long lists.

• When to switch: Large datasets, heavy rows, or measurable frame drops after tuning FlatList.

• Cost of recycling: You should provide estimatedItemSize, and because views are reused you must reset any local/mutable state so recycled rows don't show stale content.

Both give you a stack, but @react-navigation/native-stack uses the platform's native navigation primitives while @react-navigation/stack reimplements the stack in JS. Prefer native-stack by default for performance and native feel; use the JS stack when you need deep customization of transitions.

• native-stack (native):

  • Backed by UINavigationController (iOS) and Fragments (Android), so transitions and gestures run on the native side: smoother, better default behavior, less JS overhead.

  • Trade-off: animations and headers are less customizable because they're native.

• stack (JS):

  • Transitions run on the JS/Reanimated thread, giving full control over custom animations, gesture behavior, and header styling.

  • Trade-off: more JS work, so potentially less smooth on lower-end devices.

• How to choose: Default to native-stack; switch to the JS stack only when a design needs custom transition animations native-stack can't express.

React Navigation maps each platform's native "go back" affordance to popping the current stack screen: Android's hardware/gesture back button and iOS's edge swipe both trigger the same navigation action when there's a screen to pop.

• Android hardware back:

  • React Navigation listens to the OS back event and pops the stack; if the stack is at its first screen it lets the event bubble so the app can exit.

  • You can override per-screen with the BackHandler API to intercept back (e.g. confirm before leaving).

• iOS swipe-back gesture:

  • The edge-swipe pops the current screen; controlled with gestureEnabled and is only available on stack navigators (not tabs).

  • There's no equivalent hardware button on iOS, so the gesture and the header back button are the primary back paths.

• Common abstraction: Both ultimately dispatch a goBack/pop action, so your navigation logic stays the same across platforms.

Nesting navigators (a Stack inside each Tab) is normal and powerful: it lets each tab keep its own navigation history. The trade-offs are around navigation complexity, header duplication, and how state and options flow between the parent and child.

• Benefits:

  • Each tab retains its own stack history, so switching tabs preserves where you were.

  • Clear separation of flows and independent deep-link targets.

• Complexity of navigating across navigators: Jumping to a screen in another navigator requires nested navigation calls (navigation.navigate('Tab', { screen: 'Detail' })), which is easy to get wrong.

• Header and option layering:

  • A Stack inside a Tab can produce two headers; you often set headerShown: false on one level to avoid duplication.

  • Screen options set on the child don't automatically propagate to the parent tab bar; you may need getFocusedRouteNameFromRoute to hide the tab bar on deep screens.

• State and lifecycle: Inactive tabs stay mounted by default, so their screens keep state (and can keep running work) unless you unmount lazily.

• Rule of thumb: Nest when flows genuinely need independent history; avoid over-nesting since each layer adds indirection to navigation and back behavior.

Navigation state is the router's own data structure describing which screens exist, their order, and their params, whereas global app state (Redux, Zustand, Context) holds business/domain data. They overlap but should stay separate concerns.

• What navigation state contains:

  • A serializable tree of navigator routes, the active index, per-route params, and nested navigator state.

  • Owned and mutated by React Navigation via actions like navigate, push, goBack.

• What global app state contains:

  • Domain data: user profile, cart, cached API results, auth tokens, feature flags.

  • Lives longer than any single screen and is unrelated to where the user currently is.

• Why keep them separate:

  • Navigation state is UI/position; global state is data. Mixing them makes both harder to reason about.

  • Auth is the classic boundary: store the token in global state, and derive which navigator (auth vs app) to render from it, rather than pushing/popping screens manually.

• Params vs global state trap: Params are fine for identifiers (userId); don't shove large objects into params, fetch or read them from global state on the destination screen.

A URL Scheme is a custom protocol (like myapp://) that only your app registers, while Universal Links (iOS) and App Links (Android) use real https:// URLs verified to belong to your domain. The key difference is trust and fallback behavior.

• Custom URL Scheme:

  • Format like myapp://profile/42; simple to set up and works for app-to-app or in-app deep links.

  • Not verified: any app can claim the same scheme, so it's spoofable.

  • No graceful web fallback: if the app isn't installed, the link just fails.

• Universal Links / App Links:

  • Use standard https:// URLs that double as your website URLs.

  • Ownership is verified via a file hosted on your domain (apple-app-site-association for iOS, assetlinks.json for Android).

  • Graceful fallback: if the app isn't installed, the same URL opens in the browser.

  • Secure: other apps can't hijack them because the domain association is validated.

• In React Native:

  • Both are configured in the linking config of React Navigation / Expo Router, which maps incoming URLs to screens.

  • Rule of thumb: prefer Universal/App Links for public shareable links; use custom schemes for internal or OAuth redirects.

React Navigation emits focus when a screen becomes active and blur when the user leaves it, letting you run code tied to the screen being visible. useFocusEffect is preferred over useEffect because screens are kept mounted, so a plain effect won't re-run when you navigate back.

• The core problem:

  • In a stack, a background screen stays mounted, so useEffect(fn, []) runs once and never fires again when you return to it.

  • You often want work to run every time the screen is focused (refresh data, start a subscription).

• How the events work: Subscribe via navigation.addListener('focus', ...) / 'blur', or read status with useIsFocused().

• useFocusEffect:

  • Runs its effect on focus and runs the cleanup on blur, every time.

  • Wrap the callback in useCallback to avoid re-running on every render.

  • Use it to start/stop timers, listeners, or data refreshes scoped to visibility.

react-native-screens is a library that makes each React Navigation screen use the platform's native container view (UIViewController on iOS, Fragment on Android) instead of plain JS-managed <View>s. This lets the OS manage the view hierarchy, improving memory use and transition performance.

• The problem it solves: Without it, every screen in a stack stays fully mounted and attached in the native view tree, consuming memory and layout/render work even when off-screen.

• What it does:

  • Backs screens with native containers so off-screen screens can be detached from the view hierarchy.

  • Hands transitions and gestures to native navigation primitives (the native stack), giving smoother, platform-accurate animations.

• Why performance improves:

  • Less to render and lay out at once; reduced memory footprint on deep stacks.

  • Native-driven transitions run off the JS thread, so animations stay smooth even under JS load.

• Practical note: It's enabled by default in modern React Navigation and powers the native stack navigator (createNativeStackNavigator).

useNativeDriver: true tells the Animated API to send the entire animation definition to the native side once, so the animation runs on the UI thread instead of being driven frame-by-frame from JS. This means it keeps running smoothly even if the JS thread is busy.

• What it actually does:

  • Normally the JS thread computes each frame's value and sends a bridge update; with the native driver, the whole animation is serialized and executed by native code on the UI thread.

  • Result: no per-frame bridge traffic, so animations don't stutter when JS is blocked (e.g. rendering a list).

• What it can animate: Only non-layout, purely visual properties: opacity and transform (translateX/Y, scale, rotate).

• Why not width, height, or flex:

  • Those trigger layout: changing them requires re-running the Yoga layout engine and repositioning siblings, which the native animation driver cannot do off the JS/shadow thread.

  • The native driver only mutates properties that can be applied directly on a view without recalculating layout.

• Practical trap: if you set useNativeDriver: true on an unsupported prop, you get a runtime warning/error. Animate scale instead of width where possible.

Both animate UI, but the core Animated API is JS-thread driven (with an optional limited native driver), while Reanimated runs your animation logic directly on the UI thread via worklets, giving it far broader and more reliable off-thread animation and gesture support.

• Animated (built-in):

  • Values are computed on the JS thread; useNativeDriver offloads only opacity and transform.

  • Cannot natively animate layout props, and complex gesture-driven logic still runs on JS.

• Reanimated:

  • Uses worklets: JS functions run synchronously on the UI thread.

  • Shared values (useSharedValue) and useAnimatedStyle let you drive any style, including layout, entirely off the JS thread.

  • Pairs tightly with react-native-gesture-handler for jank-free gesture animations even when JS is busy.

• Bottom line: Animated is fine for simple, self-contained transitions; Reanimated is the choice for complex, interactive, gesture-driven animations that must stay smooth under JS load.

Use LayoutAnimation when you want to automatically animate the transition between two layout states after a state change, rather than manually driving an animated value. It's ideal for simple layout shifts (adding/removing items, expanding a view) where you don't need fine control.

• How it works:

  • You call LayoutAnimation.configureNext(...) right before a setState; the next layout pass animates from the old positions/sizes to the new ones.

  • It animates real layout properties (width, height, position) that the native driver can't.

• When to prefer it over Animated:

  • You just want a whole layout to reflow smoothly without wiring up individual animated values.

  • Common cases: expanding/collapsing a card, list insert/remove, accordion.

• Limitations:

  • No per-frame control, can't chain or sequence precisely, and you can't drive it from a gesture.

  • On Android you must enable UIManager.setLayoutAnimationEnabledExperimental(true).

  • For anything interactive or complex, use Animated or Reanimated instead.

PanResponder is React Native's built-in gesture system that reconciles raw touch events on the JS thread through a negotiation of handler callbacks. react-native-gesture-handler is a native alternative that recognizes and handles gestures on the UI thread, making it faster and more composable.

• How PanResponder works:

  • You create a responder with callbacks like onStartShouldSetPanResponder, onPanResponderMove, and onPanResponderRelease.

  • It implements the JS-based responder negotiation system: components 'ask' for and can be granted the touch, tracking gestureState (dx, dy, velocity).

  • All this runs on the JS thread, so heavy JS load causes laggy tracking.

• How gesture-handler differs:

  • Gesture recognition happens in native code, hooking into the platform's native gesture systems.

  • Provides declarative gesture objects (Pan, Pinch, Tap) that compose (simultaneous, exclusive, sequenced).

  • Combined with Reanimated worklets, gestures drive animations entirely off the JS thread.

• Rule of thumb: use gesture-handler for anything nontrivial or performance-sensitive; PanResponder only for simple cases with no extra dependency.

Interpolation maps an animated value from an input range to an output range, letting one driving value (like scroll position) produce many derived values (opacity, translation, rotation). You call .interpolate() on an Animated value and pass matching inputRange and outputRange arrays.

• How it works:

  • Each value in inputRange maps to the value at the same index in outputRange; values between are linearly interpolated.

  • Both ranges must be monotonic and the same length; output can be numbers or strings (e.g. '0deg', '180deg').

  • Use extrapolate: 'clamp' to stop values from going past the range ends.

• Scroll-driven example: Capture scroll with Animated.event into a value, then interpolate it into opacity or transform for a fading/shrinking header.

They're three animation types in the Animated API that differ in how the value moves over time: timing follows a duration and easing curve, spring uses physics-based spring dynamics, and decay starts with a velocity and gradually slows to a stop.

• Animated.timing:

  • Animates over a fixed duration using an easing function (linear, ease-in-out, bezier).

  • Best when you want precise, predictable timing (fades, controlled transitions).

• Animated.spring:

  • Physics model configured by stiffness/damping (or tension/friction); may overshoot and settle.

  • Best for natural, bouncy feel (a card snapping into place).

• Animated.decay:

  • Takes an initial velocity and a deceleration, then coasts to rest with no target value.

  • Best for momentum after a fling/swipe gesture.

They differ in who owns the native code: Managed keeps you in JS-only land with Expo handling native, Bare gives you full native projects to edit, and Prebuild is the modern bridge that generates the native folders on demand from config.

• Managed workflow:

  • No ios/ or android/ folders in your repo; you write only JS/TS and configure native behavior via app.json.

  • Expo builds and manages the native layer, so upgrades and native modules are handled through the SDK.

• Bare workflow:

  • You have full, committed native projects and can edit Objective-C/Swift/Java/Kotlin freely.

  • You still get Expo SDK libraries, but you own native build config and upgrades manually.

• Prebuild (modern flow):

  • You treat native folders as disposable build artifacts: npx expo prebuild regenerates ios/ and android/ from app.json plus config plugins.

  • This blurs the old Managed/Bare line: you stay config-driven yet can still access native code when needed.

• Key mental model: "ejecting" is largely obsolete; Prebuild lets you regenerate native code instead of forking it permanently.

Expo maximizes developer velocity and handles native plumbing for you; the RN CLI gives you total native control at the cost of doing that plumbing yourself. Expo becomes the wrong choice mainly when you need deep, custom native code or third-party SDKs that don't fit the config-plugin model.

• Expo Managed strengths:

  • Fast setup, OTA updates (EAS Update), managed builds, and a curated cross-platform SDK.

  • Less native maintenance: upgrades and config are handled through the framework.

• RN CLI strengths:

  • Direct access to native projects; easiest path for arbitrary native modules and platform-specific tuning.

  • No abstraction layer to fight when integrating an unusual SDK.

• When Expo is not ideal:

  • You depend on a native SDK with no Expo module or config plugin and complex native setup.

  • You need very tight control over build tooling, native threads, or custom native architecture.

  • Strict binary-size or dependency constraints where Expo's bundled modules add unwanted weight.

• Modern nuance: with Prebuild and config plugins, most "need native code" cases no longer require abandoning Expo, narrowing this gap considerably.

EAS Build compiles your app on Expo's cloud with reproducible, preconfigured environments, while local builds run on your own machine giving speed and control but requiring you to manage the whole toolchain.

• EAS Build (cloud):

  • Consistent, clean environments and no need to maintain Xcode/Android SDK versions locally.

  • Builds iOS without owning a Mac, manages signing/credentials, and integrates with CI easily.

  • Trade-offs: queue/wait times on shared tiers, cost at scale, and network dependency.

• Local build (Xcode/Android Studio):

  • Fast iteration once set up, full control, and no per-build cost.

  • Trade-offs: you own toolchain setup, signing, and "works on my machine" drift; iOS still needs a Mac.

• Practical middle ground: You can run EAS locally with eas build --local to get EAS's reproducible config while building on your own hardware.

A Dev Client is a custom-built version of the Expo Go app that includes your project's own native modules and configuration, so you can develop against a runtime that exactly matches your production app instead of Expo Go's fixed, shared SDK.

• What it is: A development build you create with expo-dev-client that bundles your specific native dependencies and still supports fast refresh over the Metro dev server.

• Why it beats Expo Go for production work:

  • Expo Go only contains the standard Expo SDK, so any custom native module or config plugin won't run there.

  • The Dev Client matches your actual native surface, so you catch native issues during development, not at release.

  • Lets you test third-party native libraries and custom entitlements that Expo Go can't load.

• Rule of thumb: Expo Go is for demos and learning; a Dev Client is the professional default once you have any custom native code.

MMKV is winning because it's a synchronous, in-memory-backed key-value store that's dramatically faster than AsyncStorage, whose asynchronous, bridge-crossing API adds latency and awkward code for simple reads.

• Asynchronous storage (AsyncStorage):

  • Every read/write returns a Promise and crosses the JS bridge, so you must await even trivial lookups.

  • Values are serialized strings, and throughput degrades with volume.

• Synchronous storage (MMKV):

  • Reads/writes return immediately, so you can read a value inline during render without a Promise.

  • Built in C++ with memory mapping and uses JSI (no async bridge), giving major performance gains.

  • Supports typed values (strings, numbers, booleans) and optional encryption.

• Why the shift: Simpler code (no await everywhere), better performance, and features like encryption make MMKV the modern default for small persisted state.

You persist global state by serializing a slice of the store to a storage engine on every change and rehydrating it on launch: redux-persist automates this on top of AsyncStorage.

• How it works:

  • You wrap your root reducer with persistReducer and create a persistStore that saves state to the storage engine automatically.

  • On startup it reads the saved blob and dispatches a rehydrate action to repopulate the store.

• Storage engine: AsyncStorage is the default: async, key-value, unencrypted. For large or sensitive data prefer react-native-mmkv (faster) or an encrypted store.

• Control what persists: Use whitelist/blacklist so you only persist durable state (auth, settings), not transient UI or loading flags.

• Rehydration gating: Wrap the app in PersistGate to delay rendering until state is restored, avoiding a flash of default state.

• Migrations: Bump version and supply a migrate function when your state shape changes, so old persisted data doesn't crash the app.

NetInfo exposes the device's connectivity state (connected or not, connection type, reachability), letting an offline-first app detect when it's online, queue work while offline, and sync when the connection returns.

• What it reports:

  • isConnected (has a network link) and isInternetReachable (can actually reach the internet, which can differ, e.g. captive Wi-Fi).

  • type (wifi, cellular, none) and details like whether the connection is expensive/metered.

• Two access patterns:

  • NetInfo.fetch() for a one-time snapshot.

  • NetInfo.addEventListener() to react continuously to changes.

• Offline-first role:

  • Drive UI: show an offline banner, disable actions, or serve cached data.

  • Trigger sync: when connectivity is restored, flush a queue of pending mutations.

• Caveat: Prefer isInternetReachable over isConnected alone; being on a network doesn't guarantee real internet access.

The Linking API lets your app open URLs and other apps through the OS's URL-scheme mechanism, and also receive inbound deep links that launch your app.

• Opening things out:

  • Linking.openURL() hands a URL to the OS, which routes it by scheme: https: (browser), tel: (dialer), mailto:, sms:, geo:/maps links.

  • Check first with Linking.canOpenURL(); on iOS unlisted schemes must be declared in LSApplicationQueriesSchemes.

• Receiving inbound links (deep links):

  • Linking.getInitialURL() reads the URL that cold-started the app.

  • Linking.addEventListener('url', ...) handles links while the app is already running.

• Practical notes:

  • Calls are async and can reject: always wrap in try/catch or check reachability first.

  • Universal/App Links (real https domains) give a smoother experience than custom schemes for opening your own app.

Push notifications are messages delivered to a device to alert or update the user: local notifications are scheduled by the app itself on-device, while remote (push) notifications originate from your server and travel through platform push services (APNs for iOS, FCM for Android).

• Local notifications:

  • Scheduled and fired by the app on the device (reminders, timers, geofence triggers).

  • No network or server required; work fully offline.

• Remote notifications: the flow:

  1. The app requests permission and registers, receiving a unique device token.

  2. It sends that token to your backend.

  3. Your server sends a payload to APNs or FCM, addressing the token.

  4. The platform service delivers it to the device, even when the app is closed.

• Handling in-app:

  • Behavior differs by app state: foreground (you often present it manually), background, and killed (OS displays it, app wakes on tap).

  • Payloads can be alert-style (visible) or silent/data-only to trigger a background fetch.

• Tooling: Libraries like Notifee, @react-native-firebase/messaging, or Expo Notifications abstract token registration and display.

React Native accesses native permission APIs (usually via PermissionsAndroid or react-native-permissions): both platforms require declaring permissions up front, but they differ sharply in when and how the user is prompted at runtime.

• Declaration is required on both:

  • Android: list permissions in AndroidManifest.xml.

  • iOS: add usage-description strings (e.g. NSCameraUsageDescription) in Info.plist; missing strings cause a crash.

• Android runtime model:

  • Normal permissions are granted at install; dangerous ones (camera, location) are requested at runtime via PermissionsAndroid.request().

  • Users can deny and choose "don't ask again", after which you must route them to Settings.

• iOS runtime model:

  • Each sensitive resource can be prompted only once; a denial is permanent until the user changes it in Settings.

  • Offers finer states, e.g. location "while using" vs "always", and "limited" photo access.

• Best practice: Always check current status before requesting, request in context (right when the feature is used), and handle the blocked state by deep-linking to Settings.

You use the built-in WebSocket API (or a library like socket.io-client) to open a persistent, bidirectional connection to a server, letting the app push and receive messages in real time without polling.

• Establishing the connection:

  • Create new WebSocket(url) and attach onopen, onmessage, onerror, onclose handlers.

  • Send with ws.send(); dispatch received data into state (Redux, context, or a query cache).

• Lifecycle management:

  • Open the socket in an effect and close it on unmount to avoid leaks and duplicate listeners.

  • Use AppState: disconnect in background, reconnect when returning to foreground (mobile OSes kill idle sockets).

• Resilience:

  • Implement reconnection with exponential backoff, driven by onclose and NetInfo connectivity changes.

  • Send periodic heartbeats/pings to detect dead connections and keep them alive.

• When to use a library: socket.io adds rooms, auto-reconnect, and fallback transports; raw WebSocket is lighter when you control both ends.

KeyboardAvoidingView is a wrapper component that adjusts its size or position when the on-screen keyboard appears, so inputs stay visible. It's tricky because iOS and Android report and handle the keyboard differently, so the same behavior prop rarely works identically on both.

• How it works: It listens to keyboard show/hide events and applies a behavior: padding, height, or position, shrinking or shifting content by the keyboard's height.

• Why it differs across platforms:

  • On iOS behavior="padding" usually works well; on Android the OS often already resizes the window via android:windowSoftInputMode, so adding avoidance double-adjusts.

  • Android's adjustResize vs adjustPan manifest setting changes everything, sometimes making the component unnecessary or conflicting.

• Common practice:

  • Set behavior per platform: Platform.OS === 'ios' ? 'padding' : undefined.

  • Use keyboardVerticalOffset to account for headers, and wrap scrollable content to keep the focused input reachable.

React Native's built-in SafeAreaView only applies insets on iOS and only as fixed padding, while react-native-safe-area-context provides real, dynamic inset values that work on both iOS and Android (including notches, status bars, and navigation bars).

• Built-in SafeAreaView:

  • iOS-only: it's a no-op on Android, so you get no protection there.

  • Applies padding to the view itself, giving you no access to the raw inset numbers.

  • Deprecated in favor of the community library.

• react-native-safe-area-context:

  • Cross-platform and updates dynamically on orientation or system UI changes.

  • Exposes useSafeAreaInsets() so you can apply insets selectively (e.g. only top or only bottom).

  • Requires a SafeAreaProvider at the app root; it's what libraries like React Navigation depend on.

SafeAreaView is necessary because modern devices have notches, dynamic islands, rounded corners, and gesture bars that can overlap your UI; safe-area insets keep content within the usable screen. KeyboardAvoidingView is separately hard because Android's window-resize model conflicts with iOS's manual avoidance model.

• Why SafeAreaView matters:

  • Prevents important content and touch targets from hiding behind the status bar, notch, or home indicator.

  • Insets vary by device and orientation, so hardcoded padding breaks; a safe-area solution adapts automatically.

• Keyboard pitfalls on iOS: iOS doesn't resize the app window, so you must actively add padding or position avoidance, plus a keyboardVerticalOffset for headers.

• Keyboard pitfalls on Android:

  • The manifest windowSoftInputMode (adjustResize) already resizes the layout, so applying KeyboardAvoidingView can double-shift or produce jitter.

  • Fix: often leave behavior undefined on Android and rely on the OS, or configure softwareKeyboardLayoutMode consistently.

Both report screen size, but Dimensions is a one-time imperative read (with a manual event listener), while useWindowDimensions is a hook that re-renders your component automatically whenever the dimensions change. The hook is preferred because it keeps the UI in sync without boilerplate.

• Dimensions.get('window'):

  • Returns a snapshot at call time; it won't update on rotation or split-screen unless you add a listener.

  • Requires Dimensions.addEventListener and manual cleanup, which is easy to get wrong (stale values).

  • Still useful outside components (module scope, utility files) where hooks can't run.

• useWindowDimensions():

  • Subscribes internally and triggers a re-render on any change, so layout stays correct on rotation.

  • No listener setup or teardown, so no leak or stale-state risk.

• Rule of thumb: inside a component use the hook; only reach for Dimensions for non-reactive, one-off reads.

You detect the OS theme with the useColorScheme hook (or the Appearance API outside components), then pick styles based on whether it returns 'light' or 'dark'. The hook re-renders automatically when the user switches system theme.

• useColorScheme(): Returns 'light', 'dark', or null; reactive to system changes.

• Appearance API: Appearance.getColorScheme() for a one-off read, and Appearance.addChangeListener outside React components.

• Applying the theme:

  • Map the scheme to a theme object of colors and pass it through Context so all components read the same palette.

  • For a user override (light/dark/system toggle), store the choice and fall back to the hook when set to system.

Orientation changes are handled by making your layout responsive to dimension changes rather than assuming a fixed size: use useWindowDimensions to re-render on rotation, and lock or listen for orientation when you need explicit control.

• React to size, not orientation directly:

  • useWindowDimensions updates width/height on rotation; derive isLandscape = width > height to switch layouts.

  • Prefer flexbox and percentages so layouts adapt without conditional code.

• Explicit orientation control:

  • Use a library like expo-screen-orientation or react-native-orientation-locker to lock or listen for orientation events.

  • Set native defaults in Info.plist (iOS) and AndroidManifest.xml for allowed orientations.

• Watch out for: Recomputing safe-area insets on rotation (react-native-safe-area-context handles this automatically).

PixelRatio reports the device's pixel density, letting you convert between layout (density-independent) units and physical pixels. You need it when working with exact pixel sizes, such as fetching correctly-sized images or drawing hairline-thin lines.

• What it exposes:

  • PixelRatio.get() returns the density (e.g. 2 or 3); getPixelSizeForLayoutSize() converts dp to physical pixels.

  • PixelRatio.roundToNearestPixel() snaps a value to the device's pixel grid to avoid blurry edges.

• When you need it:

  • Requesting remote images at the exact resolution the device can display, saving bandwidth and keeping them crisp.

  • Drawing 1-pixel borders: 1 / PixelRatio.get() (what StyleSheet.hairlineWidth uses under the hood).

  • Font scaling awareness via getFontScale() for accessibility settings.

React Native offers a mix of JS-level and native-level debugging tools. React DevTools inspects the component tree and props/state, while Flipper (and the newer built-in debugger) gives a broader view including network, logs, layout, and native plugins.

• React DevTools:

  • Inspect the component hierarchy, props, state, and hooks; edit them live.

  • Includes the Profiler to measure render timing and find unnecessary re-renders.

• Flipper:

  • A desktop app with plugins: network inspector, logs, layout inspector, AsyncStorage viewer, crash reporter, and native (iOS/Android) inspection.

  • Being de-emphasized in newer RN versions in favor of a built-in debugging experience.

• Built-in / Hermes debugging: Newer RN uses a Chrome DevTools-based debugger over the Hermes engine for breakpoints, the console, and CPU/memory profiling.

• Native tooling: Xcode Instruments and Android Studio Profiler for native crashes, memory, and thread analysis that JS tools can't see.

Store secrets like JWTs in the OS-backed secure storage (iOS Keychain, Android Keystore/EncryptedSharedPreferences) via a library, because AsyncStorage is unencrypted plain-text storage readable on compromised devices.

• Why AsyncStorage is insecure:

  • It's an unencrypted key-value store (SQLite/plain files) accessible to anyone with filesystem access on a rooted/jailbroken device or via backups.

  • No hardware-backed protection or per-app encryption.

• Use secure, OS-backed storage:

  • react-native-keychain or expo-secure-store wrap the iOS Keychain and Android Keystore/EncryptedSharedPreferences.

  • These can leverage hardware-backed keys and biometric gating.

• Broader best practices:

  • Prefer short-lived access tokens plus a refresh token; minimize what's persisted.

  • Consider httpOnly cookies handled natively, and always transport over HTTPS.

Metro is React Native's JavaScript bundler: it transforms and bundles your JS/TS into a single file (or RAM bundle) the native app loads, and serves fast incremental updates during development. It's tuned for mobile rather than the web.

• What Metro does:

  • Resolves the module graph, transforms code with Babel (JSX, TypeScript, Flow), and outputs a bundle for the native runtime.

  • Serves the bundle over a dev server and streams updates.

• Differences from Webpack:

  • Target: Metro produces a JS bundle for a native JS engine (Hermes/JSC), not browser assets like HTML/CSS.

  • No tree-shaking/code-splitting in the web sense; instead it offers inline requires and RAM bundles for lazy module evaluation.

  • Optimized for huge module graphs with aggressive caching and fast incremental rebuilds.

• Hot reloading: Metro powers Fast Refresh: it recompiles only changed modules and pushes them over the socket, preserving component state where possible.

Autolinking automatically discovers native modules from your installed npm packages and links them into the iOS and Android builds at build time, removing the manual, error-prone steps that react-native link required.

• How it works:

  • The React Native CLI scans package.json dependencies for native configuration and wires them into Gradle (Android) and CocoaPods (iOS) during build.

  • Typically you just install the package and run pod install for iOS.

• What the old react-native link did: Mutated native project files (Podfile, settings.gradle, MainApplication.java) automatically, which often caused merge conflicts and broken builds.

• Benefits:

  • Less manual native editing, fewer version-specific errors, and easier upgrades.

  • You can still opt out per-package via react-native.config.js when custom linking is needed.

React Native offers runtime branching (Platform.OS/Platform.select) for small differences and platform-specific file extensions (.ios.js/.android.js) for larger divergences the bundler resolves at build time.

• Platform.select / Platform.OS:

  • Runtime check inside a single file: good for small tweaks (a style value, a prop, a constant).

  • Both platforms' code ships in the bundle, so keep branches small.

• .ios.js / .android.js extensions:

  • Metro picks the right file per platform at bundle time; you import without the extension.

  • Best when implementations differ substantially (different native APIs or whole components), keeping each file clean.

• Choosing between them: Use Platform.select for minor, localized differences; use file extensions when logic diverges enough that mixing would hurt readability.

On the Web the browser handles HTTP caching automatically; in React Native the built-in Image component has a weak, platform-inconsistent cache, so lists of remote images re-download and re-decode frequently, hurting performance and data usage.

• No browser cache layer:

  • The browser transparently respects Cache-Control/ETag headers; RN's native image loaders do this inconsistently across iOS and Android.

  • Result: flicker on re-render, duplicate downloads, and poor scroll performance in long lists.

• What react-native-fast-image adds:

  • Wraps native libraries (SDWebImage on iOS, Glide on Android) for aggressive memory + disk caching and better decode reuse.

  • Exposes cache-control priorities and cache policy props, reducing flicker and re-fetching.

• Trade-offs:

  • Adds a native dependency: extra bundle size and a rebuild (won't work in a bare-JS Expo Go flow without a dev build).

  • Less flexible styling than core Image (e.g. some border/tint behaviors differ).

  • Newer RN versions and libraries like expo-image now offer similar caching, narrowing its advantage.

Jank is dropped frames (missing the 16ms budget at 60fps), caused when either the JS thread or the native UI/render thread is blocked from delivering frames on time.

• Blocking the JS thread:

  • Heavy synchronous work (large JSON parsing, big loops, complex reducers) during animation or scroll.

  • Animations driven in JS instead of natively (use useNativeDriver or Reanimated).

• Excessive re-renders: Missing memoization causes whole subtrees to re-render; fix with React.memo, useMemo, useCallback.

• Inefficient lists: Rendering long lists without FlatList/FlashList virtualization, missing keyExtractor, or heavy item components.

• Bridge congestion: High-frequency messages across the (old) bridge (e.g. gesture/scroll events wired to JS) cause serialization backlog.

• Native/render thread load: Large image decodes, deep view hierarchies, heavy shadows, and overdraw stall the UI thread.

OTA tools ship a new JavaScript bundle (and assets) directly to installed apps, bypassing the stores: at launch the app checks a server for a newer compatible bundle, downloads it, and loads it on the next start.

• How it works:

  • The native binary embeds a JS runtime; OTA replaces only the JS bundle + assets, not native code.

  • Updates are keyed to a runtimeVersion (EAS) or binary version so a bundle only lands on compatible native builds.

  • Rollout, channels, and rollback let you target releases and revert a bad update quickly.

• What can be updated OTA:

  • JS logic, UI, styling, images and other bundled assets.

  • NOT native modules, permissions, or SDK upgrades that change the binary: those require a store build.

• Store policy limits:

  • Apple guideline 3.3.2 allows JS-over-the-air only if it doesn't change the app's primary purpose or introduce features inconsistent with what was reviewed.

  • You must not use OTA to bypass review with materially different functionality.

A Brownfield app is an existing native application into which you embed React Native screens or components, as opposed to a Greenfield app built entirely in React Native. It lets teams adopt RN incrementally, but the integration introduces real complexity.

• What it looks like: Native code (Swift/Kotlin) hosts a RCTRootView / ReactRootView that renders an RN component inside a native screen.

• Key challenges:

  1. Navigation coexistence: reconciling native navigation stacks with RN navigation so back gestures and transitions feel seamless.

  2. Build and dependency integration: wiring CocoaPods/Gradle, autolinking, and matching versions without breaking the existing build.

  3. Lifecycle and state bridging: passing data both ways and keeping native and JS state in sync via native modules/events.

  4. Bundle and startup cost: initializing the RN runtime adds memory and first-load latency inside an otherwise native app.

  5. Tooling friction: debugging, hot reload, and crash reporting span two ecosystems.

• Why do it anyway: Incremental migration and code sharing without a full rewrite; new features can ship cross-platform while the legacy app stays intact.

Choose React Native when you want to share one JavaScript/TypeScript codebase across iOS and Android with near-native UI and fast iteration, and when your team already knows the React ecosystem. Choose Flutter or pure native when their specific strengths outweigh that.

• Pick React Native when:

  • You need one codebase for both platforms and a shared team of JS/React developers.

  • Fast delivery matters: hot reload, large ecosystem, and optional OTA updates (CodePush/EAS).

  • The app is mostly standard UI, forms, and network I/O rather than heavy graphics or low-level device work.

• Prefer Flutter when:

  • You want pixel-perfect, highly custom UI with a single rendering engine (Skia/Impeller) and consistent look across platforms.

  • You value strong out-of-the-box performance for animation-heavy UIs and don't mind learning Dart.

• Prefer pure native (Swift/Kotlin) when:

  • You need maximum performance, latest-platform APIs day one, or heavy use of hardware (AR, camera, Bluetooth, ML).

  • The app is single-platform, or teams are already specialized natively.

• Decision drivers: Existing team skills, time-to-market, degree of UI customization, performance ceiling, and long-term maintenance cost.

react-native-web is a library that maps React Native's core components and APIs onto standard DOM elements and CSS, so the same component code that renders natively on mobile can render in a browser.

• It re-implements RN primitives for the web: Components like View, Text, and Image become div/span elements with the RN style semantics (flexbox defaults, etc.) applied.

• Enables code sharing through a shared component tree: You write against the RN API once; the bundler picks native modules on mobile and react-native-web on web (via a webpack/Metro alias).

• Platform-specific code still coexists: Use Platform.OS or .web.js/.native.js file extensions to branch where behavior must differ.

• Powers React Native for Web in frameworks: It's what Expo uses for web output, letting a single codebase target iOS, Android, and browser.

• Caveat: not everything maps cleanly: Native-only modules (camera, deep native APIs) need web equivalents or fallbacks, and DOM/SEO concerns don't exist natively.

Windowing means the list keeps only a moving window of rendered items around the visible area and unmounts (or replaces with blank space) everything else, so render cost stays roughly constant no matter how big the dataset is.

• How windowing works: As you scroll, items entering the window mount and items leaving it unmount, leaving a spacer of their measured height.

• initialNumToRender: How many items to render on first paint; keep it just enough to fill the screen for fast startup.

• windowSize:

  • Size of the render window measured in units of the visible screen (default 21, meaning ~10 screens above + visible + ~10 below).

  • Larger reduces blank flashes on fast scroll but uses more memory; smaller saves memory but risks blank cells.

• Related props: maxToRenderPerBatch and updateCellsBatchingPeriod tune how many items render per scroll batch and how often.

Deep linking maps an external URL to a specific screen and params inside your app. React Navigation handles this via a linking config that translates URLs into navigation state; the OS-level mechanism differs between custom URL schemes and Universal/App Links.

• How it works in React Navigation:

  • You give NavigationContainer a linking prop with prefixes and a config that maps URL paths to screen names and params.

  • When the OS delivers a URL (cold start or while running), React Navigation parses it and navigates to the matching screen.

• URL schemes (custom scheme):

  • Links like myapp://profile/42: simple to set up and work offline.

  • Downside: not verified, any app can claim a scheme, and a plain browser can't open them if the app isn't installed.

• Universal Links (iOS) / App Links (Android):

  • Use real https:// URLs tied to a domain you own, verified via an association file (apple-app-site-association / assetlinks.json).

  • Open the app if installed, otherwise gracefully fall back to the website, and can't be hijacked by other apps.

• When to use which: Custom schemes for internal/dev flows; Universal/App Links for user-facing shareable links where you want web fallback and security.

Expo Router adds a file-based layer on top of React Navigation: your folder structure in app/ defines the routes automatically, whereas classic React Navigation requires you to declare navigators and screens imperatively in code. Because routes map to URLs, deep linking and Universal Links work out of the box.

• Traditional React Navigation:

  • You build the tree by hand: createStackNavigator, <Stack.Screen>, and a manually written linking config to support URLs.

  • Full control, but more boilerplate and easy to drift between routes and their URL mappings.

• Expo Router (file-based):

  • A file at app/profile/[id].tsx automatically becomes the route /profile/:id.

  • Layout files (_layout.tsx) declare navigators for a folder; still React Navigation under the hood.

• Why first-class Universal Links matter:

  • Every screen has a canonical URL, so deep links and web routes come for free with no separate mapping to maintain.

  • Enables true universal apps: the same route tree renders on native and web.

  • Shareable, indexable links and consistent navigation state across platforms.

Persisting navigation state saves the current route tree (to storage) so the app restores the exact screen after a reload or restart, which is great for dev and some UX, but risky in production because saved state can point at screens that are stale, invalid, or off-limits.

• How it works: Use onStateChange to save state and initialState on NavigationContainer to restore it.

• Benefits:

  • Preserves position across Fast Refresh in development.

  • Can restore deep in-flow screens after the OS kills the app in the background.

• When it's problematic:

  • Auth expiry: restoring a logged-in screen after the token expired, or after logout, leaks or breaks the flow.

  • Stale params: a restored screen references a deleted or changed resource (orderId that no longer exists).

  • App updates: route names or param shapes changed, so old state no longer matches the navigator.

  • Sensitive/ephemeral screens: restoring a payment or one-time modal is undesirable.

• Mitigations: Version the persisted state and discard on mismatch; validate restored routes against auth before rendering; usually enable only in development.

A worklet is a small JavaScript function marked to run on the UI thread instead of the JS thread. Reanimated extracts it, ships it to a separate JS runtime running on the UI thread, and executes it there synchronously per frame, so the animation never waits on a congested JS thread.

• How a worklet is created:

  • Marked with the 'worklet' directive (the Reanimated Babel plugin usually adds it automatically for useAnimatedStyle, gesture handlers, etc.).

  • It captures a snapshot of the variables it uses, since it runs in a separate context.

• Why it runs off the JS thread:

  • There's a second JS runtime on the UI thread; worklets execute there each frame in sync with rendering.

  • So even if the main JS thread is blocked (heavy computation, list rendering), the animation keeps producing frames.

• Shared state: Communicates via shared values; use runOnJS() to call back into the JS thread and runOnUI() to invoke a worklet on the UI thread.

npx expo prebuild is Continuous Native Generation (CNG): it generates the native ios and android folders on demand from your app.json/app.config.js and config plugins, so native code is treated as a build artifact rather than something you hand-edit and commit.

• What it does:

  • Reads your app config (name, bundle id, permissions) and installed config plugins, then scaffolds/regenerates the native projects.

  • Config plugins programmatically apply native changes (Info.plist entries, Gradle settings, permissions) during prebuild.

• How it changes folder management:

  • You typically don't commit or manually edit ios/android; they can be regenerated any time and are often gitignored.

  • Native customization moves into config plugins so it survives regeneration, instead of being lost on the next prebuild.

• Why it matters:

  • Keeps a managed-like workflow while still allowing custom native code, and makes upgrades cleaner (regenerate rather than merge).

  • Trade-off: if you 'eject' to manually maintained native folders, re-running prebuild can overwrite hand edits, so prefer plugins.

Config Plugins are JavaScript functions that programmatically edit your native project files during prebuild, so you can change native config (permissions, entitlements, Info.plist, Gradle, etc.) without hand-editing or committing native folders.

• What they are:

  • Functions that receive and mutate the app config/native files, run by npx expo prebuild.

  • Declared in the plugins array of app.json.

• How they modify native code:

  • They use "mods": typed transformations of files like AndroidManifest.xml, Info.plist, or Gradle scripts.

  • Because native folders are regenerated each build, the plugin re-applies its edits every time (deterministic and repeatable).

• Why it matters:

  • You keep the config-driven workflow (no committed ios//android/) while still integrating libraries that need native setup.

  • Many libraries ship their own plugin; you can also write custom ones for one-off native tweaks.

A key-value cache is ideal for small, flat, unrelated pieces of state, while a real database (SQLite/WatermelonDB) is worth its complexity when you have large, relational, queryable datasets that must stay performant offline.

• Local cache (key-value):

  • Best for settings, tokens, flags, and small serialized blobs.

  • Pros: trivial API, fast, minimal setup. Cons: no querying, filtering, or relations; you load whole values.

• SQLite:

  • A full relational engine: indexes, joins, and SQL queries over large datasets.

  • Cost: schema/migration management and more boilerplate.

• WatermelonDB:

  • Built on SQLite but optimized for React Native: lazy loading and observables so lists update reactively without loading everything.

  • Designed for large, scaling apps with sync; adds a modeling/learning-curve overhead.

• Decision rule: Match the tool to data shape and volume: don't put thousands of relational rows in a cache, and don't add a database for a handful of settings.

An offline-first app treats the local database as the source of truth and the network as an eventual sync target, so the hard problems are queuing writes, replaying them reliably, and resolving conflicts when local and server state diverge.

• Local-first data layer: Reads and writes hit a local store (SQLite, WatermelonDB, MMKV) instantly; the UI never waits on the network.

• Queueing writes (outbox pattern):

  • Offline mutations are recorded in a durable queue with enough info to replay them later.

  • Use idempotency keys so retries don't create duplicates.

• Optimistic UI: Apply changes locally immediately and mark them pending; roll back if the server later rejects them.

• Sync on reconnect: When NetInfo reports online, flush the queue in order, then pull server changes (often via a delta/last-updated timestamp).

• Conflict resolution:

  • Decide a strategy: last-write-wins (simple, can lose data), server-wins, or merge by field/CRDT for collaborative data.

  • Track versions/timestamps per record so the server can detect concurrent edits.

• Edge cases: Partial failures mid-sync, app killed before flush completes, and clock skew all require the queue to be persistent and replay-safe.

Remote JS Debugging can change behavior because it runs your JavaScript in Chrome's V8 engine on your computer, not in the device's engine (Hermes), and communicates over the network. This swaps the runtime and adds latency, so timing, engine-specific APIs, and native-bridge behavior can differ, whereas the Hermes debugger attaches directly to the engine actually running your app.

• Different engine: Remote debugging executes in V8/Chrome, so bugs tied to Hermes (or JSC) internals, date/number/Intl differences, or unsupported features won't reproduce or behave the same.

• Network round-trips change timing:

  • Every call between JS and native crosses a WebSocket to your machine, so it's much slower; race conditions and timing bugs may appear or disappear.

  • Synchronous native methods can't work the same way over an async bridge.

• The modern alternative:

  • The Hermes debugger (via Flipper or React Native DevTools) attaches to the on-device engine, so you debug the real runtime with real timing.

  • Remote JS Debugging is being deprecated for this reason.

Error Boundaries in React Native work exactly like on the Web: they are React class components that catch JavaScript errors thrown during rendering in their child tree. They cannot catch native-side crashes because those happen outside the React/JS layer entirely.

• Same JS mechanism as Web:

  • A class component using static getDerivedStateFromError() and/or componentDidCatch() catches render/lifecycle errors in descendants.

  • There is no built-in hook equivalent yet, so you still write a class or use a library.

• What they do NOT catch (same limits as Web): Errors in event handlers, async code (setTimeout, promises), and errors thrown in the boundary itself.

• Native crashes are out of reach:

  • A crash in Objective-C/Swift/Kotlin/Java or C++ (a native module, the renderer) terminates the app process; JS never gets a chance to run.

  • These need native crash reporters (Crashlytics, Sentry native SDK).

• Practical fallback: In dev, an uncaught JS error shows the redbox; in production it can white-screen or crash, so wrap your app in a top-level boundary to show recovery UI.