React Native EAS Build: Cloud Builds für iOS und Android

1. Welches reale Problem EAS Build löst

EAS Build ist der Cloud-Build-Dienst von Expo für React Native Apps und löst ein Problem, das jedes Team irgendwann trifft: iOS-Builds erfordern zwingend einen Mac mit installiertem Xcode, während Android-Builds eine gepflegte Android-Studio- und SDK-Installation voraussetzen. Für ein React Native Team ohne eigenen Mac-Rechner-Pool bedeutete das früher entweder teure Mac-Mini-Farmen im Büro oder gar keine eigenständigen iOS-Releases. EAS Build verlagert den kompletten Kompilierungsschritt auf Expos Infrastruktur, sodass ein Entwickler mit einem Windows- oder Linux-Rechner einen vollwertigen iOS-Build auslösen kann, ohne jemals einen Mac angefasst zu haben.

Der zweite reale Schmerzpunkt, den EAS Build adressiert, ist Setup-Drift zwischen Teammitgliedern. Bei lokalen Builds hat jeder Entwickler potenziell eine andere Xcode-Version, eine andere CocoaPods-Version, eine andere Android-NDK-Version installiert - und ein Build, der auf einem Rechner funktioniert, schlägt auf einem anderen mit kryptischen nativen Fehlermeldungen fehl. EAS Build führt jeden Build in einer definierten, versionierten Build-Image-Umgebung aus, sodass dieselbe Kombination aus Xcode-Version, Node-Version und nativen Toolchains bei jedem Build verwendet wird, unabhängig davon, welcher Entwickler ihn ausgelöst hat.

Der dritte Vorteil betrifft Reproduzierbarkeit in CI-Umgebungen. Ohne EAS Build müsste ein Team seinen eigenen Mac-Runner für GitHub Actions oder GitLab CI betreiben, samt Wartung, Updates und Kapazitätsplanung. Mit EAS Build reduziert sich die CI-Konfiguration auf einen API-Aufruf gegen die EAS-Infrastruktur, wodurch React Native Projekte dieselbe Build-Pipeline für lokale Entwicklung, Pull-Request-Checks und Store-Releases nutzen können, ohne eigene Build-Server zu betreiben.

2. eas.json: Build-Profile für development, preview und production

Die zentrale Konfigurationsdatei für EAS Build ist eas.json im Projekt-Root. Sie definiert benannte Build-Profile, von denen jedes eine eigenständige Kombination aus Distributionsart, nativen Build-Einstellungen und Umgebungsvariablen beschreibt. Die drei in nahezu jedem React Native Projekt vorkommenden Profile sind development, preview und production - development für Builds mit eingebettetem Dev-Client und Debug-Menü, preview für interne Testbuilds, die direkt installierbar sind, und production für den finalen Store-Build.

Ein entscheidendes Detail in eas.json ist das Feld distribution. Der Wert internal erzeugt einen Build, der direkt als Datei heruntergeladen und installiert werden kann, etwa über einen QR-Code an registrierte Testgeräte - ideal für preview-Builds ohne Umweg über TestFlight oder eine interne Play-Store-Testschiene. Der Wert store erzeugt dagegen ein Artefakt im Format, das App Store Connect beziehungsweise die Play Console erwartet, also ein signiertes .ipa beziehungsweise ein Android App Bundle. Diese Trennung erlaubt es, mit demselben Projekt und derselben EAS Build-Konfiguration sowohl schnelle interne Testbuilds als auch finale Store-Builds zu erzeugen, ohne manuell zwischen Build-Einstellungen hin- und herzuschalten.

Für Android lässt sich pro Profil zusätzlich der Ausgabetyp über buildType steuern - apk für einfach installierbare Testbuilds, app-bundle für die Play-Store-Einreichung. Für iOS steuert simulator, ob ein Build für den iOS-Simulator statt für echte Geräte kompiliert wird, was für automatisierte UI-Tests in CI ohne physisches Testgerät nützlich ist. Alle drei Profile leben nebeneinander in derselben eas.json, und jeder EAS Build-Aufruf wählt über das Flag --profile explizit aus, welche Konfiguration verwendet wird.

{
  "cli": {
    "version": ">= 13.0.0",
    "appVersionSource": "remote"
  },
  "build": {
    "development": {
      "developmentClient": true,
      "distribution": "internal",
      "ios": { "simulator": true },
      "android": { "buildType": "apk" },
      "env": { "APP_ENV": "development" }
    },
    "preview": {
      "distribution": "internal",
      "channel": "preview",
      "ios": { "simulator": false },
      "android": { "buildType": "apk" },
      "env": { "APP_ENV": "preview" }
    },
    "production": {
      "distribution": "store",
      "channel": "production",
      "autoIncrement": true,
      "android": { "buildType": "app-bundle" },
      "env": { "APP_ENV": "production" }
    }
  },
  "submit": {
    "production": {}
  }
}

