EAS Build ist der gehostete Dienst von Expo Application Services, der ein Expo- oder React-Native-Projekt in installierbare Binärdateien verwandelt: eine .aab- oder .apk-Datei für Android, eine .ipa-Datei für iOS. Sie führen einen Befehl aus, das Projekt wird hochgeladen, eine frische Cloud-Maschine kompiliert und signiert es, und Sie laden das Ergebnis herunter oder schicken es direkt an die Stores. Deshalb können Sie einen iPhone-Build auch von einem Windows-Laptop aus erstellen.
Zum Preis die kurze Antwort: Der Free-Plan deckt bis zu 15 Android- und 15 iOS-Builds pro Monat in einer Warteschlange mit niedriger Priorität ab. Die kostenpflichtigen Pläne beginnen bei 19 USD pro Monat (Starter, mit 45 USD Build-Guthaben) und 199 USD pro Monat (Production, mit 225 USD Guthaben), und jeder Build über das Guthaben hinaus kostet je nach Plattform und Maschinengröße 1 bis 4 USD. Diese Zahlen stammen von der Preisseite von Expo, abgerufen am 13. Oktober 2026.
Dieser Leitfaden konzentriert sich auf den Build-Dienst. Für das Gesamtbild des Frameworks, seines SDK und seines Routers lesen Sie zuerst, was Expo ist.
Was EAS Build leistet und was nicht
Die Definition von Expo ist knapp: EAS Build ist „ein gehosteter Dienst zum Erstellen von App-Binärdateien für Ihre Expo- und React-Native-Projekte“. Er baut auch reine native Projekte, die weder Expo noch React Native nutzen, doch seine Standardeinstellungen sind auf Expo-Apps abgestimmt, sodass die meisten Projekte keine zusätzliche Konfiguration brauchen.
Konkret übernimmt ein Build vier Aufgaben, die von Hand mühsam einzurichten sind:
- Eine saubere Build-Maschine. Jeder Build bekommt eine eigene virtuelle Maschine mit bereits installierter Toolchain: das Android SDK unter Linux, Xcode unter macOS.
- Signatur. EAS kann Ihren Android-Keystore, Ihr iOS-Distributionszertifikat und Ihre Provisioning-Profile erzeugen und speichern oder die verwenden, die Sie selbst bereitstellen.
- Reproduzierbare Einstellungen. Build-Profile in einer eas.json-Datei beschreiben jede Art von Build, sodass derselbe Befehl auf jedem Laptop und in der CI dasselbe Ergebnis liefert.
- Verteilung. Ein fertiger Build lässt sich per URL mit Testern teilen oder für die Stores an EAS Submit übergeben.
Was er nicht leistet: Ihren Store-Eintrag schreiben, Screenshots erstellen oder die App für die Öffentlichkeit freigeben. Diese Schritte bleiben in App Store Connect und der Play Console.
Build, Submit, Update: drei verschiedene Dienste
EAS ist eine Familie von Diensten, die oft verwechselt werden. Nur einer davon kompiliert überhaupt etwas.
| Dienst | Was er tut | Was Sie erhalten |
|---|---|---|
| EAS Build | Kompiliert und signiert die native App auf einer Cloud-Maschine | Eine .aab-, .apk- oder .ipa-Datei sowie die Build-Logs |
| EAS Submit | Lädt eine fertige Binärdatei zu Google Play oder App Store Connect hoch | Ein Release in einem Play-Track oder einen Build, der in TestFlight wartet |
| EAS Update | Schickt Änderungen an JavaScript und Assets an bereits installierte Apps | Einen Fix auf den Handys der Nutzer ohne neues Store-Release |
So läuft ein EAS-Build ab, Schritt für Schritt
Sie brauchen Node.js, die EAS CLI und ein kostenloses Expo-Konto. Danach sieht der Weg vom Code in den Store so aus:
- Einmal konfigurieren. Der Befehl eas build:configure legt eas.json im Stammverzeichnis des Projekts an, neben package.json.
- Einen Build starten. eas build --platform android (oder ios, oder all) verwendet standardmäßig das Profil production; mit --profile preview wählen Sie ein anderes.
- Credentials. Die CLI prüft die Signatur-Credentials und bietet beim ersten Mal an, fehlende zu erzeugen.
- Upload und Warteschlange. Das Projekt wird archiviert und hochgeladen, dann wartet der Build in der Warteschlange Ihres Plans auf eine freie Maschine.
- Kompilieren auf einer frischen Maschine. Die Maschine installiert die Abhängigkeiten, erzeugt die nativen Projekte, kompiliert und signiert die App. Die Logs laufen live im Expo-Dashboard mit.
- Die Datei abholen. Laden Sie die Datei herunter, teilen Sie sie per Installationslink oder lassen Sie EAS Submit den Upload erledigen, entweder nachträglich mit eas submit oder im selben Durchlauf mit --auto-submit.
Build-Profile in eas.json
Ein Profil ist ein benannter Satz von Build-Einstellungen. Die Datei, die eas build:configure erzeugt, enthält drei davon:
{
"build": {
"development": {
"developmentClient": true,
"distribution": "internal"
},
"preview": {
"distribution": "internal"
},
"production": {}
}
}| Profil | Für wen | Typisches Ergebnis |
|---|---|---|
| development | Sie selbst beim Programmieren: ein Development Build mit Entwicklerwerkzeugen (erfordert expo-dev-client), direkt auf Ihren Geräten installiert | APK oder Ad-hoc-Build für iOS; wird nie an einen Store übermittelt |
| preview | Ihr Team und Ihre Stakeholder, zum Testen unter produktionsnahen Bedingungen | APK oder Ad-hoc-Build für iOS, per URL geteilt |
| production | Die Stores, einschließlich TestFlight und der Test-Tracks von Play | AAB für Android (Standard), IPA für iOS |
Zwei Einstellungen tauchen häufig auf. "buildType": "apk" unter android macht aus der Ausgabe eines Profils eine direkt installierbare APK, genau das, was Sie für preview wollen. "resourceClass": "large" verlegt einen aufwendigen Build auf eine größere Maschine; medium ist der Standard, und large-Maschinen setzen einen kostenpflichtigen Plan voraus. Profile können außerdem mit "extends" voneinander erben, bis zu fünf Ebenen tief.
Credentials und Signatur
Jeder Build für die Stores muss signiert sein. Für Android bedeutet das einen Upload-Keystore; für iOS ein Distributionszertifikat und ein Provisioning-Profil, beide an Ihr Apple-Developer-Konto gebunden. EAS kann sie erzeugen und auf den Servern von Expo aufbewahren, sodass jede Maschine und jedes Teammitglied bauen kann, ohne Dateien herumzureichen. Sie können auch Ihre eigenen hochladen, was wichtig ist, wenn eine App bereits existiert: Google lehnt Updates ab, die mit einem anderen Upload-Schlüssel signiert sind, und die Play-App-Signatur bewahrt den endgültigen App-Signaturschlüssel bei Google auf.
Die Preise von EAS Build im Jahr 2026
Expo verkauft EAS nach Plänen, und jeder kostenpflichtige Plan enthält einen Dollarbetrag an Build-Guthaben. Der Free-Plan funktioniert anders: Er zählt Builds, keine Dollar.
| Plan | Preis pro Monat | Enthaltene Builds | Warteschlange | Gleichzeitige Builds | Maximale Build-Dauer |
|---|---|---|---|---|---|
| Free | 0 USD | Bis zu 15 Android- und 15 iOS-Builds | Niedrige Priorität | 1 | 45 Minuten |
| Starter | 19 USD plus Nutzung | 45 USD Build-Guthaben | Hohe Priorität | 1 | 2 Stunden |
| Production | 199 USD plus Nutzung | 225 USD Build-Guthaben | Hohe Priorität | 2 | 2 Stunden |
| Enterprise | Individuell, ab 1.000 USD | Anpassbar | Hohe Priorität | 5 | 2 Stunden |
Ist das Guthaben aufgebraucht, wird jeder Build zu einem Festpreis abgerechnet, der von Plattform und Maschine abhängt. Zusätzliche gleichzeitige Builds kosten in den kostenpflichtigen Plänen jeweils 50 USD pro Monat.
| Worker | Maschine | Preis pro Build |
|---|---|---|
| Android, medium | 4 vCPU, 16 GB RAM | 1 USD |
| Android, large | 8 vCPU, 32 GB RAM | 2 USD |
| iOS, medium | 5 Performance-Kerne, 20 GiB RAM | 2 USD |
| iOS, large | 10 Performance-Kerne, 40 GiB RAM | 4 USD |
Warteschlange und maximale Dauer
Für Einzelentwickler sind die eigentlichen Kosten des Free-Plans Zeit. Expo warnt, dass Sie zu Spitzenzeiten in der Warteschlange mit niedriger Priorität 90 Minuten und mehr warten können, während das Unternehmen in der Warteschlange mit hoher Priorität, die alle kostenpflichtigen Pläne nutzen, „null Wartezeit“ anstrebt. Außerdem muss der Build selbst im Free-Plan innerhalb von 45 Minuten fertig sein, in den kostenpflichtigen Plänen innerhalb von 2 Stunden; ein großes iOS-Projekt mit vielen nativen Modulen kann an diese Grenze heranreichen.
Was ein Monat Builds kostet
Drei typische Fälle, berechnet mit den obigen Tarifen auf medium-Maschinen (unsere Rechnung, keine Zahlen von Expo):
- Nebenprojekt, 10 Android- und 8 iOS-Builds: 0 USD im Free-Plan, wenn Sie mit der Warteschlange leben können.
- Kleines Team, 30 Android- und 20 iOS-Builds: 30 USD plus 40 USD, also 70 USD Nutzung. Das Guthaben von 45 USD im Starter-Plan deckt den Großteil ab, es bleiben 25 USD zusätzlich zum Abo von 19 USD: 44 USD für den Monat.
- Aktives Produkt, 100 Android- und 80 iOS-Builds: 100 USD plus 160 USD, also 260 USD Nutzung. Im Production-Plan bleiben nach 225 USD Guthaben 35 USD zusätzlich zu den 199 USD: 234 USD für den Monat.
large-Maschinen verdoppeln den Preis jedes Builds, wechseln Sie also nur für Builds dorthin, denen tatsächlich Speicher oder Zeit ausgeht. Builds, die über EAS Workflows gestartet werden, den CI-Dienst von Expo, werden zu denselben Festpreisen abgerechnet.
EAS Build oder lokaler Build?
Sie müssen die Cloud nicht nutzen. Es gibt zwei lokale Optionen: eas build --local, das denselben Build-Prozess auf Ihrem eigenen Rechner ausführt, und den klassischen Weg über Xcode und Android Studio ganz ohne EAS.
| Kriterium | EAS Build (Cloud) | eas build --local | Xcode / Android Studio |
|---|---|---|---|
| iOS unter Windows oder Linux | Ja | Nein, iOS erfordert einen Mac mit Xcode | Nein, Xcode läuft nur unter macOS |
| Unterstütztes System | Jeder Rechner mit Node.js | macOS und Linux; Windows nicht unterstützt (WSL ungetestet) | macOS für iOS; jedes System für Android |
| Einrichtung | EAS CLI und ein Expo-Konto | Android SDK und NDK, fastlane und CocoaPods für iOS, dazu ein Expo-Login | Vollständige native Toolchains, manuelle Signatur |
| Signatur | Von EAS verwaltet oder Ihre eigene | Kann verwaltete Credentials herunterladen | Komplett in Ihrer Verantwortung |
| Kosten | Kontingent oder Guthaben des Plans, danach 1 bis 4 USD pro Build | Ihre Hardware | Ihre Hardware |
| Wichtigste Einschränkungen | Warteschlange im Free-Plan, maximale Dauer je nach Plan | Nur eine Plattform gleichzeitig, kein Caching, Tool-Versionen aus eas.json werden ignoriert, geheime Variablen müssen lokal gesetzt werden | Keine gemeinsame Einrichtung im Team |
Eine einfache Faustregel: Bleiben Sie in der Cloud, solange Sie keinen Mac haben, solange mehrere Personen die App bauen oder solange das kostenlose Kontingent für Ihren Monat reicht. Wechseln Sie zu lokalen Builds, wenn Sie auf einem Mac viele Male am Tag an nativem Code iterieren, wenn die Unternehmensrichtlinien Build-Server von Drittanbietern verbieten oder um einen Fehler aus der Cloud auf Ihrem eigenen Rechner nachzustellen, genau wofür Expo --local empfiehlt. Die Dokumentation zu lokalen Builds listet die aktuellen Einschränkungen auf.
Vom Build in den Store, mit oder ohne Cadrant
Sobald die Binärdatei existiert, übernimmt EAS Submit den Upload. Unter Android schickt es die .aab-Datei in einen Play-Track (interner Test, Alpha, Beta oder Produktion) und kann sogar das erste Release einer ganz neuen App im internen Test-Track anlegen. Unter iOS schickt es die .ipa-Datei an App Store Connect, wo sie nach der Verarbeitung in TestFlight erscheint; Store-Eintrag und Einreichung zur Prüfung bleiben Handarbeit. Den Rest des Wegs in den Store, vom Entwicklerkonto bis zur Prüfung, finden Sie in unserem Leitfaden zum Thema App bei Google Play veröffentlichen.
Mit dem Mobile-App-Baukasten von Cadrant schreiben Sie nie eine eas.json und tippen nie einen Build-Befehl, doch kompiliert wird weiterhin von EAS Build, auf Ihrem eigenen Expo-Konto. Sie verbinden dieses Konto einmal unter Integrationen, und jede Veröffentlichung nutzt Ihr kostenloses EAS-Kontingent von 15 Android- und 15 iOS-Builds pro Monat. Unter Android erzeugt und verwahrt Cadrant den Upload-Keystore, und Expo übermittelt das App Bundle als Entwurfs-Release im internen Test-Track an Ihre Play Console. Unter iOS legt eine geführte Apple-Anmeldung die App in App Store Connect an und stellt das Distributionszertifikat bereit, dann übermittelt Expo die Binärdatei an Ihr Konto. Die Konten, das Kontingent und die Apps gehören weiterhin Ihnen.