Expo vs Bare React Native: Workflow-Vergleich

1. Warum die Frage Expo gegen Bare heute anders klingt als früher

Vor einigen Jahren war die Entscheidung zwischen Expo und dem Bare Workflow noch simpel: Expo war bequem, aber eingeschränkt, während Bare React Native volle Kontrolle bei mehr Setup-Aufwand bot. Ein Wechsel von Expo zu Bare bedeutete früher einen unumkehrbaren Eject-Schritt, nach dem die generierten iOS- und Android-Ordner manuell gepflegt werden mussten. Diese Zeiten sind vorbei. Mit Prebuild, Config Plugins und Development Builds hat sich Expo zu einer Toolchain entwickelt, die auch fast beliebige native Module unterstützt, ohne die Annehmlichkeiten des Managed Workflows aufzugeben.

Trotzdem bleibt die Wahl zwischen Expo und Bare React Native eine strategische Entscheidung mit Konsequenzen für Build-Zeit, CI-Pipeline und Team-Onboarding. Wer die beiden Modelle nicht sauber unterscheidet, trifft die Entscheidung oft aus veralteten Vorurteilen heraus, etwa der Annahme, Expo eigne sich nur für Prototypen. In der Praxis laufen große Produktions-Apps mit Millionen Nutzern auf reinem Expo, während andere Teams bewusst Bare wählen, weil sie tiefen Zugriff auf native Build-Konfiguration benötigen.

Dieser Artikel ordnet beide Workflows entlang der tatsächlichen technischen Unterschiede ein: Wo Expo Arbeit abnimmt, wo Prebuild als Brücke funktioniert, und wann der reine Bare Workflow tatsächlich die bessere Wahl ist.

2. Der Expo Managed Workflow im Detail

Der Expo Managed Workflow bündelt die gesamte native Toolchain hinter einer deklarativen Konfigurationsdatei, der app.json beziehungsweise app.config.js. Statt Xcode-Projekte und Gradle-Dateien manuell zu pflegen, definiert man App-Name, Bundle-Identifier, Icons, Splash-Screens und Berechtigungen zentral in dieser einen Datei. Beim Build generiert Expo daraus automatisch die nativen Projektstrukturen, ohne dass ein Entwickler jemals ein natives Projekt im Editor öffnen muss.

Dieses Modell reduziert die Einstiegshürde für Web-Entwickler erheblich, da kein Xcode-Wissen und keine Gradle-Kenntnisse notwendig sind, um eine funktionierende App zu bauen. Gleichzeitig bringt Expo ein umfangreiches Set an vorkonfigurierten Modulen mit, von Kamera über Standort bis zu sicherem Speicher, die alle bereits getestet und mit den korrekten Berechtigungsanfragen versehen sind. Für Teams ohne dedizierte Mobile-Erfahrung ist dieser Startvorteil oft entscheidend für die Time-to-Market.

{
  "expo": {
    "name": "ShopApp",
    "slug": "shop-app",
    "version": "2.4.0",
    "orientation": "portrait",
    "icon": "./assets/icon.png",
    "splash": {
      "image": "./assets/splash.png",
      "resizeMode": "contain",
      "backgroundColor": "#0f172a"
    },
    "ios": {
      "bundleIdentifier": "de.mironsoft.shopapp",
      "supportsTablet": true
    },
    "android": {
      "package": "de.mironsoft.shopapp",
      "permissions": ["CAMERA", "ACCESS_FINE_LOCATION"]
    },
    "plugins": [
      "expo-camera",
      "expo-location",
      ["expo-build-properties", { "ios": { "deploymentTarget": "15.1" } }]
    ]
  }
}

3. EAS Build und EAS Update: die Cloud-Infrastruktur von Expo

EAS, kurz für Expo Application Services, ist die Cloud-Infrastruktur, die Expo von einer reinen Entwicklungsbibliothek zu einer vollständigen Build- und Release-Plattform macht. EAS Build kompiliert native iOS- und Android-Binaries in der Cloud, ohne dass lokal ein Mac für iOS-Builds vorhanden sein muss. Das ist ein erheblicher Vorteil gegenüber dem klassischen Bare Workflow, bei dem iOS-Builds zwingend auf macOS-Hardware laufen müssen, entweder lokal oder über eine selbst betriebene CI-Infrastruktur.

