[{"data":1,"prerenderedAt":15},["ShallowReactive",2],{"$fx1SVRm6rthm808Jv2nYi_BGpBCwl_Hp0inAwmfJvq38":3},{"slug":4,"title":5,"description":6,"date":7,"tags":8,"draft":12,"readingMinutes":13,"html":14},"expo-vs-react-native","Expo vs React Native: Which One Should You Start With?","Expo vs React Native in 2026: Expo is React Native plus a framework, and React Native's own docs start you there. When bare React Native still makes sense, and what EAS costs.","2026-10-22",[9,10,11],"react native","expo","mobile",false,4,"\u003Cp>Expo vs React Native is mostly a false choice in 2026. Expo is React Native with a framework on top: file-based routing, a standard library of native modules and tools that generate the iOS and Android projects for you. React Native's own \u003Ca href=\"https://reactnative.dev/docs/environment-setup\">getting started page\u003C/a> tells you to create new projects with Expo (\u003Ccode>npx create-expo-app@latest\u003C/code>). So for a new app, my answer is Expo, and the real questions are whether you pay for Expo's cloud services and when you'd ever skip the framework.\u003C/p>\n\u003Cp>I've built a fitness app for iOS and Android in React Native, so this is a choice I have opinions about. Everything below about versions and prices was checked on October 22, 2026.\u003C/p>\n\u003Ch2>What "Expo" actually means now\u003C/h2>\n\u003Cp>People still picture the Expo of 2019: a sandbox that couldn't run your own native code, which you "ejected" from the moment you needed Bluetooth or a payment SDK. That's not what it is anymore, and most of the old Reddit threads comparing the two are about that version.\u003C/p>\n\u003Cp>Today the word covers three different things, and it helps to keep them apart:\u003C/p>\n\u003Cimg src=\"/blog/expo-vs-react-native/expo-react-native-layers.webp\" alt=\"Three layers: React Native at the bottom, the free Expo framework (Router, SDK modules, prebuild) in the middle, and the optional paid EAS services (Build, Submit, Update) on top\" width=\"1600\" height=\"900\" loading=\"lazy\">\u003Cul>\n\u003Cli>\u003Cstrong>React Native\u003C/strong> is the core: your JavaScript or TypeScript, React components, and the bridge to real native views. Meta maintains it.\u003C/li>\n\u003Cli>\u003Cstrong>The Expo framework\u003C/strong> is free and open source: \u003Ca href=\"https://docs.expo.dev/router/introduction/\">Expo Router\u003C/a> for screens as files, the Expo SDK modules (camera, notifications, file system, secure storage and a lot more), and "prebuild", which writes the \u003Ccode>ios/\u003C/code> and \u003Ccode>android/\u003C/code> folders from your config. The latest version is SDK 58, released October 14, 2026, according to the \u003Ca href=\"https://expo.dev/changelog\">Expo changelog\u003C/a>.\u003C/li>\n\u003Cli>\u003Cstrong>EAS\u003C/strong> (Expo Application Services) is the optional paid cloud: builds, store submission and over-the-air updates.\u003C/li>\n\u003C/ul>\n\u003Cp>You can use the first two and never pay Expo anything.\u003C/p>\n\u003Ch2>Why I'd start with Expo\u003C/h2>\n\u003Cp>The honest reason is the native folders. In a bare React Native project, \u003Ccode>ios/\u003C/code> and \u003Ccode>android/\u003C/code> are yours. Every SDK you add may ask you to edit a Gradle file, a Podfile or \u003Ccode>AppDelegate\u003C/code>, and every React Native upgrade means merging Apple's and Google's latest template changes into files you edited by hand. That upgrade is the part teams put off for a year and then pay for in a week.\u003C/p>\n\u003Cp>With prebuild, those folders are generated. Libraries ship config plugins that make their native edits for you, and you can regenerate the projects from scratch on every upgrade. If something truly needs custom native code, you write a local Expo module or a config plugin, and it still lives in your repo, not as a hand edit nobody remembers.\u003C/p>\n\u003Cp>You also get development builds instead of Expo Go: your own app binary with your native modules inside, plus fast refresh. That's the setup I'd want on any app that's going to the stores.\u003C/p>\n\u003Ch2>When bare React Native still makes sense\u003C/h2>\n\u003Cp>There are a few real cases:\u003C/p>\n\u003Col>\n\u003Cli>\u003Cstrong>You're adding React Native to an existing native app.\u003C/strong> A brownfield app already owns its Xcode and Android Studio projects. You embed React Native screens into them, and a generated project doesn't fit.\u003C/li>\n\u003Cli>\u003Cstrong>A team that wants to own every line of native config\u003C/strong>, usually because they have native engineers who already maintain it and a CI pipeline built around it.\u003C/li>\n\u003Cli>\u003Cstrong>An SDK so invasive that a config plugin would be fighting it\u003C/strong>. This is rarer than people think, but it exists, mostly in older enterprise SDKs.\u003C/li>\n\u003C/ol>\n\u003Cp>Notice what's not on the list: "I need native code". Expo handles that now.\u003C/p>\n\u003Ch2>What EAS costs (and when you don't need it)\u003C/h2>\n\u003Cp>From \u003Ca href=\"https://expo.dev/pricing\">Expo's pricing page\u003C/a>, checked today:\u003C/p>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Plan\u003C/th>\n\u003Cth>Price\u003C/th>\n\u003Cth>What's included\u003C/th>\n\u003C/tr>\n\u003C/thead>\n\u003Ctbody>\u003Ctr>\n\u003Ctd>Free\u003C/td>\n\u003Ctd>$0\u003C/td>\n\u003Ctd>15 Android and 15 iOS builds a month, low-priority queue, updates to 1,000 monthly active users\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>Starter\u003C/td>\n\u003Ctd>$19 a month + usage\u003C/td>\n\u003Ctd>$45 of build credit, high-priority queue, updates to 3,000 MAUs\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>Production\u003C/td>\n\u003Ctd>$199 a month + usage\u003C/td>\n\u003Ctd>$225 of build credit, 15 concurrencies, updates to 50,000 MAUs\u003C/td>\n\u003C/tr>\n\u003C/tbody>\u003C/table>\n\u003Cp>For a solo developer or a small team, Free covers a lot. The thing people actually pay for is EAS Update, sending JavaScript fixes to installed apps without a store review, once their user count passes the free tier.\u003C/p>\n\u003Cp>You don't need EAS at all to ship. You can run \u003Ccode>npx expo run:ios\u003C/code> and \u003Ccode>npx expo run:android\u003C/code> locally, archive in Xcode, upload an Android App Bundle yourself, and wire your own CI. It's more work, and the iOS side still needs a Mac. For a client app I'd set up EAS Build for the first release, because it removes the "works on my machine" signing problems, and then we decide on updates once there are real users.\u003C/p>\n\u003Ch2>So which one?\u003C/h2>\n\u003Cp>Start with Expo, use development builds, keep native changes in config plugins, and add EAS services only where they save you time. Go bare only if you're embedding React Native into an app that already exists, or your team has a strong reason to own the native projects.\u003C/p>\n\u003Cp>If you're still deciding whether React Native is right at all, I wrote about \u003Ca href=\"/blog/react-native-vs-flutter\">React Native vs Flutter\u003C/a> too. And if you have an app idea or a half-built React Native project that needs finishing, \u003Ca href=\"https://calendly.com/director-norsky/meeting\">book a free call\u003C/a> and tell me where it's stuck.\u003C/p>\n",1792626781363]