3. Umgebungsvariablen und Secrets pro Build-Profil

Jedes Build-Profil in eas.json kann einen eigenen env-Block definieren, der als Umgebungsvariablen in der Build-Umgebung verfügbar gemacht wird. Für React Native und Expo Apps ist das der zentrale Mechanismus, um API-Endpunkte, Feature-Flags oder Bundle-Identifier zwischen development, preview und production zu unterscheiden, ohne den Anwendungscode selbst zu verzweigen. In app.config.js wird der Wert dann typischerweise über process.env.APP_ENV ausgelesen und entscheidet, welche API-Basis-URL, welcher App-Name oder welches App-Icon in diesen Build einfließt.

Nicht jede Umgebungsvariable gehört in die eas.json selbst, weil diese Datei üblicherweise ins Git-Repository eingecheckt wird. Für sensible Werte wie API-Schlüssel, Sentry-DSN-Tokens oder Zugangsdaten zu Drittanbieter-Diensten bietet EAS Build den Secrets-Store: Mit eas secret:create wird ein Wert verschlüsselt bei Expo hinterlegt und ist im Build unter demselben Variablennamen abrufbar, etwa als process.env.SENTRY_AUTH_TOKEN, ohne dass der Klartextwert jemals im Repository oder in eas.json auftaucht. Für Teams, die dieselbe Konfigurationslogik für CI außerhalb von EAS pflegen, ist das eine sauberere Alternative zu Secrets, die in Pipeline-Variablen des jeweiligen CI-Anbieters verstreut liegen.

Wichtig ist die Unterscheidung zwischen Build-Time- und Runtime-Variablen. Werte, die über env in eas.json oder über eas secret:create gesetzt werden, sind zum Zeitpunkt des EAS Build-Laufs verfügbar und werden beim Bundling in den JavaScript-Code eingebacken - eine spätere Änderung erfordert also einen neuen Build, keinen reinen Config-Refresh zur Laufzeit. Wer stattdessen Werte zur Laufzeit ändern möchte, ohne einen neuen Build auszulösen, braucht ein separates Remote-Config-System oder eas update für reine JavaScript- und Asset-Änderungen am bereits gebauten Binary. EAS Build erzeugt also genau das Binary, auf das eas update später Patches ausliefert - die beiden Dienste sind bewusst getrennte Schritte in derselben Release-Kette.

# Log in once per machine or CI runner
eas login

# Store a sensitive value encrypted - never lands in eas.json or git
eas secret:create --scope project --name SENTRY_AUTH_TOKEN --value "xxxxx" --type string

# Trigger a cloud build for a specific profile and platform
eas build --profile development --platform ios
eas build --profile preview --platform android

# Build both platforms for the store release, non-interactive for CI
eas build --profile production --platform all --non-interactive

# Inspect recent EAS Build runs and their status
eas build:list --limit 10

4. Credentials-Management: Zertifikate und Keystores automatisch

Einer der größten praktischen Vorteile von EAS Build ist die automatische Verwaltung der iOS- und Android-Signierungsmaterialien direkt im Build-Ablauf. Wird ein iOS-Build mit distribution store und credentialsSource remote ausgeführt, prüft EAS Build zunächst, ob bereits ein gültiges Distribution-Zertifikat und ein passendes Provisioning Profile für die konfigurierte Bundle ID hinterlegt sind. Fehlen diese, bietet der interaktive Ablauf an, sie direkt zu erzeugen und verschlüsselt in Expos Infrastruktur zu speichern - ein Entwickler muss dafür nicht selbst ins Apple Developer Portal wechseln oder ein Zertifikat manuell exportieren.

Für Android übernimmt EAS Build dieselbe Rolle für Keystores: Existiert noch kein Keystore für das Projekt, wird beim ersten production-Build automatisch einer erzeugt und dauerhaft mit dem Expo-Projekt verknüpft, sodass jeder folgende Build mit demselben Schlüssel signiert wird - eine Voraussetzung, damit der Play Store Updates derselben App überhaupt akzeptiert. Bestehende Keystores oder iOS-Zertifikate lassen sich jederzeit importieren, falls ein Team bereits vor dem Wechsel zu EAS Build eigene Signing-Materialien besaß, etwa aus einem früheren Fastlane- oder manuellen Xcode-Workflow.