EAS Update ergänzt EAS Build um Over-the-Air-Updates für JavaScript- und Asset-Änderungen, ohne einen neuen App-Store-Review-Zyklus durchlaufen zu müssen. Wichtig für die Praxis: EAS Update funktioniert nur für Code-Änderungen, nicht für native Änderungen wie ein neues natives Modul oder eine geänderte Info.plist. Wer diesen Unterschied nicht kennt, veröffentlicht versehentlich ein Update, das auf älteren, bereits installierten Binaries nicht greift, weil die zugrunde liegende native Runtime nicht kompatibel ist.

# Build a production iOS binary in the cloud, no local Mac needed
eas build --platform ios --profile production

# Build both platforms for internal testing
eas build --platform all --profile preview

# Push a JS-only update to production channel without app store review
eas update --branch production --message "Fix checkout validation bug"

4. Development Builds statt Expo Go

Expo Go, die generische App aus den App Stores, war lange der einzige Weg, eine Expo-App auf einem echten Gerät zu testen. Der entscheidende Nachteil: Expo Go enthält nur eine feste Auswahl vorinstallierter nativer Module und kann keine zusätzlichen nativen Bibliotheken laden, die nicht bereits Teil der Expo Go Runtime sind. Diese Einschränkung war jahrelang der Hauptgrund, warum Teams frühzeitig zu Bare React Native gewechselt sind, sobald sie eine Bibliothek außerhalb des Expo-Ökosystems einbinden mussten.

Development Builds lösen dieses Problem vollständig. Statt der generischen Expo Go App baut man eine eigene, projektspezifische Development-App, die exakt die nativen Module enthält, die das Projekt tatsächlich benötigt, inklusive Bibliotheken von Drittanbietern außerhalb des Expo-Ökosystems. Dieser Ansatz kombiniert die Entwicklungsgeschwindigkeit von Expo, etwa Hot Reloading und Fast Refresh, mit der vollen nativen Flexibilität, die früher nur Bare React Native bot.

5. Prebuild: die Brücke zwischen Expo und Bare

expo prebuild ist der Befehl, der die deklarative app.json-Konfiguration in tatsächliche ios/- und android/-Verzeichnisse übersetzt, exakt wie sie auch ein reines Bare-React-Native-Projekt hätte. Der entscheidende Unterschied zum historischen Eject-Befehl: Prebuild ist wiederholbar. Man kann ios/ und android/ jederzeit löschen und mit expo prebuild --clean neu generieren, ohne manuelle Änderungen an diesen Ordnern zu verlieren, solange diese Änderungen über Config Plugins statt direkt im generierten Code vorgenommen wurden.

Dieses Modell erlaubt vielen Teams, dauerhaft im deklarativen Modus zu bleiben und die nativen Ordner niemals ins Versionskontrollsystem einzuchecken. Andere Teams entscheiden sich bewusst dafür, nach dem ersten Prebuild die nativen Ordner dauerhaft zu committen und manuell weiterzupflegen, was faktisch dem klassischen Bare Workflow entspricht, nur mit Expo-Modulen als Startpunkt. Diese Flexibilität macht Expo heute kompatibel mit fast jedem Reifegrad eines Projekts, vom ersten Prototyp bis zur komplexen Enterprise-App.

6. Der Bare Workflow: volle Kontrolle, voller Aufwand

Der Bare React Native Workflow bedeutet, direkt mit den generierten ios/- und android/-Projekten zu arbeiten, ohne die Abstraktionsschicht von Expo Prebuild. Xcode-Projekteinstellungen, Gradle-Build-Skripte und native Manifest-Dateien werden manuell gepflegt. Dieser Ansatz ist zwingend, wenn ein Projekt native Build-Schritte benötigt, die sich nicht über Config Plugins abbilden lassen, etwa sehr spezifische Xcode-Build-Phasen, benutzerdefinierte Gradle-Tasks oder die Integration mit bestehenden nativen iOS- und Android-Codebasen, in die React Native als Bibliothek eingebettet wird, statt umgekehrt.

Der Preis für diese Kontrolle ist Wartungsaufwand: Jedes React-Native-Upgrade erfordert manuelles Nachziehen von Änderungen in den nativen Projektdateien, ein Prozess, der bei größeren Versionssprüngen mehrere Stunden bis Tage in Anspruch nehmen kann. CI-Pipelines müssen eigenständig aufgesetzt werden, inklusive Signierung, Provisioning Profiles und App-Store-Uploads, Aufgaben, die EAS Build im Expo-Ökosystem weitgehend automatisiert. Teams mit dediziertem Mobile-Engineering-Know-how kommen mit diesem Aufwand meist gut zurecht, kleinere Teams unterschätzen ihn regelmäßig.

7. Config Plugins: native Anpassungen ohne Eject

