标签：#reactnative

Welcome to the fifth article in our OWASP Mobile Top 10 2024 series! In previous articles we covered M1: Improper Credential Usage, M2: Inadequate Supply Chain Security, M3: Insecure Authentication/Authorization, and M4: Insufficient Input/Output Validation. Today we discuss why "we already use HTTPS" isn't a sufficient answer. Introduction M5 is the most misleading item on the list, because most teams read it and move on: "We use HTTPS, this doesn't apply to us." OWASP's definition is far broader. This risk covers all aspects of getting data from point A to point B, but doing it insecurely. It encompasses mobile-to-mobile communications, app-to-server communications, or mobile-to-something-else communications. It includes all communications technologies that a mobile device might use: TCP/IP, WiFi, Bluetooth/Bluetooth-LE, NFC, audio, infrared, GSM, 3G, SMS, etc. So M5 isn't just "do you use HTTPS." It's all of this: Whether you set up TLS correctly (certificate checking, cipher selection) Whether your traffic is consistent (some endpoints HTTPS, others not) What your third-party SDKs are doing What your WebView is loading What you send over alternate channels like push notifications and SMS 💡 Key point: Just because an app uses transport security protocols doesn't mean it's implemented correctly. HTTPS is not a checkbox; it's a system that must be configured properly. A specific situation for React Native developers In React Native the network layer lives in three separate places, and most developers only think about the first: The JavaScript side — fetch , axios , XMLHttpRequest Platform configuration — ATS on iOS, Network Security Config on Android Native modules and SDKs — analytics, ads, crash reporting, payment SDKs Whatever you do on the JavaScript side, if platform configuration is loose or a third-party SDK uses plaintext HTTP, your app is exposed. OWASP Assessment Metric Value Meaning Exploitability EASY A proxy and the same network is enough Prevalence CO

By Shivkrishna Shah · Engineer Philosophy — @shivkrishnashah · @engineerphilosophy Your app shouldn't have a "no internet" screen. Here's the architecture I use to make mobile apps write locally, sync automatically, and survive the messy reality of field connectivity. Every mobile developer has shipped this screen at least once: a sad cloud icon and the words "No internet connection. Please try again." For consumer apps, that's an annoyance. For enterprise field apps — sales reps in hospital basements, auditors in warehouses, technicians in rural areas — it's a dealbreaker. If the app stops working when the signal drops, people stop trusting it. And once field users stop trusting an app, they go back to paper and WhatsApp. I spent the last few years building and maintaining an offline-first React Native platform used daily by field teams across multiple countries. This post is the architecture I wish someone had handed me on day one: how to structure local storage, detect connectivity, queue writes, auto-sync in the background, and avoid the two bugs that will absolutely bite you (duplicates and conflicts). Everything here is generic — I'll use Realm DB and NetInfo in the examples, but the pattern maps cleanly onto WatermelonDB, SQLite, or MMKV-backed queues. The one rule that changes everything The local database is the source of truth. The server is just a replica you happen to reconcile with. Most apps are built the other way around: the server is the truth, and the app is a thin cache over fetch() . Offline-first inverts this. Every read comes from the local DB. Every write goes to the local DB first. The network is an implementation detail that a background service worries about — never the UI. This single inversion gives you three things for free: Zero-latency UX. Saves are instant because they're local writes. No spinners on submit. Airplane-mode parity. The app behaves identically online and offline, because the UI never talks to the network. Crash safety. D

