React Native Developer interview questions

I keep composition at the app layer, user flows in feature modules, business rules in domain code, and I/O behind data adapters.

• The app layer owns providers, navigation, startup, and environment wiring, but no feature rules.
• Each feature exposes screens and use cases through one public entry point instead of exporting its internals.
• Domain functions use plain TypeScript and know nothing about React Native, HTTP, SQLite, or TanStack Query.
• Data adapters map API and database records into domain types, which makes transport changes local.

I place state according to ownership: remote prices in a server-state cache, the cross-session preference in a small client store, and step-local fields near the form.

• TanStack Query owns prices, loading, errors, freshness, and refetching because the server remains authoritative.
• Zustand or Redux can persist the delivery preference when several screens need it across launches.
• The draft stays in a form controller or flow-scoped context and is discarded when checkout completes.
• I avoid copying query results into a global store because two writable copies drift during refetches.

I would keep the controlled TextInput value urgent and mark only the 5,000-row result update as non-urgent.

• With one query state, useDeferredValue(query) lets the input commit immediately while the list renders from deferredQuery and can show that its results are stale.
• If the input handler owns a separate filterQuery, I call setQuery(text) normally and wrap only setFilterQuery(text) in startTransition; the controlled input value must not be transitioned.
• I virtualize the result rows with FlatList or FlashList, and I split or move the 120 ms filter if it is one monolithic JavaScript task because a transition does not make that task cheap or interruptible.
• On a mid-range device in a release build, I measure key-to-paint p95, JavaScript stalls, result latency, and rendered rows against the 120 ms baseline.

I use key-value storage for small preferences, SQLite for the 10,000 queryable records, and Keychain or Keystore-backed storage for the token.

• MMKV gives fast synchronous reads for small hot values, but large synchronous serialization can still block the JS thread.
• AsyncStorage is adequate for non-sensitive JSON that is read asynchronously and does not need relational queries.
• SQLite supports indexes, transactions, pagination, and partial updates, which the offline record set needs.
• Tokens do not belong in MMKV or AsyncStorage because neither is a credential vault by default.

I make the local database the UI source of truth and synchronize an explicit mutation outbox with the server.

• Every local edit and its outbox record commit in one SQLite transaction so a process kill cannot separate them.
• Sync uses stable client IDs, idempotency keys, a server cursor, and tombstones so retries and deletions are safe.
• Records carry server versions or update timestamps, and the product defines field-level merge or last-writer behavior for conflicts.
• The UI shows pending and conflicted states instead of pretending that an offline write is already confirmed remotely.

I use hierarchical keys whose complete filter object represents the exact server result.

• A detail key can be orders, accountId, detail, orderId, while a list key includes accountId and a normalized filters object.
• Stable primitives and sorted filter values prevent semantically identical requests from creating separate cache entries.
• After an order mutation I update its detail entry and invalidate only affected lists for that account, not the entire cache.
• I set staleTime from product tolerance, such as 30 seconds for active orders, and treat gcTime only as memory retention.

I snapshot the affected cache, apply one deterministic optimistic patch, and keep a rollback path tied to that mutation.

• In onMutate I cancel matching refetches first so an older response cannot overwrite the optimistic value.
• I patch the item in every visible page by stable ID and return the previous values as rollback context.
• On error I restore that context and show an error with a Retry action; concurrent likes need mutation IDs or commutative count logic.
• On settlement I invalidate the narrow feed and detail keys so the server result resolves any divergence.

I organize by product capability and give every feature a small public API.

• A payments module can own its screens, hooks, queries, tests, and local components under one directory.
• Other features import only payments/index exports, so internal file moves do not create repository-wide changes.
• Truly generic primitives go to shared UI, while business components stay with the feature that defines their rules.
• Cross-feature flows are composed in the app or navigation layer rather than making two features import each other.

I normalize failures at both boundaries into one discriminated union before feature code sees them.

• The REST adapter maps network failures and HTTP statuses, while the TurboModule adapter maps stable native codes; neither the UI nor the adapters parse platform message text.
• Each variant carries kind, code, retryable, and safe context: timeouts and selected 5xx responses may be retryable, while validation, unsupported capability, and denied authorization are permanent until input or state changes.
• Sentry receives the normalized kind and code plus the original cause chain, release, and boundary, with no PII, tokens, request bodies, or file contents.
• An exhaustive switch with assertNever renders Retry only for retryable variants and specific actions such as Sign in or Open settings for permanent ones.

I generate transport types from the API schema, validate responses at runtime, and map them into stable domain models.

• OpenAPI or GraphQL generation removes handwritten duplication but does not validate bytes received at runtime.
• Zod or another schema validator rejects malformed required fields at the network boundary with a reportable error.
• Version-specific DTO mappers absorb renamed or nullable fields so screens consume one domain shape.
• Discriminated unions model success and known error variants, forcing callers to handle every supported case.