Wichtig für den täglichen Build-Betrieb: Das Feld credentialsSource in eas.json entscheidet pro Profil, ob remote (die von EAS verwaltete Variante) oder local (lokal bereitgestellte Dateien, etwa für Teams mit eigenem Credentials-Repository) verwendet wird. So lässt sich in einem einzigen Projekt zum Beispiel production auf remote und ein Sonderprofil für Enterprise-Verteilung auf local stellen. Über den Befehl eas credentials lässt sich jederzeit einsehen, welches Zertifikat, Profile oder welcher Keystore aktuell für ein Build-Profil aktiv ist - EAS Build bleibt dadurch trotz Automatisierung kein Blackbox-Prozess.

5. Native Module und Config Plugins in der Cloud

Sobald ein React Native Projekt native Module mit eigenem nativen Code einbindet, etwa für Bluetooth-Kommunikation, Kamerazugriff oder Push Notifications, reicht reines JavaScript nicht mehr aus, um die native Konfiguration zu steuern. Expo löst das über Config Plugins: kleine, deklarative Funktionen, die während des vorgelagerten prebuild-Schritts von EAS Build die generierten nativen Projekte, also das Xcode-Projekt und das Android-Gradle-Projekt, gezielt modifizieren, bevor der eigentliche native Compiler startet. Ein Config Plugin kann etwa einen Eintrag in der Info.plist ergänzen, eine Gradle-Property setzen oder eine zusätzliche native Abhängigkeit registrieren.

Der entscheidende Vorteil gegenüber manuellem Editieren der ios/- und android/-Ordner: Diese Ordner existieren bei Managed-Workflow-Projekten gar nicht dauerhaft im Repository, sondern werden von EAS Build bei jedem Cloud-Build frisch aus app.json/app.config.js und den registrierten Config Plugins generiert. Das hält die native Konfiguration deklarativ, versionskontrolliert und reproduzierbar - ein manueller Eingriff in ein generiertes Xcode-Projekt würde beim nächsten Build ohnehin überschrieben. Für Projekte, die dauerhaft eigene native Dateien pflegen müssen, bietet EAS Build zusätzlich lokale Prebuild-Ausgaben (npx expo prebuild), die dann versioniert und nicht mehr automatisch neu generiert werden.

In der Praxis bedeutet das: Ein Team, das etwa react-native-ble-plx für Bluetooth Low Energy einbindet, muss weder die Info.plist noch die build.gradle manuell anfassen. Ein Config Plugin trägt die nötigen Bluetooth-Berechtigungen in die Info.plist ein und erhöht bei Bedarf die minSdkVersion in der build.gradle, und EAS Build übernimmt diese Änderungen bei jedem Cloud-Build automatisch, egal ob der Build lokal ausgelöst oder über CI angestoßen wurde.

// app.config.js: environment-specific values read at build time,
// resolved from the profile's env block in eas.json
const APP_ENV = process.env.APP_ENV || "development";

const variants = {
  development: { name: "Mironsoft Demo (Dev)", bundleIdentifier: "de.mironsoft.demo.dev" },
  preview: { name: "Mironsoft Demo (Preview)", bundleIdentifier: "de.mironsoft.demo.preview" },
  production: { name: "Mironsoft Demo", bundleIdentifier: "de.mironsoft.demo" },
};

export default ({ config }) => ({
  ...config,
  name: variants[APP_ENV].name,
  ios: { ...config.ios, bundleIdentifier: variants[APP_ENV].bundleIdentifier },
  android: { ...config.android, package: variants[APP_ENV].bundleIdentifier },
  plugins: [
    "expo-router",
    ["react-native-ble-plx", { isBackgroundEnabled: true }],
    "./plugins/withCustomEntitlements",
  ],
  extra: {
    eas: { projectId: "00000000-0000-0000-0000-000000000000" },
  },
});

Ein konkretes Beispiel für den iOS-Teil eines Config Plugins: Statt die Info.plist nach jedem EAS Build-Prebuild von Hand nachzubearbeiten, trägt das Plugin withInfoPlist zusätzliche Schlüssel wie Background Modes oder Associated Domains direkt in app.json ein. Die folgenden Werte landen unverändert in der generierten Info.plist des nativen iOS-Projekts, bevor der eigentliche Compiler-Lauf beginnt.

{
  "expo": {
    "ios": {
      "bundleIdentifier": "de.mironsoft.demo",
      "infoPlist": {
        "UIBackgroundModes": ["fetch", "remote-notification"],
        "NSAppTransportSecurity": {
          "NSAllowsArbitraryLoads": false
        },
        "com.apple.developer.associated-domains": ["applinks:mironsoft.de"]
      },
      "entitlements": {
        "aps-environment": "production"
      }
    }
  }
}