Part 1 covered the mechanism: a fingerprint gate decides whether a change ships in minutes over-the-air or needs a full store release. But a gate that only checks "is this native-safe" says nothing about whether the change is good . If every merge to main can reach production within minutes, your safety net can't be a release train that gives everyone time to notice a problem before it ships — it has to be built into the pipeline itself, because there's no train to catch it on the way out. The PR gate Every pull request into main runs through the same automated gate before it's mergeable: a type check, a lint pass, an automated test suite, and end-to-end checks against a real device build. None of that is negotiable — it's the floor, not a nice-to-have. E2E is a big enough topic on its own — closing the loop between what a unit test can see and what actually happens on a phone in someone's hand — that it deserves its own dedicated post rather than a paragraph here. jobs : typecheck : run : npm run typecheck lint : run : npm run lint test : run : npm test e2e : run : npm run e2e Nothing exotic under the hood — ESLint for the lint pass, Husky for local pre-commit/pre-push hooks so the same checks catch you before CI even runs, Jest as the test runner, and React Native Testing Library for component-level tests. Popular, boring, well-documented tooling on purpose — the pipeline's value is in how these are wired together and gated, not in any one tool being clever. Feature flags are the real safety valve Here's the entry condition that makes OTA-from- main safe at all: shipping code and releasing a feature are two different actions. A merge can put new code on every user's device within minutes — that's deploy. Whether that code actually does anything visible is a separate switch, controlled by a remote feature flag, not by whether the code merged. That decoupling is what makes trunk-based development survivable. Nobody has to get the timing of a merge exactly right, bec

I am a full-stack developer in the Netherlands, a bit over ten years in. For the last year my evenings have gone into one side project: I Like Movies, an Android app for tracking what you watch and deciding what to watch next. It went live on Google Play this summer. This is the honest version of how it got built, what the stack looks like, and the three or four decisions that mattered more than the rest. The problem was never finding a film Every movie app I tried was built for one person keeping one list. My actual problem was two people on one sofa, each with a watchlist, neither remembering which of us had saved the film worth watching. Picking something to watch with someone else is genuinely harder than picking alone, and no amount of better search fixes it, because search is not the bottleneck. Deciding is. So the app is organised around that. A household shares one library: one watchlist, one watched history, visible to everyone who lives with you. Add a film on your phone in the supermarket and it is on your partner's phone before you are home. That one feature is why the app exists, and it shaped almost every backend decision that followed. The stack, and why it is boring on purpose The backend is Go, GraphQL via gqlgen, and Postgres. The app is React Native with Expo. Film and TV metadata comes from TMDB. That is close to the most conservative stack you could pick in 2026, and that is the point. A solo project dies when the maintenance load exceeds one person's evenings, so every technology had to be something I could debug at 11pm without a second opinion. Go earned its place. The whole backend is one binary with no framework magic, and the type system plus gqlgen's generated resolvers mean a schema change breaks loudly at compile time instead of quietly in production. Postgres does everything: data, full-text search support, import staging. No microservices, no queue, no Redis. A single process and a single database will carry a consumer app much furthe

A team-lead's breakdown of 8 real React Native project architectures — what each one actually solves, where the "Domain-Driven" and "Micro-Frontend" labels get misused, and how to pick one without over-engineering an MVP. The house-building analogy When you build a house, the labor that lays the bricks gets paid well. The architect who drew the blueprint gets paid more — because the architect already accounted for the second floor you'll add next year, and made sure the foundation could take the load without anyone tearing down a wall later. React Native codebases work the same way. The folder structure you pick on day one either lets your app absorb 10 more features and 40 more engineers, or it collapses under its own weight and someone gets hired specifically to rewrite it. This is also, almost word for word, what a React Native team lead interview is probing for: "Walk me through how you'd structure a project" or "What's your folder structure and why?" Nobody wants your code in that answer — they want to hear you reason about trade-offs. So here are eight real folder structures, what each one actually solves, and two places where the common naming gets sloppy. 1. Flat Structure — for prototypes and MVPs src/ ├── App.js ├── HomeScreen.js ├── ProfileScreen.js ├── Button.js ├── Card.js └── api.js Everything in one src/ folder, no categorization. When to use it: a client demo, a hackathon build, a single-screen proof of concept — anything with a short shelf life, or code you expect a bigger team to re-architect later. Where it breaks: past 10–15 files you're scrolling through an undifferentiated pile with no signal about what belongs together. 2. Feature-Based Structure — the industry default src/ └── features/ ├── auth/ │ ├── components/ │ ├── screens/ │ └── services/ ├── profile/ │ ├── components/ │ ├── screens/ │ └── services/ └── feed/ ├── components/ ├── screens/ └── services/ This is the most common structure in production RN apps. Each product area — auth, pro

