Vor jeder App steht dieselbe reflexhafte Frage: nativ oder cross-platform? Und meist wird sie zu früh und zu grundsätzlich beantwortet.
Meine Kernthese aus der Praxis: Für den Großteil der Apps reicht Expo — schneller, günstiger, eine Codebase. Dazu kommt ein Punkt, der gern übersehen wird: Expo bringt Notifications und OTA-Updates gleich mit. Das ist Infrastruktur, die normalerweise nicht ohne Weiteres existiert und die sonst zusätzlichen technischen Overhead erzeugt — Overhead, den man erst sieht, wenn man ihn selbst bauen muss.
Warum Expo — und für wen
Es war keine Ideologie-Entscheidung, sondern Team-Realität. Es gab ein bis zwei Entwickler, und das Wissen lag eher bei React Native. Damit konnte faktisch ein Entwickler die App bauen und dabei iOS und Android abdecken. Die Expo-Dokumentation deckt die iOS- und Android-Fälle gut ab, die Entwicklung blieb dadurch relativ einfach.
Genau das ist die Auswahllogik für kleine Teams: nicht „was ist technisch am reinsten", sondern „wer kann das tragen". Eine Codebase, die eine Person über beide Plattformen pflegen kann, schlägt zwei native Stacks, für die das Team gar nicht da ist.
Was Expo eingelöst hat
Der konkrete Gewinn: eine Codebase plus EAS Build und Submit. Das hat die Time-to-Store deutlich vereinfacht — bauen und in beide Stores ausliefern aus einer Pipeline, statt zwei native Toolchains zu pflegen.
Der größte praktische Hebel war die Build-Infrastruktur selbst. Mit EAS pusht man den Code, und es wird gebaut — eine Build-Umgebung, die man nicht selbst betreiben muss. Was man dabei in Kauf nimmt: Der Build läuft dann bei Expo, der Code liegt dort. Wer das nicht will, kann lokal bauen und die fertigen Builds einreichen — der Weg bleibt offen. Aber die Bequemlichkeit, aus einer Konfiguration heraus beide Stores zu bedienen, ist genau der Punkt, der Time-to-Store senkt.
Im Kern ist das eine Datei:
// eas.json
{
"cli": { "version": ">= 5.0.0" },
"build": {
"preview": {
"distribution": "internal",
"ios": { "simulator": true }
},
"production": {
"autoIncrement": true,
"channel": "production"
}
},
"submit": {
"production": {}
}
}Den Hype muss man trotzdem einordnen. Web funktioniert mit Expo, wurde aber nicht genutzt — und ich würde es hier auch nicht empfehlen: Nutzer springen schnell auf „ist ja alles dasselbe" an, und diese Wahrnehmung kostet. OTA-Updates haben wir ebenfalls nicht eingesetzt, weil die Daten ohnehin aus der Backend-API kommen und der Nutzen damit dünn war. Die Lehre: Man nimmt die Teile von Expo, die passen — nicht alles, nur weil es mitgeliefert wird.
Wo es wehtat
Die erste teure Überraschung sind Bibliotheken. Eine Library, die im Web hervorragend ist, ist nicht automatisch eine gute Native-Bibliothek. Man stößt schnell auf Einschränkungen, und das sollte man von Anfang an einplanen. Manchmal ist die richtige Antwort eine lizenzpflichtige Bibliothek — Mapbox ist der Klassiker: solide, aber ein realer Kostentreiber, den man früh einpreisen muss.
Die zweite ist die Plattform-Differenz. iOS und Android laufen schneller auseinander, als „write once" suggeriert. Konkretes Beispiel: SQLite-Parallelität — Android beschränkt die gleichzeitigen Verbindungen, iOS nicht. Gleicher Code, anderes Verhalten; man findet das unter Last und auf die harte Tour. Das App-Store-Review verlief dagegen völlig problemlos — aber nur, weil die App keine Logins und keine Payments brauchte. Das sollte niemand auf seinen Fall verallgemeinern.
Wann doch nativ
Die klare Grenze: Nativ, wenn plattformspezifische Oberfläche dazukommt — Widgets, App-Clips, tiefere iOS- oder Android-spezifische Features. Ebenfalls nativ, wenn die App viel im Hintergrund aktiv sein soll oder Speicher- und Akkuverbrauch wirklich erste Priorität haben.
Expo kommt in vielen dieser Belange inzwischen erstaunlich nah heran. Aber „nah" ist nicht „da", wenn genau diese Dinge das Produkt sind.
Fazit
Für ein kleines Team, das eine normale Produkt-App für beide Stores baut, ist Expo meistens die richtige Wahl: eine Codebase, eine Person kann sie tragen, und Notifications- sowie OTA-Infrastruktur kommen mit, statt selbst zu eigenen Projekten zu werden. Nativ ist die bewusste Ausnahme für OS-tiefe oder ressourcenkritische Apps — nicht der Default.
Wenn bei Ihnen eine App ansteht und Sie sauber abwägen wollen, ob Cross-Platform trägt oder es nativ sein muss: Genau diese Einordnung — und die App-Entwicklung danach — ist Teil meiner Arbeit im Technical Consulting.