If you're planning an iOS and Android app, someone has probably told you Expo is "just for prototypes." Someone else has told you bare React Native is "the old way." Both claims are out of date more often than not. On expo vs bare React Native for business apps, our default is simple: start with Expo, and move to bare only when a specific native requirement forces the issue.
This guide covers the decision in terms of launch speed, cost, hiring, store approvals, maintenance and flexibility, so you can sanity-check what a developer or agency tells you. If you'd rather talk it through, our mobile app development team scopes this decision at the start of every project. For a wider view of the framework choice, see our comparison of React Native vs Flutter for small business.
Expo vs bare React Native for business apps: the short answer
For most new business apps, use Expo. Booking apps, field service tools, customer portals, staff apps and member apps all need the same plumbing: login, an API, push notifications, forms, photo upload, maps and payments. Expo handles that plumbing well, and it gets you to a testable app on real phones sooner.
Here's a concrete example. If your app only needs login, forms, camera upload and push notifications, Expo means nobody has to set up and hand-maintain native iOS and Android projects during the first build. That is days of setup you don't pay for, and a class of build problems you don't inherit.
Choose bare React Native when native control is a core requirement of the product rather than a nice-to-have. That means unusual hardware, a niche SDK with no Expo path, heavy background processing, or an existing native codebase you must build on.
The commercial stakes are practical:
- Faster first prototype. Less setup means you see a working app sooner.
- Simpler builds and releases. Fewer machines and configurations can break.
- Easier ongoing updates. Small fixes can reach users faster.
- Lower maintenance risk. Fewer hand-managed native files means fewer surprises when iOS or Android changes.
The rest of this article explains when that default holds and when it doesn't.
What Expo and bare React Native actually mean
React Native is the framework that lets one team build iOS and Android apps from a single JavaScript/TypeScript codebase. The result uses native UI components rather than a web page wrapped in a mobile shell.
Expo is a framework and toolchain built on top of React Native. It handles the common mobile plumbing: project structure, device features like the camera and notifications, cloud builds and store submission. React Native's own getting-started documentation recommends using a framework for new apps and lists Expo as a common route.
Bare React Native means the team manages the iOS and Android native projects directly. They open Xcode and Android Studio, configure native settings by hand and add native libraries themselves. That is more control and more responsibility.
It is not "real React Native versus a toy." Both approaches produce the same kind of app. The difference is who looks after the native layer: Expo's tooling or your developers.
Expo is not just a beginner tool anymore
The "Expo can't do real apps" reputation comes from an older era. Early on, you stayed inside a limited sandbox until you hit a wall. Today's Expo works differently, and a few terms explain why:
- Development builds are custom versions of your app that include your own native code. They replace the limited Expo Go preview app once you need more than the basics.
- Config plugins let a developer change the native iOS and Android settings from a configuration file, so native tweaks don't need hand-edited projects.
- Prebuild generates the native iOS and Android projects from your configuration whenever needed, so those projects stay reproducible.
- EAS Build compiles your iOS and Android apps in the cloud, with no dependency on one developer's laptop.
- EAS Submit sends finished builds to Apple and Google.
- EAS Update delivers JavaScript and asset changes over the air, without a new store release.
If a developer says Expo is too limited, ask which specific capability they mean, then check it against current Expo documentation. Sometimes the objection is valid. Often it's a habit from several years ago.
What "bare" gives you
Bare gives your team direct control over the native projects. That matters for custom native modules, unusual SDKs, deep OS-level integrations and legacy native code you need to keep.
Treat it as power with a maintenance bill, not as a mark of quality. A bare app isn't automatically faster, more stable or better built. Teams choose it because the project needs that control, and for most business apps it doesn't.
Decision table: Expo vs bare React Native
"Usually Expo" means Expo is the sensible default for a standard business app. "Bare may be better" flags where heavy native, hardware or legacy needs can tip the decision.
| Factor | Typical business app | Heavy native / hardware / legacy |
|---|---|---|
| Time to first prototype | Usually Expo: minimal setup | Bare may be better only if native setup is unavoidable anyway |
| App store launch | Usually Expo: cloud builds and submission | Bare may be better if you need a strict custom pipeline |
| Native module access | Usually Expo: covers common needs | Bare may be better for unsupported or custom modules |
| Custom SDKs | Usually Expo, using development builds and config plugins | Bare may be better for deeply invasive SDKs |
| Push notifications | Usually Expo | Either works |
| Over-the-air updates | Usually Expo: EAS Update is built in | Bare can add OTA tooling, with more setup |
| Payments and subscriptions | Usually Expo for standard payment and in-app purchase flows using supported libraries | Either works, but subscriptions need store-compliant native and backend setup |
| Background tasks | Usually Expo for light tasks | Bare may be better for heavy or continuous work |
| Bluetooth / hardware | Usually Expo for simple cases | Bare may be better for complex IoT or devices |
| Team skills | Usually Expo: JavaScript/TypeScript skills go further | Bare may be better if you have native engineers |
| Maintenance burden | Usually Expo: less native upkeep | Bare: more native upkeep |
| CI/CD complexity | Usually Expo: managed pipeline | Bare may be better for custom enterprise pipelines |
| Tooling reliance | Some reliance on Expo services | Bare may be better if you want fewer third-party dependencies |
| Long-term flexibility | Usually Expo: the path to custom native is open | Bare: maximum control from day one |
Choose Expo when your app is a typical business app
Here are the app types we see most often at the SMB level:
- A booking or appointment app
- A field service app for technicians
- A customer portal on mobile
- A staff operations app
- A subscription content app
- An e-commerce companion app
- A delivery or order-status tracker
- A member or loyalty app
- An event app
They share a feature list: authentication, API integration, push notifications, forms, media upload, maps, payments, analytics and an admin dashboard for your team. All of that is compatible with an Expo-led approach if the scope is defined properly. Nothing on that list is exotic.
Why Expo can reduce launch risk
Fewer setup decisions means fewer places to go wrong. A developer joining the project can run the app quickly instead of spending days on environment problems. Builds run in the cloud, so you aren't depending on one person's machine. Handoff to a new team is simpler, which matters if you change vendors or bring maintenance in-house.
Launch isn't the finish line. An app earns a spot on the home screen through iteration: fixing friction, adjusting onboarding, adding the feature users keep asking for. A toolchain that makes release and update paths clear helps you keep improving the app after launch.
What Expo means for cost and timeline
Look at total cost of ownership, not just the build quote. Expo can cut initial engineering overhead, and routine updates and upgrades tend to be easier to manage. The offset is that EAS, Expo's cloud build and update service, has its own pricing tiers. Treat it as a line item and check Expo's current pricing for plans and limits before budgeting. We deliberately don't quote figures here, because they change.
Ask any team you're considering to break the estimate into design, build, backend, store launch and ongoing maintenance, so you can compare quotes like for like. Our guide to what an app costs for a small business in Toronto shows typical ranges, and if you want price certainty, read about fixed price custom software development. If you're in Canada, some development work may also qualify for SR&ED tax credits (see SR&ED for app development). Eligibility depends on the work, so confirm with your accountant.
Hiring is a cost too. React Native and Expo projects draw on JavaScript/TypeScript skills, which many teams already have. A bare setup that depends on native expertise narrows who can maintain it, though that's a fair trade if the app needs it.
Choose bare React Native when the app has real native complexity
Bare is the right call when one or more of these is true:
- An unusual native SDK has no Expo-compatible path and can't be wrapped cleanly.
- Complex Bluetooth or IoT hardware is central to the product.
- Heavy background processing is required, such as continuous location or long-running tasks.
- Advanced camera, audio or video workflows go beyond standard capture and playback.
- Custom native UI components are a core part of the experience.
- You have an existing native iOS or Android codebase the new app must live alongside.
- A regulated enterprise environment dictates a specific build pipeline.
- Your team already has strong native mobile engineers who will be more productive with direct control.
If you recognize your project in that list, you're not choosing wrongly. You're choosing deliberately.
The cost of bare is not just development time
With bare, your team owns the native layer. That means keeping native dependencies compatible, maintaining Xcode and Android Studio setups, debugging native build failures and absorbing every iOS and Android update. Android and iOS problems get troubleshot separately.
None of that is a reason to avoid bare when the business value justifies the control. It's a reason not to choose it by default or because it sounds more serious.
What about ejecting? The old warning is outdated
Many older comparisons describe "ejecting" from Expo as a one-way cliff: outgrow the managed setup and you lose its benefits for good. That's no longer how modern Expo works. With prebuild, native projects can be generated from configuration, so the choice is much less permanent than it used to be.
Be honest about the limits, though. Moving between a managed setup and a heavily customized native one is still a technical project. It takes planning and testing and it isn't free. The risk is lower than the old warning suggested, but it isn't zero.
Can you add custom native code in Expo?
Yes, depending on the setup. Development builds let your app include native code that Expo Go can't run. Config plugins handle many native changes without hand-editing the projects.
The caveat is the niche SDK. If your app depends on one, validate compatibility during discovery or a small prototype before committing to a fixed scope. A few days of testing is cheaper than finding the problem in month three.
App store launch, OTA updates and compliance considerations
Whichever path you pick, the app goes through Apple App Store and Google Play review. You'll need developer accounts, signing certificates and provisioning, privacy disclosures (including Apple's privacy labels), consent handling for analytics, and compliance with Google's target API level requirements, which are updated regularly. Expo's tooling simplifies several of these steps. It doesn't remove them, and a rejection is a rejection regardless of framework.
Over-the-air (OTA) updates are useful. With EAS Update, a JavaScript or content fix can reach users without waiting on a full store release. But OTA has limits. It can't ship changes that require a new native binary, such as a new native library or a changed permission. And it doesn't bypass store rules: both Apple and Google have policies on downloaded code and on updates that change what an app does. Store policies change, so your team should read the current Apple and Google rules before building a release process around OTA.
Push notifications, payments, analytics and subscriptions
These aren't reasons to avoid Expo. They're normal requirements that need correct architecture, testing and store setup.
Push needs certificates, device tokens and a server that sends messages. Subscriptions and in-app purchases mean store-compliant purchase flows, sometimes native modules, and entitlement checks on your backend. Analytics means choosing events carefully and handling consent. Our scope typically covers push and analytics, payments and subscriptions, backend and APIs, and store launch as one connected piece of work, because the failures usually happen at the seams.
Backend and API choices matter as much as Expo vs bare
An app's success depends less on the Expo-or-bare question than on reliable authentication, a sound data model, admin tools for your staff, integrations with your existing systems, reporting and notifications. A beautiful app on a weak backend still frustrates users.
Common options include Firebase, Supabase and custom Node.js services. The right one depends on how much custom logic you have, who needs admin access and what you already run. If your app needs to connect to an ERP, CRM or booking system, that's where custom backend and API development earns its budget. Related reading: customer portal development cost in Canada.
If you already have an app: should you migrate?
It depends on what you have:
- Existing bare React Native app. Adopting parts of Expo's tooling, such as cloud builds or updates, may improve your release process without rewriting anything.
- Older Expo app. You may need to upgrade SDK versions before adding new features, and the longer you wait, the bigger the jump.
- Native Swift or Kotlin app. Moving to React Native may or may not pay off. It depends on the codebase's age, your feature roadmap and budget. A working native app is an asset.
Moving from bare toward Expo tooling later is possible, and so is moving from Expo toward more custom native work if the app grows. Both are real projects, so budget for them rather than assuming a switch.
Migration questions to ask before touching the codebase
Before anyone changes anything, get answers to these:
- Which React Native and Expo versions are you on?
- How healthy are your dependencies? Are any abandoned?
- Which native modules does the app rely on?
- What do crash reports show?
- How are builds and releases done today, and by whom?
- What's the app store status, and are any reviews or policy warnings pending?
- What analytics do you have to show how people use the app?
- How much test coverage exists?
- How stable is the API behind it?
- Do you need new features, or rescue maintenance?
Older apps often have the same problem as older business software: the right answer is incremental, not a rewrite (see how to modernize legacy software without a risky rewrite). If you want an independent view before committing budget either way, our consultancy and strategy team can review the codebase and the roadmap and tell you what's worth keeping.
Our recommendation framework for business apps
- Start with Expo if the app is new and has common business requirements.
- Use Expo with custom native development if you have a few native requirements but nothing that needs a platform-level rewrite.
- Use bare React Native if native control is a core requirement.
- Consider Flutter or fully native Swift/Kotlin if the app's UI, performance or platform-specific needs make React Native a poor fit.
We say the last one sincerely. React Native with Expo is a strong default for many SMB use cases, but it isn't right for everything. A graphics-heavy app, a product deeply tied to one platform's newest features, or a team that already has Flutter expertise may be better served elsewhere. We build with Flutter and native as well, so we'll tell you if your project belongs there. Our guide to cross-platform app development in Canada covers how to choose a build partner.
Five discovery questions before choosing Expo or bare
These questions settle most of the decision, and they're the start of how we scope projects:
- What must work offline or in the background? Light sync is easy. Continuous background work is where bare gets considered.
- Are there hardware devices or native SDKs involved? Name them now and check compatibility early.
- How quickly must we launch? A tight deadline favours Expo's shorter setup.
- Who will maintain it after launch? Pick a stack your long-term maintainers can actually support.
- What updates need to ship without app review, and what integrations and data power the app? This tells you how much OTA matters and how much backend work is hiding in the project.
Recommended path for most SMB apps
The sequence we recommend for most small and mid-sized businesses:
- Validate the idea with a clickable prototype and UX design before writing production code.
- Build the first production version in Expo and React Native where it suits the requirements.
- Test native risks early, such as an unusual SDK or hardware dependency, in a small spike.
- Launch to both stores.
- Track analytics and improve in short cycles after launch.
We cover that whole journey: prototype, cross-platform build, backend and APIs, payments and subscriptions, push and analytics, and store launch. You can see examples in our mobile and software case studies.
Expo vs bare React Native for business apps: our conclusion
For most business apps, Expo is the right starting point, and bare React Native is the right choice when native control is a core requirement. Have an app idea and want a straight answer on Expo or bare before you commit budget? Book a free 30-minute scoping call and we'll walk through your requirements and tell you what we'd build, and what we wouldn't.
