Expo vs Bare React Native Comparison

A managed React Native framework set up with Node.js LTS, reversible thanks to CNG

VS
Bare React Native

The core React Native setup, giving full control over the native toolchain

16 min readCross-Platform

Quick Verdict

In 2026 the default answer is Expo + CNG: since expo prebuild regenerates the native folders, "eject" is no longer a one-way door, the config plugin system covers most native configuration, and EAS Build's free tier is enough for a small-to-mid-sized project. The reasons that justify Bare React Native are narrow but real: a custom toolchain EAS doesn't support, a mandatory on-prem CI requirement, or a very rare native SDK. If none of those apply, start with Expo.

ExpoBare React Native
Read the full verdict

Score Comparison

Loading chart...

Detailed Scoring

Detailed Scoring: Expo and Bare React Native — category-by-category scores out of 10
CategoryExpoBare React Native
Performance
8/10
8/10
Ease of Learning
9/10
6/10
Ecosystem
8/10
8/10
Community
8/10
8/10
Job Market
7/10
8/10
Future-Proof
8/10
7/10

Pros & Cons

Expo

Pros

  • Setup requires only Node.js LTS — test instantly with Expo Go/Snack without Xcode/Android Studio
  • CNG (expo prebuild) regenerates native folders — 'eject' is no longer a one-way door
  • The config plugin system configures the native project programmatically and reproducibly
  • EAS Update ships instant OTA JS updates separate from the native layer
  • The EAS Build Free plan includes 15+15 builds/month and 1,000 MAU updates — a no-cost start for a small project
  • EAS Workflows trigger automated native builds from GitHub events/cron, driven by the app config
  • Upgrading is as simple as updating an npm dependency plus prebuild --clean
  • As a founding member of the React Foundation, Expo stays closely aligned with the RN ecosystem

Cons

  • Expo SDKs trail the RN core by one version (SDK 57 → RN 0.86, not RN 0.87) — you can't get the newest RN feature immediately
  • Expo Go (iOS) has required login in the terminal and the app since September 3, 2026
  • Writing a config plugin for very rare/specialized native SDKs can take extra effort
  • Once the EAS Free plan is exceeded, you must move to a paid tier: Starter ($19/month) or Production ($199/month)
  • Because EAS is designed cloud-first, it fits poorly with a mandatory on-prem enterprise CI requirement
  • Hand-editing native folders and then running prebuild silently wipes those changes (unless moved into a config plugin)

Best For

Teams wanting to start a new React Native project quicklySmall-to-mid-sized projects that can use EAS's cloud CI/CDMVP/prototype development and fast iterationApps with heavy OTA update needs that want to ship JS fixes without waiting for store reviewProjects whose native needs are covered by the standard config plugin ecosystem (camera, notifications, location, etc.)

Bare React Native

Pros

  • Direct, unlimited access to the native project (Xcode/Gradle) — no abstraction layer
  • You get every RN minor release (0.85, 0.86, 0.87...) immediately, without waiting for the Expo SDK cycle
  • No dependency on EAS at all — set up any CI/CD service or on-prem pipeline you want
  • You can integrate any native SDK directly, not limited to the config plugin ecosystem
  • 126,507 GitHub stars and 25,238 forks back a large, mature community
  • MIT-licensed, open source, no vendor lock-in

Cons

  • Setup requires Xcode + CocoaPods, Android Studio + SDK + Gradle — a noticeably longer initial setup than Expo
  • The native ios/android folders are permanent; every version upgrade requires manually applying diffs via Upgrade Helper
  • There's no ready-made OTA update solution — you must manually integrate expo-updates or set up an alternative
  • Even if you want to use CI/CD (including EAS), you must manually sync native build credentials
  • Extra native package configuration (Info.plist permissions, Manifest entries, Gradle settings) is done by hand — there's no config plugin reproducibility
  • Toolchain setup for a new developer joining the team noticeably extends the time to the first build

Best For

Projects requiring a custom toolchain or build environment that EAS doesn't supportTeams with a mandatory enterprise on-prem/self-hosted CI requirementApps requiring a very rare or highly specialized native SDK integration that can't be covered by a config pluginLarge, complex apps that need continuous, deep intervention in native codeTeams that want to use the newest RN core version without waiting for the SDK cycle

Code Comparison

Expo
// Expo — adding a native permission via app.config.ts + a local config plugin (TypeScript)