App Review rejected my iOS app under Guideline 2.1. The note said reviewers were unable to locate the App Tracking Transparency permission request when they tested the build. The prompt worked on my iPhone. Every single launch. It just didn't work on theirs. The cause turned out to be two properties of the ATT API that are easy to miss individually and genuinely nasty in combination: together they produce a bug that is invisible on a fast device and completely reproducible on a slow one. Your test device is fast. The reviewer's device is not necessarily. This post is the root cause, the fix I shipped, and the list of other things that silently suppress the prompt. The two facts that explain everything 1. iOS only presents the ATT prompt while your app is active Apple's documentation for requestTrackingAuthorization(completionHandler:) states, for iOS 15 and later: "Calls to the API only prompt when the application state is UIApplicationStateActive." That's UIApplication.State.active — not merely "in the foreground," and not "the code is running." During launch there is a window where your JS/UI is already executing but the app is still inactive : splash screen dismissal, the first render, a modal transition animating in or out. Call the API in that window and iOS declines to present. 2. When iOS declines to present, you don't get an error You get notDetermined back ( undetermined in expo-tracking-transparency ) — which is the exact same value you get when the user simply hasn't answered yet. There is no "I couldn't show it" signal. There is no thrown error. There is no presented: false flag. From the return value alone, "the user hasn't decided yet" and "iOS silently no-op'd your request" are indistinguishable. That's the trap. The API looks like it succeeded. The bug I shipped Reduced to its essentials: // Called during startup, while the splash screen was still going away. const { status } = await requestTrackingPermissionsAsync (); const granted = status === ' gr

If you're testing an iOS build with real devices, you've got two main paths: Apple's TestFlight, or Expo's EAS Preview using Ad-Hoc provisioning. They solve the same problem — getting a build onto a real iPhone without the App Store — but the workflows are genuinely different, not just cosmetically. How each one works TestFlight uses Apple's official infrastructure. You upload your build to App Store Connect (often via npx testflight to speed this up), Apple processes/reviews it, and testers install the TestFlight app and accept an email or public link invite. No UDID collection needed — Apple handles device registration behind the scenes. Expo EAS Preview (Ad-Hoc) uses Ad-Hoc provisioning. You register each tester's device UDID against your Apple Developer account before building — either manually (eas device:create, eas device:list) or by having the tester scan a QR code that installs a temporary profile. Once devices are tied to your provisioning profile, you build with: bash eas build --platform ios --profile preview This generates a direct install link/QR code — no App Store account or TestFlight app required. Comparison table Feature Expo Preview / Ad-Hoc Apple TestFlight Device limit ~100 devices/device class/year (Apple Developer account tier) Up to 10,000 external testers Processing time Immediate after cloud build finishes Apple review/processing (mins to hours) UDID management Manual or profile-based registration required Not required, handled by Apple Best for Fast internal testing, client demos, strict ad-hoc distribution Larger-scale beta testing, staging before production Which one should you use? Fast internal iteration, client demos, small teams → Ad-Hoc. No waiting on Apple, instant install links. Wider beta testing before a production release → TestFlight. Built-in scale, no manual device management. Most teams I've worked with end up using both at different stages: Ad-Hoc during active development for quick feedback loops, TestFlight once the bui

