How to Build a Mobile App with React Native: Complete Guide
React Native powers roughly 39% of cross-platform mobile apps built today, according to Stack Overflow’s 2025 Developer Survey. If you’re looking to ship iOS and Android apps from a single JavaScript codebase, you’re joining a crowd that includes Shopify, Microsoft, and Airbnb—though some of them have since shifted strategies. This guide walks you through the actual process of building a real mobile app with React Native, with current benchmarks and honest trade-offs you’ll face.
Last verified: April 2026
Executive Summary
| Metric | Value | Source/Context |
|---|---|---|
| React Native Market Adoption | 39% of cross-platform projects | Stack Overflow Developer Survey 2025 |
| Average Project Setup Time | 45-90 minutes | Typical developer experience with Expo CLI |
| Code Reusability Between Platforms | 65-80% | Shared JavaScript, platform-specific modules needed |
| Monthly Active Npm Downloads | 2.8M downloads | React Native core package, March 2026 |
| Average Developer Productivity Gain | 35-45% faster than native | Based on feature-to-market time |
| Performance Gap vs Native | 5-15% slower on CPU tasks | Depends on app complexity and optimization |
| Community Modules Available | 185,000+ packages | React Native ecosystem via npm |
| Estimated Cost Savings | $40K-$120K per project | Single codebase vs separate iOS/Android teams |
Building Your First React Native App: Core Steps
You’ve got two main entry points: Expo or the bare React Native CLI. Expo gets you running faster—I can spin up a functional app in under an hour using their managed workflow. The trade-off is flexibility. You’re locked into Expo’s build system, which handles push notifications, asset management, and OTA updates beautifully, but you lose direct native module control. If you need custom native code or have performance constraints (think heavy image processing), the bare React Native CLI gives you a native iOS and Android project you can customize, but you’re responsible for your own build pipeline.
Here’s the reality: most startups and MVPs use Expo first. It’s free, it’s documented better than anything else in mobile dev, and you can deploy without touching Xcode or Android Studio. The Expo SDK gives you access to camera, geolocation, notifications, and 50+ other APIs out of the box. You build with JavaScript, test on your physical phone via the Expo app, and publish with one command. The app size penalty is real though—Expo apps start at about 35-40MB base size due to the runtime, versus 5-10MB for optimized native apps.
The code itself looks similar to React web, but you’re not building for the DOM. You import components from React Native instead of your usual HTML libraries. Text components replace <p> tags, View replaces <div>, and ScrollView handles lists—though you’ll want FlatList for performance on large datasets. State management works the same way; Redux, Zustand, and Context API all run fine. The gotcha is that styling uses a JavaScript object syntax, not CSS. It’s scoped locally by default, which prevents the CSS chaos you get in web projects, but it means you can’t reuse stylesheets across platforms in the usual way.
Navigation is where things get tricky. React Navigation is the standard library, and it’s solid, but it requires understanding stack navigators, tab navigators, and drawer navigators. A simple three-screen app might take you 30-45 minutes to wire up properly if you’re new to the pattern. Deep linking—making URLs in your app route to specific screens—adds another layer of complexity that you’ll need eventually once you’re past the prototype phase.
Expo vs Bare React Native: Feature Comparison
| Feature | Expo | Bare React Native CLI |
|---|---|---|
| Setup Time | 15 minutes | 45-60 minutes |
| Built-in APIs | 50+ (camera, location, notifications) | Requires third-party libraries |
| Custom Native Code | Via Expo Modules (limited) | Full native module support |
| Build System | EAS Build (managed, $99-599/month teams) | Xcode & Android Studio (free, self-managed) |
| App Size | 35-40MB minimum | 5-10MB (optimized) |
| Over-the-Air Updates | EAS Updates (included for Expo Go) | CodePush or custom solutions ($9-100/month) |
| Community Size | Smaller but growing | Larger ecosystem, more Stack Overflow answers |
| Learning Curve | Gentle | Steeper (native knowledge needed) |
I recommend Expo if you’re shipping an MVP in 8-12 weeks and don’t have hardware-specific requirements. The managed build service alone saves you dozens of hours wrestling with certificate signing and provisioning profiles. That’s worth $99/month to most teams. If you’re building something that needs Bluetooth, AR, or deeply integrated health metrics, start with bare React Native and use libraries like react-native-community packages that wrap native code.
The Expo-to-bare migration path exists, but it’s manual. You’re essentially ejecting your project and configuring your own native build files. It’s doable but not reversible, so test your custom native code requirements early if they matter for your idea.
Performance Benchmarks: Real-World Numbers
| Scenario | React Native (ms) | Native iOS (ms) | Native Android (ms) |
|---|---|---|---|
| App Cold Start | 2,800-3,500 | 800-1,200 | 1,500-2,100 |
| Render 1000-item List | 45-65 (with FlatList) | 12-18 | 18-25 |
| Image Processing (50 images) | 1,200-1,800 | 350-500 | 450-650 |
| Navigation Transition | 250-400 | 100-180 | 120-200 |
| JSON Parse (2MB file) | 180-250 | 45-70 | 60-90 |
The numbers look scary, but context matters. Cold start time of 3.5 seconds is fine for most apps—users expect a splash screen. The list rendering gap closes significantly with proper optimization (memoization, windowing, virtualization). Image processing is where React Native struggles most; if your app is fundamentally about filtering or transforming images in real-time, native might be worth the investment.
Key Factors That’ll Impact Your Build
1. State Management Strategy
You don’t strictly need Redux anymore. Context API handles most apps under 5 screens and 10 state trees. For anything more complex, Redux (about 42% of React Native developers use it) or modern alternatives like Zustand work fine. The real issue is that mobile apps hit performance cliffs faster than web apps when you’re passing state through deep component trees. Use selectors and memoization aggressively. A $0 solution (context) that’s poorly architected will feel slower than a $0 solution (Zustand) that’s optimized.
2. Network and Caching
Mobile networks are slow and unreliable compared to your development machine on WiFi. React Query (now TanStack Query) is almost mandatory once you’re fetching data from APIs. It handles caching, retry logic, and background refresh with 15 lines of configuration. Without it, your app will feel janky when the user’s connection drops. Budget for 20-30% of your development time on network resilience—that’s not wasted time, it’s the difference between a $2 app and a $20 app in terms of user satisfaction.
3. Bundle Size and Code Splitting
App store downloads still matter. A 150MB app loses about 15% of potential users in markets with limited bandwidth (much of Southeast Asia, Africa, and South America). For Expo apps, you’re at the mercy of the SDK version size. For bare apps, learn to split code with dynamic imports and lazy loading. Measure with `metro bundle-analyzer`. If you’re shipping an app over 100MB without obvious media content, you’ve got a problem.
4. Testing and CI/CD Pipeline
Jest works out of the box for unit tests. React Native Testing Library is your friend for component testing. But end-to-end testing is where things get painful. Detox is the best tool for this, and it works, but it’s not as mature as Selenium or Cypress. Budget $15K-$30K annually for CI/CD infrastructure (GitHub Actions, BrowserStack, or EAS Builds for Expo). Many teams skip proper e2e testing and regret it after shipping a broken build to production.
How to Use This Data
Choose Your Stack Early
In week one, decide: Expo or bare? State management library? Navigation approach? These decisions compound. Changing your mind after six weeks of development costs 10-20 hours of refactoring. I’m not saying you need to predict the future, but you need a coherent initial architecture. Write a one-page technical spec. It doesn’t need to be perfect—it just needs to exist so you’re not making these decisions under time pressure.
Test Performance on Real Devices Early
The simulator is a liar. iOS Simulator runs on your MacBook’s CPU; a real iPhone 12 is drastically slower. Android Emulator is particularly terrible. By week two, if you’re building something with lists or animations, test on actual phones. Buy a $200 Android device and borrow someone’s iPhone. You’ll catch performance issues that feel impossible to debug later. Use the React Native Performance Monitor (built-in) to watch frame rates and memory usage.
Budget for Platform Differences
That 65-80% code reuse figure? It assumes you’re okay with platform-specific UI. A button looks different on iOS (rounded rectangle) and Android (flat with ripple). StatusBar color handling differs. Safe area insets require different approaches. You’ll write `.ios.js` and `.android.js` files. Plan for 15-25% of your component library to be platform-specific. This isn’t wasted effort; it’s respecting platform conventions, which users actually appreciate.
Plan Your Release Strategy
App Store reviews take 24-48 hours (usually). Play Store is faster. With Expo, you can push OTA updates for JavaScript changes without re-reviewing, which is incredible. With bare React Native, you’re looking at CodePush ($9-100/month depending on usage). This matters for bug fixes. If you ship a critical bug on day one, Expo apps can be fixed in 15 minutes. Native apps need 48 hours plus review time. This is a significant advantage; factor it into your release timeline.
Frequently Asked Questions
Is React Native dead?
No, but its hype cycle peaked in 2017. Meta still maintains it actively, and big companies still use it (though many have written custom forks at scale). The real answer is nuanced: React Native is great for MVPs and small-to-medium teams where development speed matters more than hitting 60fps in complex animations. It’s not great if you’re building the next Instagram or a heavy gaming app. For a weather app, news reader, or e-commerce platform? React Native is a solid, pragmatic choice. The community is smaller than 2017, but it’s more mature and realistic about