// plugins/withCameraUsage.ts — config plugin that adds camera permission to Info.plist
import { ConfigPlugin, withInfoPlist } from "expo/config-plugins";

const withCameraUsage: ConfigPlugin = (config) =>
  withInfoPlist(config, (config) => {
    config.modResults.NSCameraUsageDescription =
      "We need camera access to take a profile photo";
    return config;
  });

export default withCameraUsage;

// app.config.ts — the plugin is referenced by file PATH (requires npm i -D tsx)
import "tsx/cjs";
import { ExpoConfig, ConfigContext } from "expo/config";

export default ({ config }: ConfigContext): ExpoConfig => ({
  ...config,
  name: "MyApp",
  slug: "my-app",
  version: "1.0.0",
  plugins: [["./plugins/withCameraUsage.ts"], "expo-router", "expo-updates"],
  updates: { url: "https://u.expo.dev/your-project-id" },
  runtimeVersion: { policy: "appVersion" },
});

// Terminal: generate the native folders (CNG) and apply them
// npx expo prebuild --clean

// Run EAS Build and publish an OTA update
// eas build --platform all --profile production
// eas update --branch production --message "Bug fix: login crash"
Bare React Native
// Bare React Native — package installation + manual native configuration (TypeScript)

// 1) Install the package: autolinking links it, fetch pods, rebuild
// $ npm install react-native-vision-camera react-native-nitro-modules react-native-nitro-image
// $ npx pod-install
// $ npm run ios     # Android: npm run android

// 2) Add permissions MANUALLY — this step is not part of autolinking
// ios/MyApp/Info.plist:
// <key>NSCameraUsageDescription</key>
// <string>We need camera access to take a profile photo</string>
// android/app/src/main/AndroidManifest.xml:
// <uses-permission android:name="android.permission.CAMERA" />

// 3) Usage on the JS side (shared code)
import React, { useEffect } from "react";
import { Camera, useCameraPermission } from "react-native-vision-camera";

function ProfileCamera() {
  const { hasPermission, requestPermission } = useCameraPermission();

  useEffect(() => {
    if (!hasPermission) requestPermission();
  }, [hasPermission, requestPermission]);

  return <Camera style={{ flex: 1 }} isActive={true} device="back" />;
}

export default ProfileCamera;

// 4) Upgrading (0.86 -> 0.87): there is NO CLI command for this
// Upgrade Helper (web): https://react-native-community.github.io/upgrade-helper/
// -> apply the diff manually to Podfile.lock, build.gradle, AppDelegate.swift

// 5) Your own CI pipeline (GitHub Actions, summary)
// - run: npx pod-install
// - run: xcodebuild -workspace ios/MyApp.xcworkspace -scheme MyApp -configuration Release

Conclusion

In 2026 the default answer is Expo + CNG: since expo prebuild regenerates the native folders, "eject" is no longer a one-way door, the config plugin system covers most native configuration, and EAS Build's free tier is enough for a small-to-mid-sized project. The reasons that justify Bare React Native are narrow but real: a custom toolchain EAS doesn't support, a mandatory on-prem CI requirement, or a very rare native SDK. If none of those apply, start with Expo.

Get Free Consultation
FAQ

Frequently Asked Questions

In 2026 the default answer is Expo + CNG: the config plugin system covers most native modules, EAS Build's free tier (15+15 builds/month) is enough for a small-to-mid-sized project, and thanks to expo prebuild, dropping down to native code is no longer an irreversible decision. The real reasons that justify bare RN: a custom toolchain EAS doesn't support, a mandatory enterprise on-prem CI requirement, or a very rare native SDK that a config plugin can't cover.

Introduction

When starting a React Native project, the first question is no longer "which UI library" but "which setup model": Expo or bare React Native? React Native 0.87 (August 11, 2026) made the Strict TypeScript API the default and raised the minimum toolchain (Node 22, AGP 9, Kotlin 2.0+) — in a bare project you upgrade this by hand. On the Expo side, SDK 57 (June 30, 2026) and the general availability of EAS Observe (August 20, 2026) expanded the tooling; and as of September 3, 2026, mandatory login arrived for the iOS version of Expo Go. In the past, choosing "managed" meant giving up access to native code; "eject" was a one-way door. Today, with Continuous Native Generation (CNG) and expo prebuild, the native ios/android folders can be generated and deleted on demand. Bare React Native, on the other hand, guarantees full control and independence from EAS — at the cost of setting up and managing the native toolchain by hand. This comparison is based on the RN blog, Expo changelog/pricing pages, and GitHub API data.