A navigation map should help the user move through the world, not fight every gesture they make. I recently hit a deceptively simple bug while building field guidance in a React Native / Expo app: the route rendered correctly and the camera followed the current position, but users could not meaningfully zoom or pan while walking. They could pinch the map, but the next location update snapped the camera back to a fixed zoom. The map looked active. The experience felt broken. The cause: two camera owners The implementation combined two useful features: followsUserLocation={true} on the native map. animateCamera(...) after every location update, using a fixed walking zoom and pitch. Each feature was reasonable on its own. Together, they gave the camera two automatic owners and the user none. A pinch gesture changed the zoom for a fraction of a second. Then a GPS update arrived and our effect applied the navigation camera again. On iOS, native user-follow behavior added another layer of camera control. A better model: follow mode and explore mode The fix was not to stop navigation. Route progress, distance, bearing, breadcrumb recording and off-route detection should all continue regardless of what the user does with the map. Only the camera behavior should change. We now keep a small piece of local UI state: const [ cameraFollowing , setCameraFollowing ] = useState ( navigationActive ); useEffect (() => { if ( ! navigationActive || ! cameraFollowing || bearing == null ) return ; mapRef . current ?. animateCamera ( walkingCamera ( currentCoordinate , bearing ), { duration : 480 }, ); }, [ currentCoordinate , bearing , navigationActive , cameraFollowing ]); The native follow prop uses the same state: < MapView showsUserLocation followsUserLocation = { navigationActive && cameraFollowing } onTouchStart = { () => { if ( navigationActive ) setCameraFollowing ( false ); } } /> As soon as the user touches the map, the camera enters explore mode. Pinch, pan and rotation work n

This article is an English translation of the original Japanese article. In my club management app, I use the following invite URL for both web and iOS app: https://squad-note.com/invite/{orgId} If the app is installed, Expo Router opens the invite screen in the app. If not, the web page displays. Using Universal Links lets me share a single URL rather than splitting it into web and app versions. Expo Router File Structure I place the invite screen as a dynamic route. apps/mobile/src/app/invite/[orgId]/index.tsx The screen retrieves the orgId from the URL via useLocalSearchParams . import { useLocalSearchParams , useRouter } from " expo-router " ; export default function InviteScreen () { const { orgId } = useLocalSearchParams < { orgId : string } > (); const router = useRouter (); const { data : org , isLoading } = api . organization . getPublic . useQuery ( { id : orgId ! }, { enabled : !! orgId }, ); // Display invite content and execute join process } When opened with /invite/abc , orgId receives abc . I also provide a page with the same path on the web side. Setting a Custom Scheme To handle app-specific URLs, I set a scheme in the Expo config. export default ({ config }: ConfigContext ): ExpoConfig => ({ ... config , scheme : " squadnote " , }); This allows handling URLs like the following during development and authentication callbacks: squadnote://invite/abc However, I use HTTPS for the invite URLs shared with users. Because custom schemes can be declared by different apps with the same scheme, I use Universal Links as the entry point to securely associate normal web URLs with the app. iOS Associated Domains In app.config.ts , I separate domains for production and development. ios : { bundleIdentifier : IS_PROD ? " com.squadnote.app " : " com.squadnote.app.dev " , associatedDomains : IS_PROD ? [ " applinks:squad-note.com " ] : [ " applinks:dev.squad-note.com " ], } Adding the configuration alone does not make it work. I also serve apple-app-site-association

This is an English translation of my original article on Qiita . An Android build failed in an Expo SDK 54 app. The project still used Expo SDK 54, but several Expo packages had been upgraded to versions intended for SDK 55. TypeScript checks passed, and the development server ran normally. I did not catch the mismatch until EAS Build reached the native build step. What the dependency list looked like The relevant part of package.json looked like this: { "dependencies" : { "expo" : "~54.0.33" , "expo-apple-authentication" : "~55.0.13" , "expo-dev-client" : "^55.0.27" , "expo-image-picker" : "^55.0.18" , "expo-linking" : "^55.0.12" , "expo-notifications" : "^55.0.19" , "expo-splash-screen" : "^55.0.18" } } The expo package was still on version 54, while several related packages were on version 55. This happened because those packages had been installed individually using their latest versions. The package version does not always match the Expo SDK number. For example, Expo SDK 54 uses expo-notifications 0.32 and expo-splash-screen 31. Looking only at major version numbers is not enough to determine SDK compatibility. Start with expo install --check Expo CLI can compare the installed packages with the versions expected by the current SDK: npx expo install --check It can also return the result as JSON: npx expo install --check --json This is more reliable than trying to infer compatibility from package.json manually. Expo CLI can fix the versions automatically: npx expo install --fix npx expo-doctor I wanted to review each change, so I used the reported versions to update package.json myself. The versions I changed These were the main corrections: - "expo-apple-authentication": "~55.0.13" + "expo-apple-authentication": "~8.0.8" - "expo-dev-client": "^55.0.27" + "expo-dev-client": "~6.0.21" - "expo-image-picker": "^55.0.18" + "expo-image-picker": "~17.0.11" - "expo-linking": "^55.0.12" + "expo-linking": "~8.0.12" - "expo-notifications": "^55.0.19" + "expo-notifications"

