Ich habe rund zwanzig Jahre lang fürs Web gebaut. Native Apps habe ich lange links liegen lassen – nicht, weil sie mich nicht interessiert hätten, sondern wegen allem, was vor der ersten Zeile Code kommt.
Xcode installieren. Ein Developer-Konto anlegen. Zertifikate erzeugen, Provisioning Profiles zuordnen, verstehen, was der Unterschied zwischen beiden ist. Und dann die App irgendwie auf das eigene Telefon bekommen.
Das ist kein Programmieren. Das ist Verwaltung. Und sie steht am Anfang, also genau dort, wo die Motivation am dünnsten ist. Wie das ohne Hilfsmittel aussieht, habe ich später bei einer nativen iOS-App ausführlich erlebt.
Genau an dieser Stelle setzt Expo an. Deshalb finde ich die übliche Kurzbeschreibung – „ein Framework für React Native" – zwar nicht falsch, aber wenig hilfreich. Sie sagt nicht, wobei es einem tatsächlich hilft.
Expo ersetzt React Native nicht
Das ist der häufigste Anfängerirrtum, deshalb gleich vorweg.
React Native ist die Grundlage. Man schreibt TypeScript und React, und statt HTML im Browser entstehen daraus echte Bedienelemente des Betriebssystems. Kein eingebetteter Browser, keine nachgebaute Optik – ein Button ist ein echter Button.
Expo ist das, was drumherum liegt: Projekt-Setup, native Konfiguration, Bauen, Ausliefern, dazu eine große Sammlung fertiger Module für Dinge wie Kamera, Schriftarten oder verschlüsselte Speicherung.
Man tauscht also nicht das eine gegen das andere. Man benutzt beides gleichzeitig. In der offiziellen Dokumentation steht das ziemlich unmissverständlich: Das expo-Paket und sein Kommandozeilen-Werkzeug funktionieren mit jeder React-Native-App.
Ein Bild, das hinreichend trägt: React Native ist der Motor, Expo ist das Auto drumherum. Man kann einen Motor auch einzeln kaufen. Fahren möchte man damit eher nicht.
Was einem tatsächlich abgenommen wird
Der Anfang ist ein Befehl:
npx create-expo-app@latest meine-app
cd meine-app
npx expo start
Danach steht ein Projekt, das läuft. Kein Xcode, kein Android Studio, keine Zertifikate. Auf dem Telefon scannt man einen QR-Code, und die App ist da.
Das ist der sichtbare Teil. Der interessantere liegt darunter.
Die nativen Projekte sind kein Quellcode mehr
Eine native App braucht ein iOS- und ein Android-Projekt: Info.plist, AndroidManifest.xml, Build-Konfiguration, Berechtigungen. Klassischerweise liegen diese Ordner im Repository und werden von Hand gepflegt.
Expo dreht das um. Das Prinzip heißt Continuous Native Generation, und es bedeutet: Die Ordner ios/ und android/ werden bei Bedarf erzeugt, aus einer Konfigurationsdatei und einer Handvoll Plugins. In neu angelegten Projekten stehen sie sogar in der .gitignore – sie sind Bauergebnis, nicht Quelle.
Gepflegt wird stattdessen die Beschreibung dessen, was anders sein soll:
{
"expo": {
"name": "Meine App",
"plugins": [
["expo-camera", { "cameraPermission": "Für das Scannen von Barcodes." }]
]
}
}
Ein solches Config Plugin schreibt beim Erzeugen der nativen Projekte an die richtigen Stellen – hier den Berechtigungstext in die Info.plist und den passenden Eintrag ins Android-Manifest. Man muss nicht wissen, wo diese Stellen sind.
Der Preis dafür steht in der Dokumentation als Warnung: Wer die erzeugten Ordner von Hand ändert, riskiert, die Änderungen beim nächsten Durchlauf zu verlieren. Das ist kein Fehler, das ist die Idee. Konfiguration statt Nachbearbeitung.
Zwei Arten, die App auf das Telefon zu bekommen
Hier stolpern viele, weil zwei ähnlich klingende Dinge nebeneinander existieren.
Expo Go ist eine fertige App aus dem Store. Sie enthält einen festen Satz nativer Module und kann darin fremde Projekte ausführen. Zum Ausprobieren großartig, aber begrenzt: Was nicht eingebaut ist, kann man nicht benutzen.
Ein Development Build ist die Alternative für echte Projekte. Vereinfacht gesagt: die eigene Version von Expo Go, gebaut aus dem eigenen Projekt, mit genau den nativen Bibliotheken, die man tatsächlich braucht. Bedienung und Komfort sind gleich – Änderungen am TypeScript-Code sind weiterhin sofort auf dem Gerät. Neu gebaut werden muss nur, wenn sich etwas Natives ändert.
Für ernsthafte Projekte ist das der Normalfall. Expo Go ist die Probefahrt.
Bauen und Ausliefern
Zwei weitere Bausteine sind optional, aber der Grund, warum viele bei Expo bleiben.
EAS Build baut die App in der Cloud. Praktisch heißt das: Man kann eine iOS-App bauen lassen, ohne einen Mac vor sich zu haben, und der ganze Zertifikatskram wird verwaltet, statt erklärt.
EAS Update schiebt Änderungen am JavaScript-Teil direkt auf installierte Geräte, an der Store-Prüfung vorbei. Ein Textfehler oder ein falsch berechneter Wert ist damit in Minuten draußen statt in Tagen. Wichtig ist die Grenze: Änderungen an nativem Code gehen so nicht. Dafür braucht es einen neuen Build und den regulären Weg über den Store.
Beides sind eigene Dienste von Expo mit eigener Preisstruktur, und beides ist nicht verpflichtend – die Werkzeuge selbst sind quelloffen, bauen und ausliefern kann man auch in der eigenen Infrastruktur.
Was schon eingebaut ist
Statt einer Featureliste drei Dinge, die ich täglich benutze.
Die Navigation liegt im Dateisystem. Wer Next.js kennt, kennt das Prinzip: Eine Datei im richtigen Ordner ist eine Route.
app/
_layout.tsx
index.tsx → /
articles/
index.tsx → /articles
[id].tsx → /articles/42
Keine Routen-Tabelle, die man parallel pflegt und die irgendwann nicht mehr zum Ordnerinhalt passt. Die eckigen Klammern markieren einen variablen Teil, und in der Datei kommt man an ihn heran:
import { useLocalSearchParams } from 'expo-router'
export default function ArticleScreen() {
const { id } = useLocalSearchParams<{ id: string }>()
// ...
}
Schriftarten, Kamera, Bilder, Standort kommen als einzeln installierbare Module, die zusammen mit dem Rest aktualisiert werden. Das klingt banal, ist aber der Unterschied zwischen „ich binde eine Schrift ein" und „ich lege eine Datei in ein natives Verzeichnis und trage sie an drei Stellen ein".
Zugangsdaten liegen dort, wo sie hingehören. Ein Anmelde-Token gehört nicht in den normalen Speicher der App. Mit expo-secure-store landet er im Schlüsselbund des Betriebssystems – auf iOS in der Keychain, auf Android im Keystore:
import * as SecureStore from 'expo-secure-store'
await SecureStore.setItemAsync('session', token)
const stored = await SecureStore.getItemAsync('session')
Zwei Zeilen für etwas, das man sonst pro Plattform einzeln lösen müsste.
Der Einwand, den es so nicht mehr gibt
Wer sich vor zwei, drei Jahren zu Expo umgehört hat, ist zuverlässig auf einen Satz gestoßen: Mit Expo kommst du an nativen Code nicht ran, und wenn du ihn brauchst, musst du „ejecten" – einmal und unwiderruflich.
Das stimmte einmal. Heute nicht mehr, und zwar ziemlich deutlich.
Der Befehl expo eject wurde mit SDK 46 im August 2022 vollständig entfernt. Auch der Begriff ist verschwunden: In der offiziellen FAQ steht inzwischen wörtlich, „eject" sei ein veralteter Begriff und nicht mehr nötig. Die alte Zweiteilung in „managed" und „bare workflow" taucht in der aktuellen Dokumentation nicht mehr als Hauptunterscheidung auf.
An ihre Stelle ist die Frage getreten, ob man die nativen Projekte erzeugen lässt oder selbst pflegt. Und dazwischen liegt keine Einbahnstraße mehr, sondern ein Schalter.
Konkret gibt es heute vier Wege zu nativem Code, und keiner davon ist ein Ausstieg:
- Eine Bibliothek mit nativem Anteil installieren und den Development Build neu erzeugen.
- Ein Config Plugin schreiben, das beim Erzeugen die nativen Dateien anpasst.
- Ein eigenes natives Modul schreiben – die Dokumentation beschreibt das als vorgesehenen Weg, nicht als Notausgang.
- Die Ordner
ios/undandroid/doch ins Repository legen und selbst pflegen. Dann verzichtet man auf das automatische Erzeugen und benutzt den Rest weiter.
Ehrlich bleiben muss man trotzdem: Kostenlos ist das nicht. Jede native Abhängigkeit bedeutet einen neuen Build. Und für Bibliotheken, die kein Config Plugin mitbringen, schreibt man es selbst – das ist überschaubar, aber es ist Arbeit, die man vorher nicht hatte.
Wo Expo aufhört
Der ehrlichste Test für ein Werkzeug ist nicht die Liste dessen, was es kann. Es ist das Projekt, bei dem es nicht geholfen hätte. Ich habe so eins.
Eine kleine App gegen Doom-Scrolling, die ich vor einer Weile gebaut habe, hing mit ihrer Hauptfunktion an Apples Screen-Time-Schnittstelle. Und die existiert ausschließlich in nativen Erweiterungen, die außerhalb der eigentlichen App laufen. Kein plattformübergreifendes Werkzeug nimmt einem das ab, Expo auch nicht.
Machbar wäre es gewesen: ein eigenes natives Modul, ein Config Plugin drumherum. Nur hätte ich damit Swift geschrieben und zusätzlich die Konfiguration gepflegt, die den Swift-Teil in die erzeugten Projekte bringt. Zwei Ebenen statt einer – für genau die Funktion, um die es in der App überhaupt ging.
Daraus ist meine Faustregel geworden. Die Frage ist nicht, ob man nativen Code braucht; den braucht man früher oder später fast immer. Die Frage ist, ob er im Kern der App sitzt oder an ihrem Rand. Am Rand ist Expo bequem. Im Kern zahlt man doppelt.
Drei weitere Grenzen, kürzer:
Wer seine iOS- und Android-Projekte seit Jahren von Hand pflegt, sollte das automatische Erzeugen nicht anwerfen. Die Dokumentation warnt ausdrücklich davor, weil manuelle Anpassungen dabei verloren gehen. Einzelne Expo-Bausteine lassen sich trotzdem nachrüsten.
Wo der Build das Haus nicht verlassen darf, fällt der bequemste Teil weg. Selbst bauen ist möglich, aber ein guter Teil des Komforts steckt genau in dem Dienst, den man dann nicht nutzt.
Und wenn es nur eine Plattform gibt und das Team ohnehin nativ arbeitet, bezahlt man eine Abstraktion, von der niemand etwas hat.
Bleibt ein Punkt, der im Alltag schwerer wiegt, als er klingt: Man bindet sich an einen fremden Veröffentlichungsrhythmus. Man aktualisiert, wenn Expo aktualisiert, nicht wenn es einem selbst passt. Fairerweise hat sich das zuletzt entspannt – die aktuelle SDK-Version bringt React Native 0.86 mit, React bleibt unverändert, und der Sprung war ausdrücklich ohne Brüche geplant. Ein Upgrade ist im Wesentlichen ein Befehl. Aber der Takt wird woanders vorgegeben.
Was Expo nicht ändert
Damit kein falscher Eindruck entsteht: Die App-Prüfung im Store wird davon nicht freundlicher. Die Eigenheiten der beiden Plattformen muss man trotzdem lernen – wie sich Navigation anfühlen soll, wann ein Bildschirm eine eigene Route verdient, warum dieselbe Anordnung auf Android falsch aussieht. Und eine App, die sich gut anfühlt, ist weiterhin Arbeit.
Expo verschiebt nur, wann man das lernt. Nicht mehr vorher, als Eintrittspreis, sondern dann, wenn man es tatsächlich braucht.
Genau darin lag für mich der Unterschied. Früher stand die Verwaltung am Anfang und das Bauen danach – wer an einem Abend eine Idee ausprobieren wollte, hat den Abend mit Zertifikaten verbracht. Heute steht die Idee am Anfang, und der ganze Rest kommt erst, wenn es wirklich in den Store gehen soll.
Für meine Ernährungs-App war das der Grund, bei Expo zu bleiben – und es ist bis heute mein Standard, wenn ich Apps für iOS und Android baue. Nicht, weil es alles kann. Sondern weil mich nichts davon am ersten Abend aufgehalten hat.
Expo macht das Bauen einer App nicht einfach. Es macht das Anfangen einfach – und daran scheitern die meisten Ideen, lange bevor es schwierig wird.