Comparison Matrix

Comparison Matrix: Expo / Bare React Native
FeatureExpoBare React Native
Native module integrationAutolinking + config pluginAutolinking + manual Info.plist/Gradle
Native folder managementCNG (generated via prebuild) (Winner)Permanent, manual maintenance
Setup requirementNode.js LTS only (Winner)Xcode + Android Studio + Gradle
Version upgrade flownpm update + prebuild --clean (Winner)Manual diff via Upgrade Helper
Current core versionSDK 57 → RN 0.86RN 0.87.1 (npm) (Winner)
EAS Build free tier15+15 builds/month, 1K MAU update (Winner)Usable but native sync is manual
OTA updateEAS Update integrated by default (Winner)expo-updates requires manual integration
CI/CD (EAS Workflows)Automatic native build from app config (Winner)Manual native credential sync or your own pipeline
Quick preview (Expo Go)Yes, login required on iOS since Sep 3, 2026 (Winner)None
Vendor lock-in / exit costLow (prebuild is reversible)None (already independent) (Winner)
Enterprise on-prem CI requirementEAS is cloud-first, hard to fitFully flexible, you build your own CI (Winner)
Custom/rare native SDK integrationMay require writing a config pluginDirect native project editing (Winner)
Year founded2015 (650 Industries)2015 (Meta, RN core)
GitHub stars52,060 (expo/expo)126,507 (react/react-native) (Winner)
LicenseMITMIT

Deep Dive

Expo

Overview

Expo is a framework + toolset built on top of React Native, founded in 2015 by 650 Industries (Palo Alto). As one of the founding members of the React Foundation, it works closely with the RN ecosystem. Historically, the 'managed workflow' restricted access to native code, and 'eject' was a hard-to-reverse operation; with expo prebuild, this model evolved into Continuous Native Generation (CNG) — the official documentation treats the concepts of 'ejecting' and 'managed vs bare workflow' as deprecated; the native folders aren't source, but repeatable output generated from the app config. As of 2026, the current release is SDK 57 (June 30, 2026, carrying RN 0.86); with EAS Build, Update, Workflows, and the newly GA Observe (August 20, 2026), it offers an end-to-end cloud platform. Expo Go is still the fastest way to test instantly without a native SDK installed, but as of September 3, 2026, login is mandatory on iOS (development builds are exempt).

Ecosystem

Package manager
npm / Yarn / pnpm (via Expo CLI)
Development environment
VS Code + Expo ToolsAndroid Studio (native build)Xcode (native build)
Popular libraries
expo-routerexpo-updatesexpo-notificationsexpo-cameraexpo-modules-core
GitHub stars
52,060

Bare React Native

Overview

React Native was released by Meta (formerly Facebook) on April 26, 2015, and the 'bare' setup is its core, unmanaged form — built directly on native Xcode/Gradle projects without any framework layer (including Expo). The repo is hosted under react/react-native, with 126,507 GitHub stars and 25,238 forks, a large community, and an MIT license. As of 2026, the current stable release is 0.87.1 (announced August 11, 2026): the Strict TypeScript API became the default, the minimum toolchain rose to Node 22/AGP 9/Kotlin 2.0+, and experimental Swift Package Manager support was added. New Architecture became the default with RN 0.76 (October 23, 2024) and was declared production-ready in the same announcement. In a bare setup, the native folders are a permanent part of the project — there's no 'regeneration' layer like CNG; the native diff for each version upgrade is applied by hand by consulting Upgrade Helper.

Ecosystem

Package manager
npm / Yarn / pnpm + CocoaPods (iOS) + Gradle (Android)
Development environment
VS CodeXcode (native build)Android Studio (native build)
Popular libraries
react-navigationreact-native-reanimatedreact-native-gesture-handlerreact-native-vision-camera
GitHub stars
126,507

Technical Analysis

Adding Native Modules: Config Plugin vs. Manual Native Configuration