Over the past few weeks, I've been focused on deepening my understanding of mobile analytics—not just by completing a course, but by putting those concepts into practice through hands-on implementation in React Native. Throughout this journey, I explored a wide range of topics, including: Firebase Analytics integration Google Analytics 4 (GA4) Event planning and naming conventions Screen view tracking Custom events and custom definitions Key Events (Conversions) User properties and User ID Acquisition and campaign tracking Audience segmentation Ecommerce measurement Checkout funnel analysis Promotions and marketing attribution BigQuery integration Realtime reporting and DebugView Analytics validation and best practices One of the biggest lessons I learned is that analytics is much more than logging events . A well-designed analytics strategy helps answer important questions about user behavior, feature adoption, user engagement, and conversion optimization. The quality of the insights you gain depends on having a well-planned event architecture, consistent naming conventions, and meaningful data collection from the very beginning. Completing this Udemy course gave me a strong foundation in Firebase Analytics and Google Analytics 4. Reinforcing that knowledge through hands-on implementation in React Native helped me better understand event planning, debugging, reporting, and analytics best practices for modern mobile applications. Course Certificate I'm happy to have successfully completed the Firebase Analytics & Google Analytics 4 (GA4) course on Udemy. Certificate: https://www.udemy.com/certificate/UC-4a23b92f-0857-4a75-83dd-ac186bdfdfbc The course covered both the fundamentals and advanced capabilities of mobile analytics, including GA4 reports, custom events, screen tracking, audiences, BigQuery integration, and data-driven decision making. It has been a valuable learning experience that strengthened both my theoretical understanding and practical implementation

If you ship a React Native / Expo app to the App Store, you know the ritual. Open the Apple Developer portal, create a bundle identifier, tick the capability checkboxes, generate a provisioning profile, pick the right certificate. Then hop over to the Expo dashboard, create the EAS app, wire up credentials, add your environment variables one screen at a time. It works, until you have to do it again for a second app, or a second environment, or a teammate needs to know why a capability is enabled. None of it is written down. It drifts. And the usual mobile tooling doesn't help much here: fastlane and the EAS CLI are great, but they're imperative — scripts that do things — not a declarative description of what your release setup should be . That's the gap these two providers fill: elevenode/appstore — App Store Connect: bundle identifiers, provisioning profiles, certificates. elevenode/expo — Expo Application Services (EAS): apps, credentials, environment variables, update channels. Both are open source (Apache 2.0) and published on the Terraform Registry. Let's use them together to describe a mobile app's release setup as code. What you'll need Terraform (or OpenTofu) An App Store Connect API key (Users and Access → Integrations → App Store Connect API): the key, its key ID, and your issuer ID An Expo access token (expo.dev → account settings → Access Tokens) and your Expo account name Export the credentials as environment variables so nothing sensitive lands in your config: export APPSTORE_KEY = " $( cat AuthKey_XXXX.p8 ) " export APPSTORE_KEY_ID = "XXXXXXXXXX" export APPSTORE_KEY_ISSUER_ID = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" export EXPO_TOKEN = "your-expo-access-token" export EXPO_ACCOUNT_NAME = "your-account-name" Wiring up both providers terraform { required_providers { appstore = { source = "elevenode/appstore" } expo = { source = "elevenode/expo" } } } # Reads APPSTORE_KEY / APPSTORE_KEY_ID / APPSTORE_KEY_ISSUER_ID from the env. provider "appstore" {} # Re