Für Android greift dasselbe Prinzip auf Gradle-Ebene. Erfordert ein natives Modul, etwa eine Bluetooth-Bibliothek, eine höhere minSdkVersion oder zusätzliche ABI-Filter, injiziert ein Config Plugin über withAppBuildGradle den passenden Codeblock direkt in die generierte build.gradle. Ein Entwickler muss diese Datei dafür nie manuell öffnen, da EAS Build sie bei jedem Cloud-Build ohnehin neu aus app.json und den registrierten Plugins erzeugt.

// android/app/build.gradle: generated during prebuild, values injected
// by a config plugin using withAppBuildGradle (not hand-edited)
android {
    defaultConfig {
        applicationId "de.mironsoft.demo"
        // Bumped from the template default because a native BLE module
        // requires BluetoothLeScanner APIs only available from API 21+
        minSdkVersion 21
        targetSdkVersion 34

        ndk {
            // Limit native library packaging to the ABIs EAS Build
            // actually needs to test on, reducing final app size
            abiFilters "arm64-v8a", "armeabi-v7a"
        }
    }
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile("proguard-android-optimize.txt"), "proguard-rules.pro"
        }
    }
}

6. Build Triggers: lokal eas build versus CI-Pipeline

Ein EAS Build lässt sich auf zwei grundsätzlich unterschiedliche Arten auslösen. Der lokale Weg ist der interaktive Terminal-Befehl eas build --profile preview --platform ios, den ein Entwickler direkt aus dem Projektverzeichnis heraus startet. Der Quellcode wird dabei komprimiert zu Expos Build-Servern hochgeladen, dort in einer isolierten Umgebung kompiliert, und der fertige Build-Link erscheint nach Abschluss im Terminal und im Expo-Dashboard. Dieser Weg eignet sich hervorragend für schnelle, ad-hoc ausgelöste Testbuilds während der aktiven Entwicklung.

Der zweite Weg bindet EAS Build in eine CI-Pipeline ein, etwa GitHub Actions oder GitLab CI. Statt eines interaktiven Terminal-Aufrufs läuft derselbe eas build-Befehl mit dem Flag --non-interactive in einem CI-Job, ausgelöst durch einen Git-Push, einen Merge in den main-Branch oder einen manuellen Workflow-Dispatch. Der CI-Runner selbst muss dafür keinerlei native Toolchain installieren - er ruft lediglich die EAS CLI auf, die den eigentlichen Build-Auftrag an die EAS-Infrastruktur delegiert und auf das Ergebnis wartet. Das reduziert die CI-Konfiguration auf wenige Zeilen, unabhängig davon, wie komplex die native Konfiguration des React Native Projekts selbst ist.

Für Teams, die beide Wege parallel nutzen, empfiehlt sich eine klare Konvention: development- und preview-Builds werden meist lokal von Entwicklern bei Bedarf ausgelöst, während production-Builds ausschließlich über die CI-Pipeline laufen, damit jeder Store-Release nachvollziehbar an einen bestimmten Commit und einen automatisierten, protokollierten EAS Build-Lauf gebunden ist, statt an eine manuelle Aktion auf einem einzelnen Entwicklerrechner.

7. Vom Build zum Store: eas submit

Ist ein production-Build mit distribution store erfolgreich abgeschlossen, übernimmt eas submit den letzten Schritt: das Hochladen des fertigen .ipa- beziehungsweise .aab-Artefakts zu App Store Connect beziehungsweise zur Google Play Console. Ohne EAS Build und eas submit müsste dieser Schritt entweder manuell über Xcode beziehungsweise die Play Console Weboberfläche erfolgen, oder über ein separates Tool wie Fastlane deliver, das eigene Zugangsdaten und eine eigene Konfiguration benötigt.

Der submit-Block in eas.json wird pro Profil konfiguriert und referenziert typischerweise einen App Store Connect API Key für iOS beziehungsweise ein Service-Account-JSON für Android, beide sicher als EAS Secret hinterlegt statt im Klartext im Repository. Damit lässt sich eas submit --platform ios --latest direkt im Anschluss an einen erfolgreichen production-Build ausführen und automatisch den zuletzt erzeugten Build einreichen, ohne die Build-ID manuell nachschlagen zu müssen. Für Android kann eas submit zusätzlich festlegen, in welche Testschiene der Play Console der Build wandert, etwa internal testing oder production mit gestaffeltem Rollout-Prozentsatz.