The legacy bridge serialized batched asynchronous messages, while the New Architecture uses JSI-based typed interfaces and removes that JSON bridge bottleneck.

• Legacy calls crossed queues through serialized payloads, so chatty APIs paid copying and scheduling costs.
• TurboModules expose generated contracts through JSI and can be loaded lazily instead of registering every module at startup.
• Fabric uses the same architectural direction for rendering and supports tighter coordination with React's concurrent renderer.
• I still design coarse native APIs because direct access does not make 20 unnecessary boundary crossings free.

I would pass a file URI to an asynchronous TurboModule or Expo Module and process it on a bounded native worker queue.

• The JavaScript call sends the URI and small options, not a 5 MB base64 string or number array, and receives metadata or a temporary output URI.
• A promise returns the single result, typed progress events are optional, and a job ID with cancel(jobId) lets the user stop the work.
• Screen unmount or React Native runtime invalidation cancels the job, the worker checks cancellation, deletes temporary files, and schedules completion through the module boundary rather than touching UI from its thread.
• I measure duration, copies, peak RSS, and JavaScript responsiveness in release first, and add a custom JSI buffer or HostObject only if profiling proves the module boundary is the bottleneck.

Fabric represents the tree in C++ and lets React prepare and prioritize render work before an atomic native mount.

• React can build immutable shadow-tree revisions and interrupt lower-priority render work under concurrent rendering.
• Layout and reconciliation no longer depend on the old serialized bridge protocol.
• The commit produces a consistent tree revision rather than exposing a half-applied set of updates.
• Actual UIKit or Android View mutations still obey platform main-thread rules, so Fabric does not erase the 16.7 ms frame budget.

I expose small typed TurboModule contracts and let the registry create each implementation only when its feature first asks for it.

• Each module groups a cohesive capability, such as biometrics or document scanning, instead of mirroring every native class.
• Codegen produces the platform interfaces, which keeps iOS, Android, and TypeScript signatures aligned.
• Expensive SDK setup happens lazily or in an explicit initialize method rather than in module construction.
• A JavaScript facade owns fallback behavior and makes unsupported platform capabilities explicit.

I make the TypeScript spec the narrow source of truth and stay within Codegen-supported, unambiguous types.

• The interface extends TurboModule and is obtained through TurboModuleRegistry, with required and optional methods represented deliberately.
• Structured records, nullable values, promises, callbacks, and typed events are declared explicitly instead of using any or class instances.
• Platform implementations inherit or conform to generated specs, so a missing method fails during the native build.
• CI runs Codegen and both platform compilers whenever the spec changes, catching drift before application tests.

Only the bounded sub-millisecond read is a possible synchronous method, while the 2-second operation must return a promise or event-driven result.

• A synchronous call blocks the JS runtime, so it must not wait on disk, network, locks, permissions, or the main thread.
• A promise maps one eventual result or error cleanly and keeps the JS event loop available.
• Long streams or repeated progress updates use typed events rather than a promise that tries to report many values.
• Native errors cross as stable codes and metadata, not platform exception text that JavaScript must parse.

I expose one typed event stream with explicit subscription lifetime and throttle or batch data before it reaches JavaScript.

• The native observer starts when the first listener subscribes and stops when the last subscription is removed.
• Each event includes a timestamp and sequence number so consumers can detect stale or skipped updates.
• The module coalesces updates to the UI's actual need, such as 2 per second, instead of forwarding all 10.
• Screen cleanup removes the subscription, and tests verify that remounting 20 times still leaves one native observer.

I tie the SDK resource to the native module or application lifecycle, not to each React screen mount.

• Lazy module initialization creates the SDK once for the active React Native runtime and makes repeated setup idempotent.
• The invalidation or teardown hook removes observers, closes resources, and releases callbacks when that runtime is destroyed.
• Kotlin code does not retain an Activity because Android can replace it; it uses application context and requests the current Activity only when required.
• Swift dispatches UIKit access to the main queue and keeps callback references weak where a cycle is possible.

I run the 80 ms computation on a native worker queue and schedule only UI changes and the final callback onto their required threads.

• UIKit and Android View mutations stay on the main thread, whose frame budget is about 16.7 ms at 60 Hz.
• CPU-heavy decoding or transformation uses a bounded worker pool so it cannot create unbounded concurrent jobs.
• Completion enters JavaScript through the React Native scheduler rather than invoking a JSI runtime from the worker directly.
• Cancellation and request IDs prevent a late result from updating a screen that has already unmounted.

I use a config plugin to apply deterministic native project changes and a development build that actually contains the BLE native code.

• Expo Go cannot load an arbitrary custom native module because its native binary is already fixed.
• The plugin modifies Info.plist, AndroidManifest, Gradle, or entitlements during prebuild without requiring manual edits after every regeneration.
• A local or EAS development build supplies the custom runtime while preserving Expo tooling and the developer menu.
• Any native dependency or plugin change requires a new binary; an OTA JavaScript update cannot add the BLE SDK.