In Expo, the need to touch native code is resolved in two ways: npm packages containing native code are linked automatically via Expo Autolinking; for packages that require additional native configuration (Info.plist permissions, Android manifest entries, Gradle settings), you write a config plugin or use the package's own plugin. The official definition is clear: a config plugin lets you automatically configure the native project generated during the prebuild process beyond the default app config props — meaning the same native project is regenerated every time prebuild runs. In bare React Native, native packages are also linked via autolinking: the official documentation's flow is simply npm install <package> + npx pod-install + rebuilding the app, without writing a Podfile or Gradle entry by hand. What remains manual is configuration: Info.plist permission keys, AndroidManifest entries, Gradle settings. Because these live inside the native folders, they must be preserved by hand on every RN version upgrade. In short, the difference isn't in linking but in where configuration lives: in Expo, "write a config plugin once, it's applied on every prebuild"; in bare RN, "keep every native configuration in the project and preserve it through upgrades."

CNG/Prebuild: Generating Native Folders From Scratch

Continuous Native Generation (CNG) is Expo treating the native folders as "compiled output" rather than "source." When you run npx expo prebuild --clean, the android and ios folders are generated from scratch based on the app config (app.json/app.config.js) and the installed config plugins. The official documentation summarizes the practical result this way: the RN version upgrade process now consists only of updating npm dependencies and the app config, then rerunning prebuild --clean. The native folders may not be committed to git (.gitignore); CI regenerates them on every build. In bare React Native, the android/ios folders are a permanent, manually maintained part of the project. This is exactly why React Native's web-based "Upgrade Helper" tool exists: you have to manually apply the native file differences (Podfile, build.gradle, AppDelegate) between each minor version. This provides more transparency (you always see exactly what's in the native project) but makes version upgrades noticeably more labor-intensive compared to CNG — especially since RN itself ships a minor version every few months (0.85 in April, 0.86 in June, 0.87 in August 2026).

EAS Build/Update Cost and the Free Tier

EAS's Free plan includes 15 Android + 15 iOS builds per month (30 total), OTA update delivery to up to 1,000 MAU, and 100 GiB of edge bandwidth — with a low-priority build queue. For a small-to-mid-sized project building a few times a week, this is usually enough. Once a team grows or CI is triggered frequently, there are two tiers: Starter ($19/month + $45 build credit, high-priority queue, 3,000 MAU) and Production ($199/month + $225 build credit, 2 concurrent builds, 50,000 MAU, SSO, priority support). Overage fees are $0.10/GiB for bandwidth and $0.05/GiB for storage. An important nuance: EAS Build and EAS Update aren't Expo-specific — the official documentation defines EAS Workflows as a CI/CD service "for React Native and Expo apps." So a bare RN project can use EAS too. But without CNG, you have to manually sync the native project state (build credentials, native configuration) to EAS; in Expo projects this sync flows automatically through the app config. Not using EAS and instead building your own CI (Fastlane, Bitrise, GitHub Actions + Xcode/Gradle scripts) from scratch is also a common choice in bare RN — its cost is time and maintenance overhead, not a direct subscription fee.

OTA Updates and the Expo Go Login Change

EAS Update splits a build into two layers: the native layer embedded in the binary, and the "mutable" update layer between them — small bug fixes and JS changes reach users through the channel and deployment mechanism without waiting for a native version upgrade. The expo-updates library can also be manually integrated into a bare RN project (Expo modules can be used in bare RN too), but it isn't default/automatic — the developer sets up their own OTA solution. Starting September 3, 2026, an important change came to the iOS version of Expo Go: login became mandatory both in the terminal's Expo CLI and in the Expo Go app to run a project. This distinction is critical — the official changelog explicitly states that development builds are exempt from this requirement, and that it currently only affects the latest Expo Go version on iOS. In other words, running a development or production build produced with EAS Build doesn't depend on the login requirement; this friction only exists in Expo Go, the quick-prototyping tool, and only on iOS. Bare RN projects have no such "quick preview app" layer at all, so this discussion doesn't touch it.

New Architecture and RN 0.87 Strict TypeScript Adoption Speed