Der praktische Effekt: Ein vollständiger Release-Zyklus, von einem Git-Tag über einen automatisierten EAS Build-Lauf bis zur Einreichung bei Apple und Google, lässt sich als einzige CI-Pipeline abbilden, ohne dass jemand manuell ein Artefakt herunterladen und anschließend erneut hochladen muss. Die eigentliche Metadaten-Pflege im App Store Connect Eintrag selbst, also Screenshots, Beschreibungstexte und Privacy-Angaben, bleibt davon unberührt und ein separater, meist seltener wiederholter Vorgang.

8. Warum EAS Build den klassischen Expo Build und Bare-Xcode-Workflow ablöst

Vor der Einführung von EAS Build bot Expo einen älteren, mittlerweile abgeschalteten Dienst namens Classic Expo Build (expo build:ios / expo build:android). Dieser Dienst war stark eingeschränkt: Er unterstützte kein Config-Plugin-System für native Module, keine benannten Build-Profile, und Credentials wurden über einen weniger transparenten, teilweise manuell zu bestätigenden Prozess verwaltet. Sobald ein Projekt eigenen nativen Code außerhalb der damals unterstützten Expo-APIs benötigte, musste komplett auf den Bare Workflow mit lokalem Xcode- und Android-Studio-Build gewechselt werden - ein Bruch, der viele Teams zwang, zwei völlig unterschiedliche Build-Systeme zu pflegen.

Der Bare-Workflow-Ansatz mit rein lokalen Builds funktioniert zwar auch für React Native Apps mit beliebigem nativem Code, verlagert aber jede der zuvor beschriebenen Herausforderungen zurück ins Team: Jeder Entwickler braucht einen Mac für iOS-Builds, jede Toolchain-Version muss synchron gehalten werden, und CI-Pipelines benötigen eigene, gewartete Mac-Runner. EAS Build schließt genau diese Lücke, indem es Config Plugins, benannte Build-Profile und automatisiertes Credentials-Management mit voller Unterstützung für beliebigen nativen Code kombiniert - auch Projekte mit umfangreichen eigenen nativen Modulen laufen heute über denselben Cloud-Build-Dienst, ohne auf einen rein lokalen Workflow zurückfallen zu müssen.

9. Bare Workflow, Classic Expo Build und EAS Build im Vergleich

Die folgende Übersicht stellt die drei Ansätze nebeneinander, die ein React Native Team historisch und aktuell für iOS- und Android-Builds zur Auswahl hat oder hatte. Sie zeigt, warum EAS Build für die meisten neuen Expo-Projekte inzwischen die Standardwahl ist.

In der Praxis bedeutet diese Gegenüberstellung: Der Bare Workflow mit rein lokalen Builds bleibt eine valide Option für Teams mit sehr spezifischen, exotischen nativen Anforderungen und bestehender Mac-Infrastruktur, verursacht aber laufenden Wartungsaufwand. Classic Expo Build ist als abgeschalteter Dienst keine Option mehr für neue Projekte. EAS Build vereint die Flexibilität des Bare Workflow mit der Automatisierung, die frühere Managed-Workflow-Nutzer bereits von Classic Expo Build kannten, und ist deshalb für nahezu jedes neue React Native und Expo Projekt der pragmatischste Ausgangspunkt.

10. Zusammenfassung

EAS Build verlagert den kompletten iOS- und Android-Kompilierungsschritt für React Native und Expo Apps in die Cloud und beseitigt damit die drei größten praktischen Hürden lokaler Builds: die Mac-Pflicht für iOS, die Setup-Drift zwischen Entwicklerrechnern und den Aufwand für eigene CI-Build-Server. Über eas.json lassen sich benannte Build-Profile für development, preview und production mit eigenen Umgebungsvariablen, eigener Distributionsart und eigenen nativen Einstellungen definieren, während EAS Secrets sensible Werte verschlüsselt und außerhalb des Repositorys hält.

iOS-Zertifikate, Provisioning Profiles und Android-Keystores werden von EAS Build automatisch erzeugt, verlängert und verwaltet, bleiben über eas credentials aber jederzeit einsehbar und exportierbar. Config Plugins übertragen native Anforderungen deklarativ in generierte Xcode- und Gradle-Projekte, sodass auch Projekte mit eigenem nativen Code vollständig über denselben Cloud-Build-Dienst laufen. Mit eas submit endet die Pipeline direkt bei App Store Connect und der Google Play Console, wodurch ein kompletter Release-Zyklus ohne manuellen Download- und Upload-Schritt abgebildet werden kann.

11. FAQ: EAS Build für React Native