Expo vs Bare React Native Vergleich

Mit Node.js LTS eingerichtetes, dank CNG umkehrbares Managed-RN-Framework

VS
Bare React Native

Kernkonfiguration von React Native mit voller Kontrolle über die native Toolchain

16 Min. LesezeitCross-Platform

Schnelles Fazit

2026 lautet die Standardantwort Expo + CNG: `expo prebuild` erzeugt die nativen Ordner neu, wodurch "Eject" keine Einbahnstraße mehr ist, das Config-Plugin-System deckt den Großteil der nativen Konfiguration ab, und der kostenlose Tarif von EAS Build reicht für kleine bis mittlere Projekte. Die Gründe, die Bare React Native rechtfertigen, sind eng, aber real: eine von EAS nicht unterstützte spezielle Toolchain, eine On-Prem-CI-Pflicht oder ein sehr seltenes natives SDK. Fehlen diese drei, starte mit Expo.

ExpoBare React Native
Vollständiges Fazit lesen

Punktevergleich

Diagramm wird geladen...

Detaillierte Bewertung

Detaillierte Bewertung: Expo und Bare React Native — Bewertungen pro Kategorie auf einer Skala von 1 bis 10
KategorieExpoBare React Native
Performance
8/10
8/10
Erlernbarkeit
9/10
6/10
Ökosystem
8/10
8/10
Community
8/10
8/10
Arbeitsmarkt
7/10
8/10
Zukunftssicherheit
8/10
7/10

Vor- und Nachteile

Expo

Vorteile

  • Für die Einrichtung genügt allein Node.js LTS — sofortiger Test mit Expo Go/Snack ohne Xcode/Android Studio
  • Mit CNG (`expo prebuild`) lassen sich native Ordner neu erzeugen — "Eject" ist keine Einbahnstraße mehr
  • Das Config-Plugin-System konfiguriert das native Projekt programmatisch und wiederholbar
  • Mit EAS Update ein sofortiges OTA-JS-Update, getrennt von der nativen Ebene
  • Der kostenlose EAS-Build-Tarif enthält 15+15 Builds/Monat und Updates für 1.000 MAU — kostenloser Start für kleine Projekte
  • Mit EAS Workflows automatischer nativer Build, ausgelöst durch GitHub-Events/Cron, basierend auf der App-Konfiguration
  • Versions-Upgrade ist so einfach wie ein npm-Abhängigkeits-Update + `prebuild --clean`
  • Als Gründungsmitglied der React Foundation enge Abstimmung mit dem RN-Ökosystem

Nachteile

  • Expo-SDKs hinken dem RN-Kern eine Version hinterher (SDK 57 → RN 0.86, nicht RN 0.87) — kein sofortiger Zugriff auf das neueste RN-Feature
  • Expo Go (iOS) verlangt seit dem 3. September 2026 einen Login im Terminal und in der App
  • Ein Config-Plugin für sehr seltene/spezielle native SDKs zu schreiben, kann zusätzlichen Aufwand bedeuten
  • Bei Überschreiten des EAS-Free-Plans ist ein Wechsel zum kostenpflichtigen Starter- (19 $/Monat) oder Production-Tarif (199 $/Monat) nötig
  • Da EAS cloud-first konzipiert ist, ist die Kompatibilität mit einer unternehmensinternen On-Prem-CI-Pflicht schwach
  • Manuelles Bearbeiten nativer Ordner mit anschließendem Prebuild löscht Änderungen stillschweigend (sofern sie nicht in ein Config-Plugin überführt wurden)

Am besten geeignet für

Teams, die neue React-Native-Projekte schnell starten wollenKleine bis mittelgroße Projekte, die die EAS-Cloud-CI/CD nutzen könnenMVP-/Prototyp-Entwicklung und schnelle IterationApps mit hohem OTA-Update-Bedarf, die JS-Fixes ohne Store-Freigabe ausliefern wollenProjekte, deren native Anforderungen durch das Standard-Config-Plugin-Ökosystem (Kamera, Benachrichtigungen, Standort usw.) abgedeckt sind

Bare React Native

Vorteile

  • Direkter, unbegrenzter Zugriff auf das native Projekt (Xcode/Gradle) — keinerlei Abstraktionsschicht
  • Jede Minor-Version von RN (0.85, 0.86, 0.87 ...) sofort verfügbar, ohne auf den Expo-SDK-Zyklus zu warten
  • Keine Abhängigkeit von EAS — jeder beliebige CI/CD-Dienst oder eine On-Prem-Pipeline lässt sich einrichten
  • Jedes native SDK lässt sich direkt integrieren, nicht beschränkt auf das Config-Plugin-Ökosystem
  • Breite und ausgereifte Community-Unterstützung mit 126.507 GitHub-Sternen und 25.238 Forks
  • MIT-lizenziert, Open Source, keine Vendor-Abhängigkeit