React Native 0.87 (August 11, 2026) made the Strict TypeScript API the default JavaScript API and raised the minimum toolchain requirements to Node.js 22, Android Gradle Plugin 9, and Kotlin 2.0+; it also added experimental Swift Package Manager support. New Architecture, meanwhile, started as an experimental opt-in in 0.68; it was made default with RN 0.76 (October 23, 2024) and declared production-ready in the same announcement — so by 0.87, both setup models get it by default. There's an important distinction here: Expo SDKs ship locked to a specific RN core version, meaning SDK 57 (June 30, 2026) carries RN 0.86, not RN 0.87. This means Expo projects haven't gotten RN 0.87's Strict TS default yet and have to wait for the next SDK release — there's no official commitment date. Expo projects get this kind of upgrade "bundled" with an SDK update, while bare RN projects can upgrade each minor RN version (0.85→0.86→0.87) independently and immediately. Third-party packages using deep imports will throw type errors on the move to Strict TS — in bare RN you experience this right away, in Expo you experience it along with the SDK upgrade.

CI/CD: EAS Workflows vs. Your Own Pipeline

EAS Workflows is a CI/CD service that automates recurring tasks like Android/iOS binary builds, publishing OTA updates, submitting to the stores, running E2E tests, and web deploys to EAS Hosting. It runs in managed cloud environments and can be triggered by GitHub events (push, PR) or cron schedules. The official documentation states it can be used for both React Native and Expo projects — meaning a bare RN project can also hook into EAS Workflows. The difference shows up in how the "pre-packaged" jobs are designed: in Expo/CNG projects, EAS can manage the native build process end to end by reading the app config. In a bare RN project, the native project state (signing certificates, provisioning profiles, Gradle configuration) has to be manually synced to EAS — you provide here what CNG generates automatically. Alternatively, bare RN teams often build a pipeline from scratch with Fastlane + Bitrise or GitHub Actions + their own Xcode/Gradle scripts; this loses the "pre-packaged" convenience EAS offers but gives full control over the pipeline and fits enterprise on-prem requirements (e.g., a mandatory self-hosted runner).

Vendor Lock-in and Time From Setup to First Build

The official documentation treats the concept of "eject" as deprecated; all Expo projects now use Continuous Native Generation, and expo prebuild has taken its place. The practical meaning of this change: as long as you don't touch the native folders by hand, prebuild can always regenerate the same native project — meaning "leaving managed" is no longer a one-way door but a repeatable operation. If you remove a config plugin, the native folders are regenerated without it. There's flexibility in the other direction too: thanks to expo-modules-core, Expo modules can also be added to bare RN projects afterward — meaning the move "from bare to Expo tooling" isn't a one-way door either. The setup-threshold difference is concrete: the only system requirement for an Expo project is Node.js LTS — after npx create-expo-app, you can test instantly via Expo Go or Snack without a native SDK installed. In bare RN, the official documentation points you to the "environment-setup" section: installing Xcode + CocoaPods, Android Studio + SDK + Gradle is a prerequisite for the first build. This difference determines not just the first day, but the setup cost paid every time by a developer newly joining the team and by whoever sets up the CI environment.

Which One, When

You're starting a new React Native project from scratch, with no custom toolchain or on-prem CI requirement

Recommendation: Expo + CNG

With npx create-expo-app you have a working project in minutes, the EAS Free plan (15+15 builds/month) is enough for a small-to-mid project, and you can drop down to native code with prebuild when needed.

Corporate policy requires CI to run self-hosted/on-prem

Recommendation: Bare React Native

Since EAS is designed cloud-first, it directly conflicts with an on-prem requirement; you'll need to build your own Fastlane/Jenkins pipeline.

You need to integrate a very rare native SDK that can't be covered by a config plugin

Recommendation: Bare React Native (or Expo + custom dev client)

Expo Go can't run this SDK; writing a config plugin may not be possible. For integrations that need direct access to the native project, bare RN, or at least an EAS development build, is required.

You have an existing bare RN project and native folder maintenance has become a burden

Recommendation: Add Expo modules incrementally, evaluate moving to CNG

Thanks to expo-modules-core, Expo modules like OTA update and notifications can be added to a bare project; a full move to CNG requires a large refactor and shouldn't be rushed.

The team is small, a fast MVP/prototype is needed, and shipping to the App Store isn't the priority

Recommendation: Develop with Expo Go

Instant on-device testing without native toolchain setup; on iOS, login has been required since September 3, 2026, but this is a one-time friction that goes away once you move to a development build.

You need to move to the RN 0.87 Strict TypeScript API right away

Recommendation: Consider bare React Native (or wait for the next SDK)

Bare RN upgrades each minor version independently; since Expo SDKs ship locked to an RN core version, the Strict TS default only arrives in the next SDK release (no committed date). If the release cadence isn't a blocker for you, waiting is also a valid option.