Config Plugins sind der Mechanismus, mit dem Expo native Projektanpassungen deklarativ ermöglicht, ohne den generierten Code direkt zu editieren. Ein Config Plugin ist eine Funktion, die während expo prebuild ausgeführt wird und programmatisch Änderungen an den generierten Info.plist-, AndroidManifest.xml- oder Build-Gradle-Dateien vornimmt. Viele populäre native Bibliotheken liefern ihr eigenes Config Plugin mit, sodass die Installation aus Sicht des Entwicklers nur aus npx expo install und einem Eintrag in der app.json besteht.

Für Sonderfälle ohne fertiges Plugin lassen sich eigene Config Plugins mit dem Paket @expo/config-plugins schreiben. Das ist deutlich weniger Aufwand, als man vermuten würde, da die API gezielte, typisierte Hilfsfunktionen für die häufigsten Modifikationen bereitstellt, etwa das Hinzufügen einer Berechtigung oder eines Frameworks. Dieser Mechanismus ist der eigentliche Grund, warum die Grenze zwischen Expo und Bare React Native heute so viel durchlässiger ist als noch vor wenigen Jahren.

// A minimal custom Expo config plugin
const { withInfoPlist } = require('@expo/config-plugins');

// Adds a custom Info.plist entry during prebuild, no manual Xcode editing needed
function withCameraUsageDescription(config, usageText) {
  return withInfoPlist(config, (config) => {
    config.modResults.NSCameraUsageDescription = usageText;
    return config;
  });
}

module.exports = withCameraUsageDescription;

8. Entscheidungskriterien für die Praxis

Die Entscheidung zwischen Expo und dem Bare Workflow sollte an konkreten Projektmerkmalen festgemacht werden, nicht an pauschalen Vorurteilen. Wer ein Team ohne dedizierte Mobile-Spezialisten hat, profitiert deutlich von EAS Build, Development Builds und dem großen Modul-Ökosystem von Expo, weil die native Toolchain-Komplexität weitgehend verschwindet. Auch Projekte mit engen Zeitplänen und der Notwendigkeit häufiger Over-the-Air-Updates ohne App-Store-Review profitieren stark von EAS Update.

Für Bare React Native sprechen konkrete Anforderungen wie die Integration in bestehende native Apps, sehr spezifische Build-Pipeline-Anforderungen, die sich nicht über Config Plugins abbilden lassen, oder Unternehmensrichtlinien, die eine vollständige On-Premise-CI ohne externe Cloud-Dienste vorschreiben. In der Praxis empfiehlt sich für neue Projekte fast immer der Start mit Expo und Development Builds, da der Wechsel zu Bare über Prebuild jederzeit möglich bleibt, während der umgekehrte Weg von Bare zu Expo deutlich aufwendiger ist.

9. Expo und Bare React Native im direkten Vergleich

Die folgende Tabelle stellt die zentralen Entscheidungskriterien zwischen Expo und Bare React Native gegenüber und zeigt, welcher Workflow in welchem Szenario den geringeren operativen Aufwand verursacht.

Die Tabelle zeigt: Es gibt keine pauschal richtige Antwort, sondern konkrete Kriterien, die je nach Projekt unterschiedlich gewichtet werden müssen. Der praktische Rat lautet meist, mit Expo zu starten und erst dann zu Bare zu wechseln, wenn eine konkrete Anforderung dies zwingend erfordert, nicht aus vorauseilendem Kontrollbedürfnis.

10. Zusammenfassung

Die Entscheidung zwischen Expo und Bare React Native ist heute weit weniger binär als noch vor einigen Jahren. Development Builds, Prebuild und Config Plugins haben die Grenze durchlässig gemacht: Ein Expo-Projekt kann fast jedes native Modul einbinden, ohne die deklarative Konfiguration zu verlassen, und lässt sich bei Bedarf jederzeit über Prebuild in ein Bare-Projekt überführen. EAS Build und EAS Update lösen zusätzlich zwei der größten operativen Schmerzpunkte von Bare React Native: Mac-Abhängigkeit für iOS-Builds und langsame Update-Zyklen über den App Store.

Für die meisten neuen Projekte ist der Start mit Expo die pragmatischere Wahl, da der Wechsel zu Bare später möglich bleibt, während der umgekehrte Weg mehr Migrationsaufwand bedeutet. Bare React Native bleibt die richtige Wahl für Brownfield-Integrationen in bestehende native Apps und für Teams mit sehr spezifischen, nicht über Config Plugins abbildbaren Build-Anforderungen.

11. FAQ: Expo vs Bare React Native