Nachteile

  • Für die Einrichtung sind Xcode + CocoaPods sowie Android Studio + SDK + Gradle zwingend — deutlich längere Erstinstallation als bei Expo
  • Die nativen `ios`/`android`-Ordner sind dauerhaft; jedes Versions-Upgrade erfordert das manuelle Anwenden eines Diffs über den Upgrade Helper
  • Es gibt keine fertige Lösung für OTA-Updates — `expo-updates` muss manuell integriert oder eine Alternative eingerichtet werden
  • Selbst bei Nutzung von CI/CD (auch EAS) müssen native Build-Credentials manuell synchronisiert werden
  • Zusätzliche native Paketkonfiguration (Info.plist-Berechtigungen, Manifest-Einträge, Gradle-Einstellungen) erfolgt manuell — ohne die Wiederholbarkeit eines Config-Plugins
  • Für neu hinzukommende Entwickler verlängert die Toolchain-Einrichtung die Zeit bis zum ersten Build deutlich

Am besten geeignet für

Projekte, die eine von EAS nicht unterstützte spezielle Toolchain oder Build-Umgebung benötigenTeams mit unternehmensinterner On-Prem-/Self-Hosted-CI-PflichtApps, die eine sehr seltene oder spezielle native SDK-Integration benötigen, die kein Config-Plugin abdecktGroße, komplexe Apps mit fortlaufendem, tiefem Eingriff in nativen CodeTeams, die die aktuellste Version des RN-Kerns nutzen wollen, ohne auf den SDK-Zyklus zu warten

Code-Vergleich

Expo
// Expo — natives Recht per app.config.ts + lokalem Config-Plugin hinzufügen (TypeScript)

// plugins/withCameraUsage.ts — Config-Plugin, das die Kameraberechtigung in die Info.plist einfügt
import { ConfigPlugin, withInfoPlist } from "expo/config-plugins";

const withCameraUsage: ConfigPlugin = (config) =>
  withInfoPlist(config, (config) => {
    config.modResults.NSCameraUsageDescription =
      "Profil fotoğrafı çekmek için kameraya erişim gerekiyor";
    return config;
  });

export default withCameraUsage;

// app.config.ts — das Plugin wird per Dateipfad referenziert (npm i -D tsx erforderlich)
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: native Ordner erzeugen (CNG) und anwenden
// npx expo prebuild --clean

// EAS Build ausführen und OTA-Update veröffentlichen
// eas build --platform all --profile production
// eas update --branch production --message "Bug fix: login crash"
Bare React Native
// Bare React Native — Paketinstallation + manuelle native Konfiguration (TypeScript)

// 1) Paket installieren: Autolinking bindet es ein, Pods werden geladen, neu kompiliert
// $ 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) Berechtigungen MANUELL hinzufügen — dieser Schritt ist nicht Teil des Autolinking
// ios/MyApp/Info.plist:
// <key>NSCameraUsageDescription</key>
// <string>Profil fotoğrafı çekmek için kameraya erişim gerekiyor</string>
// android/app/src/main/AndroidManifest.xml:
// <uses-permission android:name="android.permission.CAMERA" />

// 3) Verwendung auf JS-Seite (gemeinsamer 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) Versions-Upgrade (0.86 -> 0.87): dafür gibt es KEINEN CLI-Befehl
// Upgrade Helper (Web): https://react-native-community.github.io/upgrade-helper/
// -> den Diff manuell auf Podfile.lock, build.gradle, AppDelegate.swift anwenden

// 5) Eigene CI-Pipeline (GitHub Actions, zusammengefasst)
// - run: npx pod-install
// - run: xcodebuild -workspace ios/MyApp.xcworkspace -scheme MyApp -configuration Release

Fazit

2026 lautet die Standardantwort Expo + CNG: `expo prebuild` erzeugt die nativen Ordner neu, wodurch "Eject" keine Einbahnstraße mehr ist, das Config-Plugin-System deckt den Großteil der nativen Konfiguration ab, und der kostenlose Tarif von EAS Build reicht für kleine bis mittlere Projekte. Die Gründe, die Bare React Native rechtfertigen, sind eng, aber real: eine von EAS nicht unterstützte spezielle Toolchain, eine On-Prem-CI-Pflicht oder ein sehr seltenes natives SDK. Fehlen diese drei, starte mit Expo.

Kostenlose Beratung erhalten
FAQ

Häufig gestellte Fragen

2026 lautet die Standardantwort Expo + CNG: Das Config-Plugin-System deckt die meisten nativen Module ab, der kostenlose Tarif von EAS Build (15+15 Builds/Monat) reicht für kleine bis mittlere Projekte, und dank `expo prebuild` ist der Zugriff auf nativen Code keine unumkehrbare Entscheidung mehr. Echte Gründe für Bare RN: eine von EAS nicht unterstützte spezielle Toolchain, eine unternehmensinterne On-Prem-CI-Pflicht oder ein sehr seltenes natives SDK, das kein Config-Plugin abdeckt.

Verwandte Blogartikel

Alle Artikel ansehen

Verwandte Projekte

Alle Projekte ansehen
Alle Vergleiche