If you've been developing with React Native or Expo for a while, chances are you've had a project that suddenly refuses to build for what seems like no reason. Maybe you installed a new package. Maybe you upgraded Expo. Maybe you only changed a single dependency. You confidently run your Android build, expecting it to compile like always... Instead, Gradle greets you with something like this: Execution failed for task ':app:checkDebugDuplicateClasses'. Duplicate class androidx.lifecycle.ViewModelLazy found in modules lifecycle-viewmodel-2.8.2.aar and lifecycle-viewmodel-ktx-2.6.1.aar Duplicate class com.google.android.gms.internal.measurement.zzab found in modules play-services-measurement-base-22.0.0.aar and play-services-measurement-impl-21.6.2.aar Duplicate class ... At first glance, the error looks straightforward: there are duplicate classes . Easy enough, right? Not exactly. In reality, this is one of those Android build errors that can send you down a rabbit hole of Gradle files, dependency trees and Stack Overflow threads, only to realize the real cause was something completely different. Let's break down what's actually happening and, more importantly, how to fix it. Why this error happens Every Android library included in your project contains compiled Java or Kotlin classes. When Gradle builds your application, it combines all of those libraries into a single APK or AAB. If two different dependencies contain the exact same class, Gradle doesn't know which version should be packaged. Instead of guessing, it stops the build with a Duplicate class error. The difficult part is that the dependency causing the conflict usually isn't the one shown in the error. Very often, it's another package pulling in an older or incompatible version behind the scenes. The most common causes After seeing this error many times, these are usually the culprits. 1. Two libraries depend on different versions of the same package This is by far the most common scenario. For example:

Liquid syntax error: Variable '{{% raw %}' was not properly terminated with regexp: /\}\}/

How I Built a Block Puzzle Game with React Native and Expo A few weeks ago, I launched my first mobile game — a block puzzle called Blockbeam. It's an 8x8 grid where you drag colorful blocks, fill rows and columns, and chase high scores. Simple concept, but building it taught me a lot about React Native's capabilities beyond typical CRUD apps. Here's what I learned. Why React Native for Games? Most mobile games are built with Unity or native code. But for a 2D puzzle game, React Native is surprisingly capable. The game doesn't need 60fps 3D rendering — it needs gesture handling, state management, and smooth animations. React Native handles all three well. The key stack: Expo SDK 54 — managed workflow, over-the-air updates, zero native config react-native-reanimated — 60fps drag animations react-native-gesture-handler — PanResponder for drag-and-drop react-native-svg — block rendering AsyncStorage — game state persistence The Puzzle Engine The core of any block puzzle is the board state. I used a flat 64-element array for the 8x8 grid: const BOARD = 8 ; const CELLS = BOARD * BOARD ; // 64 type Board = number []; // 0 = empty, 1-7 = block colors Piece placement is straightforward: check if all target cells are empty, fill them, then scan for complete rows and columns to clear. The interesting part was the "greedy solver" I built for the auto-play bot. It tries every piece in every position and picks the move that clears the most lines: for ( const piece of tray ) { for ( let r = 0 ; r <= BOARD - piece . h ; r ++ ) { for ( let c = 0 ; c <= BOARD - piece . w ; c ++ ) { if ( ! canPlace ( board , piece , r , c )) continue ; const score = simulateClear ( board , piece , r , c ); if ( score > bestScore ) { /* pick this move */ } } } } Drag and Drop with PanResponder The trickiest part was the drag mechanic. Each tray piece has a PanResponder that tracks touch position and renders a floating ghost. On release, it calculates the nearest cell position: const anchor = { col : M