Common Pitfalls

  • Manually editing the native ios/android folders and then running expo prebuild --clean — all manual changes are wiped out

    Expo

    Solution

    If you want a native change to be permanent, write a config plugin; it's applied automatically every time prebuild runs, so the manual edit isn't lost.

  • Wasting hours thinking the project doesn't work because you haven't logged in to Expo Go (iOS) after September 3, 2026

    Expo

    Solution

    If you're using a development build, this requirement doesn't apply; if you're testing with Expo Go, log in both in the terminal's Expo CLI and in the phone app.

  • Assuming 'an RN 0.87 feature exists in Expo' without checking which RN core version the Expo SDK carries

    Expo

    Solution

    Verify the RN version each SDK release carries in its changelog (e.g., SDK 57 → RN 0.86, not RN 0.87); if you're waiting on a new RN feature, follow the next SDK.

  • Postponing minor version upgrades (0.85→0.86→0.87) in bare RN and ending up with a backlogged, multi-step upgrade

    Bare React Native

    Solution

    Use React Native Upgrade Helper for every minor version; a backlogged upgrade compounds native file conflicts.

  • Forgetting to manually sync native build credentials and configuration when using EAS in a bare RN project

    Bare React Native

    Solution

    Without CNG, EAS can't read the native project state from the app config; you have to manually upload and keep signing certificates and provisioning profiles up to date with the EAS CLI.

Migration Guide

Bare React Native → Expo (CNG)

Estimated time: Small project (5-10 native customizations): 1-2 weeks. Mid-sized (many third-party native modules): 3-6 weeks. Large project with complex/very custom native integrations: 2-3 months, some modules may not be portable to CNG.
  1. 11. Add the expo package and expo-modules-autolinking to the project, set up the base integration with npx install-expo-modules@latest
  2. 22. Inventory your existing native customizations (Info.plist permissions, AndroidManifest entries, Gradle dependencies) — check whether each one has a config plugin equivalent
  3. 33. Write a custom config plugin for native changes with no equivalent (using mods APIs like withInfoPlist, withAndroidManifest)
  4. 44. Create app.json/app.config.js, add the plugins to the plugins array
  5. 55. Run npx expo prebuild --clean and verify the generated native project builds (in Xcode + Android Studio)
  6. 66. Move the CI pipeline to EAS Build or update the existing pipeline to read the app config
  7. 77. If you need OTA updates, integrate expo-updates and configure EAS Update channels
  8. 88. Add the native folders to .gitignore (they're now generated output), document the prebuild workflow for the team

Future Outlook

Expo

Expo's roadmap is accelerating: SDK 57 (June 30, 2026), the general availability of EAS Observe (August 20, 2026, with tiers of 100K-500K events/month for performance/error monitoring), and the expanding config plugin ecosystem are making CNG less exception-prone. It hasn't been officially announced when the next SDK release will carry RN 0.87's Strict TypeScript default — suggesting Expo's pattern of trailing "one version behind the RN core" may continue. The Expo changelog says the Expo Go login requirement will be extended to the Android version in the future; no date was given.

Bare React Native

The React Native core is moving at its own independent pace: 0.85 (April 2026, new animation backend), 0.86 (June 2026, edge-to-edge + DevTools), 0.87 (August 2026, Strict TS + experimental SwiftPM) — roughly a minor release every two months. Since New Architecture has been the default since 0.76 (October 23, 2024), the roadmap's focus has shifted from the architecture transition to release cadence. The trend for bare RN is clear: the freedom to adopt every release immediately, in exchange for the burden of manually applying every upgrade with Upgrade Helper.

Golden Insight

The most valuable takeaway is this: you don't need to answer the "Expo or bare RN" question once and for all. Thanks to CNG, it's now a reversible decision. Start with Expo — npx expo prebuild is always available to you; you can drop down to native code and write a config plugin; the next prebuild --clean returns you to a clean native project (as long as you haven't touched the native files by hand). The door is open in the other direction too: with expo-modules-core, you can add Expo's OTA update or notification modules to a bare project afterward. The real risk is choosing bare RN from the start out of a "can't go back" fear and needlessly taking on the Xcode/Gradle maintenance burden.

Related Blog Posts

View All Posts

Related Projects

View All Projects
All Comparisons