Expo-Entwickler für EAS Build und OTA-Updates
Ich arbeite täglich mit Expo: Builds in die Cloud holen, Korrekturen over the air ausliefern, liegen gebliebene SDK-Sprünge nachholen und die Navigation auf Expo Router bringen, ohne das Projekt neu aufzusetzen.
- Expo SDK
- EAS Build
- Expo Router
- TypeScript
- OTA-Updates
Gebaut für Teams mit einer laufenden Expo-App
Typisch ist eine App, die mit Expo gestartet ist und jetzt Fragen stellt, die der Managed Workflow allein nicht beantwortet: ein Build, der nur auf einem bestimmten Laptop durchläuft, ein SDK-Sprung, der seit zwei Versionen liegen bleibt, ein Release ohne festen Ablauf. Geht es weniger um Expo selbst als um die App darunter, ist der React-Native-Entwickler die passendere Seite: bestehende App übernehmen, Brücken zu nativem Code, Performance.
Wo Expo-Projekte stehen bleiben
Die App läuft, aber der Weg von der Änderung bis auf das Gerät der Nutzer ist der Engpass. Fast immer liegt es an einer dieser Stellen.
Der Build hängt an einem Rechner
Releases entstehen in einer lokalen Xcode- und Android-Studio-Installation. Fällt der Rechner aus oder wechselt die Person, steht die Auslieferung.
Das SDK-Upgrade wird verschoben
Jede ausgelassene Expo-SDK-Version macht den nächsten Sprung größer, weil Abhängigkeiten, Build-Tools und native Module gleichzeitig nachziehen müssen.
Jeder Tippfehler braucht ein Review
Eine Textkorrektur wartet auf die Store-Freigabe, obwohl kein nativer Code betroffen ist. Genau dafür gibt es Updates over the air.
Die Navigation ist gewachsen
Screens liegen in zwei Systemen nebeneinander, Deep Links treffen den falschen Bildschirm, und niemand kann sagen, welche Route wohin gehört.
Eine native Bibliothek fehlt
Die eine Funktion, die der Managed Workflow nicht vorsieht, blockiert ein ganzes Feature. Config Plugins und Prebuild sind der Weg daran vorbei.
Die Credentials sind verstreut
Zertifikate, Provisioning Profiles und Keystore liegen in privaten Ordnern. Beim ersten Wechsel im Team wird ein Release zur Suchaktion.
Was ich an einer Expo-App mache
Einzeln buchbar oder zusammen. Geht es nicht um Expo-Eigenheiten, sondern um eine App, die es noch gar nicht gibt, steht der Rahmen dafür auf App-Entwicklung.
EAS Build
Builds laufen in der Cloud statt auf einem Laptop. Credentials liegen zentral, und jeder im Team kann einen Release anstoßen.
EAS Submit
Der fertige Build geht automatisch an App Store Connect und in die Play Console, inklusive Spur für TestFlight und internes Testing.
Over-the-air-Updates
Änderungen an JavaScript und Assets erreichen installierte Apps ohne Store-Review. Getrennte Kanäle für Test und Produktion, mit Weg zurück auf den letzten Stand.
Expo Router
Dateibasierte Navigation mit typisierten Routen, Deep Links und geteilten Layouts. Auch als Umbau von React Navigation auf Expo Router.
SDK-Upgrades
Sprung auf die aktuelle Expo-SDK-Version samt Abhängigkeiten, in nachvollziehbaren Schritten und mit Testlauf auf beiden Plattformen.
Config Plugins und Prebuild
Native Einstellungen und Bibliotheken werden beschrieben statt in Xcode geklickt. Jeder Prebuild erzeugt danach dasselbe Ergebnis.
Vom ersten Blick zum reproduzierbaren Release
Nach der Übergabe läuft es entweder bei dir weiter oder als laufende Betreuung, monatlich statt projektweise.
Bestandsaufnahme
Ich sehe mir Repository, app.json, eas.json und den letzten Build an und schreibe auf, was die Auslieferung heute aufhält.
Reihenfolge festlegen
Was zuerst: Build-Pipeline, SDK-Sprung oder Navigation. Jeder Schritt bekommt einen Umfang, damit nichts zur Dauerbaustelle wird.
Umsetzung in Schritten
Änderungen laufen über Pull Requests, jeder Schritt endet in einem Build. Du hast nach jedem Schritt eine installierbare Version.
Übergabe
Pipeline, Update-Kanäle und Credentials sind dokumentiert und liegen in euren Konten. Kein Wissen bleibt bei mir hängen.
Sag mir, wo die App gerade klemmt
Ein Absatz reicht: welche Expo-SDK-Version im Einsatz ist, wie gebaut wird und was zuletzt nicht funktioniert hat. Du bekommst eine Einschätzung, was zuerst dran ist, statt eines Verkaufsgesprächs.
Fragen zu Expo-Projekten
Ja, das ist eine abgegrenzte Aufgabe. Vorher schaue ich nach, wie viele Versionen dazwischenliegen und welche nativen Module betroffen sind. Danach sage ich dir, ob das eher ein Tag oder eher zwei Wochen werden, bevor du zusagst.
Alles, was in JavaScript und in den Assets liegt, geht über EAS Update direkt an installierte Apps. Neuer nativer Code, also ein neues SDK oder eine neue native Bibliothek, braucht weiterhin einen Store-Build. Deshalb trennt man beides sauber: kleine Korrekturen over the air, größere Sprünge über den Store.
Nein. Über Config Plugins und Prebuild bleibt die native Konfiguration generiert und trotzdem anpassbar. Erst wenn das nicht mehr reicht, werden die Ordner ios und android dauerhaft eingecheckt. Diesen Schritt gehe ich erst, wenn ein Feature ihn wirklich verlangt, denn der Rückweg ist aufwendig.
Ja. Neben React Native und Expo arbeite ich mit Kotlin und Jetpack Compose für natives Android. Das hilft, wenn ein Problem unterhalb der JavaScript-Ebene liegt und jemand in den nativen Build schauen muss.
Mit Lesezugriff auf das Repository und einem Build, den ich einmal selbst durchlaufen lasse. Erst danach sage ich, was ich ändern würde. Eine Schätzung ohne Blick ins Projekt wäre geraten.
Ja. Eine kaputte Build-Konfiguration, ein hängendes Store-Release oder ein einzelnes Config Plugin gehen stundenweise. Wird daraus Regelmäßigkeit, ist die laufende Betreuung der ruhigere Weg für beide Seiten.
Lass uns gemeinsam etwas Großartiges bauen.
Hast du ein Projekt im Kopf? Ich würde gerne davon hören. Schick mir eine Nachricht und ich melde mich so schnell wie möglich.