This is Part 8 of 10 , a bonus practice article with 70 code-output challenges . Each challenge asks you to predict the result before revealing the answer and reasoning. Complete series This Dev.to series has five core handbook articles plus five focused practice extras. Open the series page to move through the complete reading order: Part 1: JavaScript — core handbook, questions 1–120 Part 2: React — core handbook, questions 121–220 Part 3: React Native — core handbook, questions 221–420 Part 4: Performance & Architecture — core handbook, questions 421–560 Part 5: Senior & System Design — core handbook, questions 561–719 Part 6: Output-Based JavaScript Practice — bonus practice article Part 7: Coding Interview Practice — bonus practice article Part 8: Code Output Challenges — bonus practice article Part 9: Current React Native Interview Questions — new high-frequency practice article Part 10: Project & Production Interviews — senior project ownership and real-production practice How to use this challenge set Read the code, state the exact output or error, then explain the language rule. Do not run the snippet until you have committed to an answer. For React Native interviews, connect the JavaScript behavior to rendering, state updates, list handling, or the JavaScript thread when relevant. Skills tested Hoisting, scope, closures, and this Arrays, conditions, references, object behavior, and loose versus strict equality Promises, timers, async / await , and microtasks Common JavaScript patterns used in React and React Native interviews Code output challenges Challenge 1. Block-scoped counter Predict the exact output before opening the answer. let total = 0 ; for ( let i = 0 ; i < 3 ; i ++ ) { total += i ; } console . log ( total ); Answer and explanation Expected output: 3 Why: The loop adds 0, 1, and 2. Challenge 2. var callback loop Predict the exact output before opening the answer. for ( var i = 0 ; i < 3 ; i ++ ) { setTimeout (() => { console . log ( i ); }, 0

This is Part 7 of 10 , a bonus practice article containing 75 coding interview questions drawn from the React Native Interview Handbook. It covers the implementation tasks commonly used in JavaScript and React Native rounds, from string and array problems to hooks, FlatList , asynchronous work, caching, retries, and native modules. Complete series This Dev.to series has five core handbook articles plus five focused practice extras. Open the series page to move through the complete reading order: Part 1: JavaScript — core handbook, questions 1–120 Part 2: React — core handbook, questions 121–220 Part 3: React Native — core handbook, questions 221–420 Part 4: Performance & Architecture — core handbook, questions 421–560 Part 5: Senior & System Design — core handbook, questions 561–719 Part 6: Output-Based JavaScript Practice — bonus practice article Part 7: Coding Interview Practice — bonus practice article Part 8: Code Output Challenges — bonus practice article Part 9: Current React Native Interview Questions — new high-frequency practice article Part 10: Project & Production Interviews — senior project ownership and real-production practice How to answer coding questions Before coding, clarify inputs, output, edge cases, platform constraints, time complexity, space complexity, cancellation, and test coverage. Start with a correct readable solution, then optimize only when the constraint justifies it. Topics covered Strings, arrays, maps, sets, recursion, and algorithmic complexity Debounce, throttle, memoization, deep cloning, and polyfills Custom hooks, API state, error boundaries, and React rendering FlatList pagination, pull to refresh, search, and offline retry Promises, timeouts, concurrency limits, and exponential backoff Caching, EventEmitter, Pub/Sub, LRU design, and native module boundaries Interview coding checklist Confirm assumptions before writing code. State time and space complexity. Handle empty input, invalid input, and duplicate values deliberately

This is Part 6 of 10 , a bonus practice article containing 191 output-based JavaScript interview questions . It includes 111 questions drawn from the React Native Interview Handbook plus 80 additional questions on the JavaScript behavior interviewers commonly test in React Native rounds: hoisting, scope, closures, arrays, objects, functions, coercion, conditions, Promises, and the event loop. Complete series This Dev.to series has five core handbook articles plus five focused practice extras. Open the series page to move through the complete reading order: Part 1: JavaScript — core handbook, questions 1–120 Part 2: React — core handbook, questions 121–220 Part 3: React Native — core handbook, questions 221–420 Part 4: Performance & Architecture — core handbook, questions 421–560 Part 5: Senior & System Design — core handbook, questions 561–719 Part 6: Output-Based JavaScript Practice — bonus practice article Part 7: Coding Interview Practice — bonus practice article Part 8: Code Output Challenges — bonus practice article Part 9: Current React Native Interview Questions — new high-frequency practice article Part 10: Project & Production Interviews — senior project ownership and real-production practice How to use this guide Before opening an answer, state the exact output first. Then explain the rule that causes it: evaluation order, scope, coercion, reference identity, prototype lookup, or microtask scheduling. Run the snippet only after committing to an answer. Topics covered Hoisting, Temporal Dead Zone, var , let , const , and function declarations Scope, closures, this , arrow functions, call , apply , and bind Arrays, sparse arrays, map , reduce , sort , slice , splice , and mutation Objects, references, shallow copies, prototypes, getters, and property lookup Conditions, truthiness, equality, nullish coalescing, and type coercion Promises, async / await , microtasks, timers, and error recovery React and React Native rendering behavior, state updates, effects,

In today's mobile-first world, users expect authentication to be both secure and effortless. Typing passwords every time an app is opened not only impacts the user experience but also introduces security risks if passwords are weak or reused. Biometric authentication solves this problem by allowing users to verify their identity using Fingerprint , Face ID , Touch ID , Iris Scanner , or even their device's PIN/Password . If you're building a React Native application, @sbaiahmed1/react-native-biometrics is one of the most comprehensive biometric libraries available. Beyond simple authentication prompts, it offers hardware-backed cryptographic key management, biometric enrollment detection, device integrity checks, StrongBox support, and compatibility with both the React Native New Architecture and Expo. In this article, we'll explore everything this library offers and learn how to integrate biometric authentication into a React Native application. Why Biometric Authentication? Traditional authentication methods come with several drawbacks: Passwords are easy to forget. Weak passwords are vulnerable to attacks. OTP-based logins can be slow and frustrating. Users often abandon apps with poor login experiences. Biometric authentication addresses these challenges by providing: 🔒 Enhanced security ⚡ Faster authentication 😊 Better user experience 📱 Native platform support 🔑 Secure fallback using device credentials Whether you're building a banking app, healthcare platform, enterprise application, or e-commerce app, biometric authentication has become an expected feature. Installation Install the package using npm: npm install @ sbaiahmed1 /react-native-biometric s or with Yarn: yarn add @ sbaiahmed1 /react-native-biometric s For iOS: cd ios pod install Platform Configuration Before using biometric authentication, configure the required permissions for both Android and iOS. Android Open your android/app/src/main/AndroidManifest.xml file and add the following permissions: <

Expo SDK 56 ships with a custom Kotlin compiler plugin that eliminates reflection from Expo Modules on Android. The result: 70% faster module initialization and a 30% reduction in time to first render. The plugin runs during compilation, so app developers get these performance gains automatically without changing any code. Module authors can unlock even bigger wins with a single annotation. This post walks through how we built it and why this approach succeeded where previous attempts failed. For the Swift side where we now talk to JSI directly, check out our companion post Talking to JSI in Swift . The reflection problem we inherited Before Expo Modules, we had Unimodules. They worked like old React Native bridge modules: you'd sprinkle annotations across methods you wanted to expose, and the runtime would discover everything through reflection. class ClipboardModule ( context : Context ) : ExportedModule ( context ) { override fun getName () = "ExpoClipboard" @ExpoMethod fun getStringAsync ( promise : Promise ) { val clip = clipboardManager . primaryClip ?. getItemAt ( 0 ) promise . resolve ( clip ?. text ?. toString () ?: "" ) } @ExpoMethod fun setStringAsync ( content : String , promise : Promise ) { clipboardManager . setPrimaryClip ( ClipData . newPlainText ( null , content )) promise . resolve ( true ) } } Reflection made sense when we needed metadata about our own code. What methods does this module export? What arguments do they accept? The JVM could answer those questions. But reflection costs time, and on Android that time comes straight out of your startup budget. Every module the runtime introspects adds milliseconds before users see your app. Building the Expo Modules API gave us a chance to fix this. We wanted better ergonomics and less reflection. The Kotlin DSL delivered both in one move, removing most reflection while making modules easier to write. But we couldn't eliminate all of it. Type information for function arguments and Record properties s