Planung eines Expo SDK 58-Updates: iOS 27, React Native 0.88 und neue Werkzeuge

Expo SDK 58 wird nicht durch eine einzige herausragende Funktion definiert. Stattdessen enthält es gleichzeitig eine lange Liste an Änderungen: Unterstützung für iOS 27, React Native 0.88, schnellere Android-Kompilierungen, günstigere Aufrufe von nativen Modulen, Widgets für den Android-Startbildschirm, Integration von Siri über App Intents, eine CLI zur Erstellung von Code-Agenten, ein weiterentwickelter Expo Router sowie ein experimenteller, auf Rust basierender Transformer für Metro. Diese Anleitung ordnet diese Liste nach ihrem praktischen Einfluss, damit Sie erkennen können, welche Änderungen Ihre Codebasis betreffen, welche kostenlos zur Verfügung stehen, welche noch experimentell sind und wie Sie den Upgrade ohne Beeinträchtigung einer Produktionsanwendung durchführen können.

Betrachten Sie SDK 58 als Beta-Version, denn das ist es auch

Zum Zeitpunkt der Erstellung befindet sich SDK 58 noch in der Beta-Phase, und Expo geht davon aus, dass diese Phase etwa drei bis vier Wochen andauern wird. Überprüfen Sie den Expo-Changelog auf den aktuellen Status, bevor Sie etwas in Bezug auf ein Veröffentlichungsdatum planen.

Eine Beta-Phase ist das ideale Zeitfenster für Tests: Ihr Anwendungscode, Bibliotheken Dritter, benutzerdefinierte native Module, der Build-Prozess sowie jeder manuell geschriebene Native-Code. Es ist kein guter Zeitpunkt, das SDK in einer Produktivanwendung kurz vor einem Wochenende zu aktualisieren. Für Nebenprojekte und interne Tools hingegen bietet die Beta eine risikofreie Möglichkeit, einen Einblick in zukünftige Entwicklungen zu gewinnen und Probleme frühzeitig aufzudecken, solange noch Zeit besteht, sie im Quellcode zu beheben.

iOS 27 und der auf Szenen basierende Lebenszyklus

Ein großer Teil der Motivation für SDK 58 ist iOS 27. Apps, die mit dem iOS 27 SDK kompiliert werden, nutzen Apples auf Szenen basierenden Lebenszyklus, und Expo hat seine native Infrastruktur entsprechend diesem Modell umgestaltet.

Ein wenig Hintergrundwissen hilft hier. Im älteren Modell hatte UIApplicationDelegate die Kontrolle über die gesamte App: ein Fenster sowie eine Reihe von Start- und Vordergrund-Aufrufen. Das Szenenmodell teilt diese Verantwortlichkeiten auf, sodass jede UI-Instanz (eine Szene) ihren eigenen Lebenszyklus hat, der von einem Szenenbeauftragten verwaltet wird. Aufgaben, die früher beim App-Beauftragten lagen – wie die Reaktion auf das Aktivwerden der App oder die Verarbeitung eingehender URLs – können nun zu Szenen-Ebene-Aufrufen verschoben werden.

In einem typischen Expo-Projekt sollte dieser Übergang unsichtbar bleiben. Er spielt eine Rolle, wenn man die native Seite angepasst hat. Ein häufiges Beispiel sind zusätzliche Einstellungen innerhalb des Start-Aufrufs des App-Beauftragten, wie die unten stehende Swift-Methode (hier ohne Syntax-Highlighting dargestellt):

func application(
  _ application: UIApplication,
  didFinishLaunchingWithOptions launchOptions:
  [UIApplication.LaunchOptionsKey: Any]?
) -> Bool {
  // Custom initialization
  return true
}

Falls Ihre AppDelegate.swift umfangreiche benutzerdefinierte Logik enthält, könnte ein Teil davon nun der Szenenverwaltung zugeordnet werden anstelle eines einzigen globalen Anwendungsfensters. Expo empfiehlt, die Leitlinien zur Migration des Szenenlebenszyklus zu lesen, wenn Sie den nativen App-Delegate ändern.

Welche Projekte erfordern eine genaue Prüfung

Viele Expo-Apps rufen niemals AppDelegate.swift auf, und für sie sollte die Migration problemlos verlaufen. Größere Apps sammeln im Laufe der Jahre jedoch tendenziell mehr native Code an – genau hier liegt das Risiko. Prüfen Sie sorgfältig, ob Ihr iOS-Projekt eine native Einrichtung für eines der folgenden Elemente besitzt:

• Initialisierung von Analytics-SDKs
• Verarbeitung von Deep Links und Universal Links
• Authentifizierungs-SDKs
• Push-Benachrichtigungen
• Nativer Zahlungs-SDKs

Jeder dieser Aspekte ist in der Regel mit Start- oder URL-Callbacks verknüpft, und genau diese Callbacks werden vom Szenenmodell beeinflusst. Prüfen Sie diese Abläufe ausdrücklich, anstatt anzunehmen, dass ein erfolgreicher Build bedeutet, dass die App funktioniert.

React Native 0.88 und die strenge TypeScript-API

Die SDK 58 Beta wird mit der React Native 0.88 Release Candidate ausgeliefert. Ein Upgrade von Expo bedeutet daher, alles zu berücksichtigen, was sich sowohl in React Native 0.87 als auch in 0.88 geändert hat – nicht nur in einer einzelnen Version.

Die Veränderung, auf die Sie am ehesten stoßen werden, ist die strenge TypeScript-API, die definiert, was als öffentliche React Native-API gilt. Importe, die auf interne Dateien verweisen, sind dabei die Hauptbetroffenen:

import Something from 'react-native/Libraries/...';

Apps und Bibliotheken verwenden seit Jahren solche tiefen Importe, meist weil der öffentliche Eingangspunkt nicht das bereitstellte, was sie benötigten. Das funktionierte stets zufällig: Interne Dateipfade können in jeder Version ohne Vorankündigung verschoben oder verändert werden. React Native zieht nun eine klare Grenze zwischen öffentlichen und privaten Modulen, und ein Codebasis voller tiefen Importe sollte SDK 58 als Anlass nutzen, sie zu bereinigen. Falls eine Bibliothek in Ihrem Abhängigkeitsbaum dies tut, prüfen Sie, ob bereits eine neuere Version das Problem behoben hat.

Entfernte APIs wie InteractionManager

Auch einige ältere APIs sind verschwunden, und InteractionManager gehört dazu. Code, der schwere Aufgaben aufschiebt, bis Animationen und Interaktionen abgeschlossen sind, sieht oft so aus:

InteractionManager.runAfterInteractions(() => {
  loadHeavyContent();
});

Die empfohlene Alternative ist die standardmäßige idle-Callback-API:

requestIdleCallback(() => {
  loadHeavyContent();
});

Die Semantik ist ähnlich, aber nicht identisch. InteractionManager wartete darauf, dass die registrierten Interaktionen abgeschlossen waren, während requestIdleCallback den Callback ausführt, wenn der JavaScript-Thread Zeit hat. In den meisten Fällen, in denen „das hier nach dem Auftauchen des Bildschirms laden“ gewünscht ist, spielt der Unterschied keine Rolle. Falls Sie jedoch darauf vertrauen, dass eine bestimmte Animation abgewartet wird, überprüfen Sie das Verhalten an einem echten Gerät.

In einer kleinen Anwendung ist diese Migration in der Regel schnell. In einer älteren Anwendung mit vielen Abhängigkeiten sollten Sie den Upgrade auf einem separaten Branch durchführen und den TypeScript-Compiler dazu nutzen, alle möglichen Probleme aufzulisten, bevor Sie etwas anderes anfassen. Die Compilerfehler bilden somit Ihre Checkliste für die Migration.

Schnellere saubere Android-Builds

expo-modules-core liefert nun vorkompilierte native Bibliotheken für Android. Früher verbrachte ein sauber kompilierter Android-Build einen erheblichen Teil seiner Zeit mit der Kompilierung des C++-Codes, auf den die Expo-Module angewiesen sind. SDK 58 überspringt den größten Teil dieses Schritts.

Laut eigenen Messungen von Expo sank die Zeit für einen sauberen Debug-Build für Android bei einer leeren App mit SDK 58 auf einem Apple M3 Pro-Gerät von etwa 80 Sekunden auf etwa 39 Sekunden. Ihre Werte werden je nach Projektgröße und Hardware unterschiedlich ausfallen, doch der Vorteil entsteht durch das vollständige Überspringen dieser Arbeit, sodass er in jedem Projekt mit Expo-Modulen sichtbar sein sollte.

In CI verdoppelt sich der Nutzen. Ein Team, das täglich zwanzig Pull Requests öffnet, wodurch jeweils Android-Builds ausgelöst werden, zahlt die Kompilierungskosten bei jedem Ausführungsvorgang – und die CI-Maschinen starten oft mit leeren Caches. Einmal eine halbe Minute zu sparen, ist unbedeutend. Doch wenn man diese Zeit bei jedem lokalen sauberen Build, jeder CI-Aufgabe, jeder Feature-Branch und jedem Release-Build spart, summieren sich die Einsparungen zu erheblichen Zeitaufwand- und Rechengebühren. Die Build-Geschwindigkeit ist ebenfalls eine Form der Leistung – nur wird sie in Entwicklertagen statt in Frame-Raten gemessen.

Günstigere Aufrufe zwischen JavaScript und nativem Code

Die Leistungsverbesserungen in SDK 58 beschränken sich nicht auf die Kompilierung. Auch Expo hat die Kosten für Aufrufe in native Module reduziert, wobei der größte Nutzen auf iOS zu verzeichnen ist. Das Übertragen langer Zeichenketten erfolgt deutlich schneller, und von asynchronen nativen Funktionen zurückgegebene Promises verursachen weniger Overhead.

Um davon zu profitieren, müssen Sie nichts ändern: Die vorhandenen Expo-Module übernehmen diese Verbesserungen automatisch, sobald Sie aktualisieren.

Dies ist besonders wichtig für Apps, die häufig zwischen JavaScript und nativen Technologien wechseln. Betrachten Sie einen solchen Aufruf:

const result = await SomeNativeModule.processLargePayload(data);

Die native Funktion mag ihre Arbeit schnell erledigen, doch jeder Aufruf erfordert dennoch Aufwand, um Argumente in native Typen umzuwandeln und die Ergebnisse wieder in JavaScript-Werte umzuwandeln. Wenn eine App solche Aufrufe tausende Male ausführt – beispielsweise beim Verarbeiten eines Datensstreams von Sensoren oder beim Synchronisieren großer Datenmengen – führt bereits eine kleine Zeitersparnis bei jedem Wechsel zu einer messbaren Verbesserung.

Expo Modules 2.0: Native Klassen anstelle einer DSL

Für Teams, die eigene native Module entwickeln, stellt Expo Modules 2.0 eine der bedeutendsten Änderungen dar. Zum Zeitpunkt dieser Erstellung befindet es sich in der Beta-Phase für iOS und Android.

Die aktuelle Expo Modules API beschreibt ein Modul über eine DSL: einen Definitionsblock, in dem Sie Funktionen, Eigenschaften und Ereignisse deklarieren. Expo Modules 2.0 verfolgt einen konventionelleren Ansatz. Sie schreiben eine gewöhnliche Swift- oder Kotlin-Klasse und kennzeichnen die Mitglieder, die an JavaScript ausgeliefert werden sollen.

Die praktische Folge ist, dass Ihr natives Code wie echter Native-Code aussieht. Swift wirkt wie Swift und Kotlin wie Kotlin – ohne dass man zunächst eine framework-spezifische Schicht erlernen muss. Dadurch sinkt die Hürde für Entwickler, die die Plattform kennen, aber nicht Expo, und es hilft auch AI-Code-Tools, da in ihren Trainingsdaten weitaus mehr gewöhnlicher Swift- und Kotlin-Code als Expo-DSL-Code vorhanden ist.

Auch aus Sicht der Leistungsfähigkeit gibt es Vorteile. Bindings können zur Zeit der Kompilierung erzeugt werden anstelle dessen, dass sie laufzeitbasiert dynamisch gelöst werden, und Expos Benchmarks zeigen in mehreren Mikrobenchmarks erhebliche Verbesserungen. Mikrobenchmarks isolieren eine einzelne Operation, weshalb sie selten eins-zu-eins in Geschwindigkeitssteigerungen auf Anwendungsebene münden; sie sind daher allein kein Grund, Ihre native Architektur neu zu gestalten. Wenn Sie mehr über die Gründe erfahren möchten, warum statische Bindings schneller sind, behandelt der Vergleich in Nitro Modules: wie statische Bindings React Native TurboModules übertrifft dasselbe Prinzip. Besonders hervorzuheben ist bei Expo Modules 2.0, dass es die Module gleichzeitig einfacher zum Schreiben und schneller macht – eine seltene Kombination.

Home-Screen-Widgets auf Android

expo-widgets unterstützt nun auch Android, was neue Produktideen für viele Arten von Apps ermöglicht: Gewohnheits Tracker, Finanztools, Lieferdienst-Apps, Fitness-Apps, Aufgabenmanager und Kalender.

Eine Gewohnheits-App könnte den heutigen Fortschritt anzeigen, ohne geöffnet zu werden. Eine Finanz-App könnte eine kurze Budgetübersicht mit einem solchen Überschriftentext anzeigen:

Monthly Budget

und darunter eine Aufschlüsselung der verbleibenden Summe nach Kategorien:

₹34,500 remainingFood        ₹8,200
Travel      ₹3,400
Shopping    ₹5,100

Ein Aufgabenmanager könnte die drei wichtigsten Aufgaben des Tages direkt auf dem Startbildschirm anzeigen.

Auf Android läuft jedes Widget seinen eigenen JavaScript-Bundle in einem dedizierten Hermes-Runtime aus, unterstützt Benutzerinteraktionen und kann Material Colors verwenden, um sich mit dem Systemthema zu verbinden. Der separate Runtime ist wichtig zu verstehen: Das Widget teilt weder Speicher noch Zustand mit der laufenden App, sodass Daten explizit an das Widget übergeben werden müssen und nicht aus dem internen Speicher der App gelesen werden können. Für cross-platform-Teams beseitigt das Vorhandensein von Widgets auf beiden Plattformen innerhalb des Expo-Ecosystems einen weiteren Grund für die Pflege separater native Implementierungen.

App Intents: Siri, Shortcuts und Spotlight

expo-app-intents verbindet Expo-Apps mit App Intents, dem System von Apple, das hinter mehreren Systemfunktionen steht:

• Siri
• Shortcuts
• Spotlight
• Apple Intelligence

Stellen Sie sich einen Aufgabenmanager vor. Normalerweise bedeutet die Erledigung einer Aufgabe, die App zu öffnen, den entsprechenden Eintrag zu finden und darauf zu tippen. Wenn eine Absicht bereitgestellt wird, kann der Benutzer einfach Siri fragen:

"Fertige die Upload-ID-Dokumente ab."

Siri löst die passende Aufgabe und ruft die von Ihrer App deklarierte Aktion auf. Ihr JavaScript-Code erhält diese Aufrufe und aktualisiert die Daten der App. Im Beispiel von Expo geschieht dies, ohne dass die App in den Vordergrund gebracht werden muss.

Die weitreichendere Bedeutung ist ein Wandel in der Struktur mobiler Apps. Das App-Icon ist nicht mehr der einzige Eingangspunkt. Einige Aktionen starten über Siri, andere über Widgets, wieder andere über die Spotlight-Suche und noch weitere über die Shortcuts-Automatisierungen des Benutzers. Die App wird zu einer Sammlung von Funktionen, die das Betriebssystem dort bereitstellen kann, wo sie nützlich sind – und das sollte man berücksichtigen, wenn man Funktionen entwirft.

Eine wichtige Einschränkung: expo-app-intents befindet sich zum Zeitpunkt der Erstellung in der Alpha-Version. Experimentieren Sie damit, setzen Sie aber noch keine für das Geschäft kritischen Workflows darauf um.

Expo UI rückt näher an SwiftUI und Jetpack Compose heran

Expo UI vertieft weiterhin seine Integration mit SwiftUI und Jetpack Compose. Das SDK 58 fügt Navigationssprimitiven für iOS in SwiftUI hinzu:

NavigationStack
NavigationLink
NavigationDestination
Toolbar

Diese entsprechen den eigenen Navigationselementen von SwiftUI, sodass Sie native Stapelnavigation und Toolbars erhalten anstelle einer in JavaScript nachgebildeten Version. Die Veröffentlichung fügt außerdem weitere Jetpack Compose-Komponenten hinzu und verbessert die bereits vorhandenen universellen Komponenten, die auf allen Plattformen funktionieren.

Eine kleinere Verbesserung ist überraschend nützlich: Jede Komponente in der Expo UI-Dokumentation verfügt nun über ein visuelles Beispiel. Ohne Screenshote führt die Auswahl einer UI-Komponente oft zu einem frustrierenden Kreislauf:

1. Einen Komponenten finden, der klanglich passt.
2. Sie seine Eigenschaften durchlesen.
3. Ihnen eine Verbindung zu einem Bildschirm herstellen.
4. Die App starten.
5. Feststellen, dass das Endergebnis überhaupt nicht so aussieht wie erwartet.
6. Mit einer anderen Komponente von vorn beginnen.

Durch die Anzeige der renderierten Komponente neben ihrer API wird dieser Teufelskreis unterbrochen.

Device Hub und Steuerung über einen browserbasierten Simulator

Xcode 27 ersetzt Simulator.app durch Device Hub, und Expo CLI versteht den neuen Arbeitsablauf. Zudem experimentiert Expo mit einem separaten Paket, expo-device-hub, das einen lokalen Dashboard im Browser für Ihre Simulatoren und Emulatoren bereitstellt.

Von diesem Dashboard aus können Sie folgendes einsehen:

• einen Echtzeit-Spiegel des Gerätescreens
• CPU- und Speicherverbrauch
• Netzwerkverkehr
• Erscheinungsoptionen wie Helligkeits- und Dunkelmodus
• Barrierefreiheitsoptionen

Man kann auch über den Browser auf dem Gerät tippen, streichen und eingeben. Um es auszuprobieren, installieren Sie das Paket und starten Sie den Entwicklungsserver:

npx expo install expo-device-hub
npx expo start

Falls Ihr Arbeitstag darin besteht, ständig zwischen einem Editor, einer Terminalanwendung, dem Android-Emulator, dem iOS-Simulator sowie separaten Profilierungstools hin- und herzuschalten, kann das Zusammenfassen einiger dieser Funktionen in einem einzigen Browserfenster den Entwicklungsprozess deutlich flüssiger gestalten.

Expo arbeitet außerdem an dem EAS Simulator, der mit cloudbasierten Simulatoren eine ähnliche Erfahrung bieten soll, sodass man Xcode oder Android Studio nicht lokal installieren muss.

Eine CLI für Coding-Agents

Diese Erweiterung zeigt deutlich, wohin sich die Entwicklungstools entwickeln. Expo hat ein experimentelles Paket veröffentlicht:

@expo/agent-cli

Coding-Agenten haben Schwierigkeiten, wenn sie entscheiden müssen, welches von mehreren Tools verwendet werden soll: Expo CLI, EAS CLI, expo-doctor und so weiter – jedes mit eigenen Flags und Ausgabeformaten. Der Agent-CLI bündelt diese Tools unter einer einheitlichen Schnittstelle. Die Einrichtung für Ihr Projekt sieht so aus:

npx @expo/agent-cli@latest agents:setup

Einige seiner Befehle veranschaulichen das Konzept. Der erste davon ist:

status

Er überprüft Dinge wie die Kompatibilität mit Expo Go, ohne die App zu starten. Der nächste Befehl ist:

dev

Er startet die Entwicklungsumgebung und versucht, den schnellsten Weg zu einer laufenden App zu finden. Der letzte Befehl ist:

smoke

Er startet die App, macht einen Screenshot und schaltet sie wieder aus.

Der letzte Befehl ist für automatisierte Workflows am interessantesten. Angenommen, Sie bitten einen Agenten, ein Einstellungsformular hinzuzufügen und zu überprüfen, ob die App weiterhin startet. Anstatt davon auszugehen, dass die Änderung funktioniert, kann der Agent einen Testlauf durchführen und sich das Ergebnis ansehen. Das ist ein kleiner Schritt von Agenten als Code-Generatoren zu Agenten, die ihre eigene Arbeit überprüfen können – und genau darin liegt der größte praktische Wert. Das Paket ist noch experimentell, daher sollten Sie mit Änderungen an seinen Befehlen rechnen.

Expo Router stabilisiert mehrere Funktionen

Expo Router erhält in SDK 58 eine umfangreiche Aktualisierung. Mehrere bisher experimentelle Funktionen sind nun stabil:

• Data-Loader, um Routendaten vor dem Rendern einer Ansicht abzurufen
• Server-seitiges Rendering für Web-Ausgaben
• Middleware, die vor Erreichen einer Route ausgeführt wird
• Eigene Tab-Elemente, die von den Plattform-Tab-Leisten unterstützt werden
• Toolbars

Im Hintergrund wurde auch die Navigation umgeschrieben, sodass der Zustand der Navigation deterministischer ist – das bedeutet, dass dieselbe Abfolge von Aktionen zuverlässig denselben Zustand erzeugt. Die meisten Apps sollten keinen Unterschied bemerken. Wenn Sie eigene Navigator erstellt haben oder direkt vom folgenden Pfad importieren, lesen Sie den Migrationsleitfaden sorgfältig durch:

expo-router/react-navigation

Im Web sind asynchrone Routen nun Standard. Jede Route kann in ihren eigenen JavaScript-Chunk aufgeteilt werden und beim Navigieren des Benutzers geladen werden, anstatt beim ersten Seitenaufruf Code für jedes Bildschirm zu übertragen. Für auf Expo Router basierende Webanwendungen ist dies ein sinnvoller Standard, da die Anfangsladezeit in der Regel am meisten auffällt. Bedenken Sie, dass dies auch bedeutet, dass eine Route beim ersten Besuch kurzzeitig geladen werden kann; daher verdienen die Ladezustände im Web eine schnelle Überprüfung.

Ein experimenteller Rust-Transformer für Metro

Technisch gesehen könnte dies die interessanteste Änderung in dieser Version sein, obwohl sie ausdrücklich experimentell ist. Expo testet einen in Rust geschriebenen JavaScript-Transformer namens Noxcturnal, der auf dem oxc-Toolchain basiert.

Ein großer Teil der Zeit, die Metro für das Kaltverpacken benötigt, geht auf Babel-Transformationsprozesse drauf: Das Parsen jeder Datei, das Anwenden von Plugins und die Erstellung der Ausgabe. Durch den Ersatz dieses Schritts durch nativen Rust-Code wird direkt der teuerste Teil angegangen. In Expos Tests waren die Transformationsprozesse für einzelne Module etwa dreimal schneller, und vollständige Kaltverpackungen waren etwa doppelt so schnell. Eine große Testanwendung mit rund 5.500 Dateien benötigte von 5,26 Sekunden nur noch 2,46 Sekunden.

Sie können dies über eine Experimentier-Flagge in Ihrer Konfiguration aktivieren:

experiments: {
  noxcturnalTransformWorker: true
}

Kennen Sie die Grenzen, bevor Sie diese Funktion aktivieren. Projekte, die auf benutzerdefinierten Babel-Plugins, Voreinstellungen oder spezialisierten Transformationen angewiesen sind, greifen möglicherweise weiterhin auf Babel zurück, wodurch die Geschwindigkeitssteigerung von der Standardisierung Ihrer Einrichtung abhängt. Da es sich um eine experimentelle Funktion handelt, können ihr Verhalten und ihre Konfiguration zwischen den Versionen ändern.

Diese Richtung entspricht dem umfassenderen Ökosystem, in dem leistungskritische JavaScript-Tools bereits seit mehreren Jahren von JavaScript zu Rust wechseln. Expo prüft nun denselben Weg für Metro.

Das Standardverhalten bezüglich der Erstellung von Fingerprints in SDK 58 ist nun die balanced-Voreinstellung. Das Fingerprint ist ein Hash aller Elemente, die den nativen Build beeinflussen; ändert es sich, geht Expos Tooling davon aus, dass ein neues natives Binärdatei erforderlich ist.

Das klingt langweilig, bis es Sie vor einem erneuten Neubau des nativen Codes für eine Änderung bewahrt, die den nativen Code nie beeinflusst hat. Je nach Konfiguration führte früher eine Änderung wie der App-Version in app.json dazu, dass die Fingerabdruckdaten verändert wurden. Die ausgewogene Voreinstellung versucht, Änderungen zu ignorieren, die den nativen Laufzeitumfeld nicht wesentlich verändern. Das Ergebnis im Alltag ist einfach: Weniger unnötige Neubauten, was auch bedeutet, dass weniger überflüssige Binärdateien erstellt werden müssen, wenn man sich auf Fingerabdruckdaten verlässt, um zwischen einem Over-the-Air-Update und einem neuen Store-Bau zu entscheiden. Niemand demonstriert diese Art von Funktion, aber jeder profitiert davon.

Kleine Verbesserungen, die man kennen sollte

Neben den wichtigsten Punkten können je nach Ihrer App mehrere Module-Updates relevant sein:

• expo-camera fügt das Scannen mehrseitiger Dokumente hinzu, was für Quittungsscanner, Prozesse zum Hochladen von Dokumenten, Identitätsprüfung (KYC) und Kostenverwaltung nützlich ist.
• expo-font unterstützt variable Schriftarten auf Android, iOS und im Web.
• expo-audio bietet nun bedienbare Sperrbildschirmfunktionen, die sich an Playlists orientieren, sowie die Möglichkeit zur Aufnahme in WAV/PCM-Format.
• expo-file-system enthält zusätzliche Hashing-APIs sowie eine native Vorschaufunktion.
• expo-notifications fügt neue Funktionen wie die Benachrichtigung über Wecker auf Android hinzu.
• Durch eine Integration mit PostHog können Informationen zur EAS-Build-Version und -Aktualisierung an Analyseereignisse angehängt werden.

Niemand dieser Bestandteile definiert allein eine Version. In Kombination zeigen sie, wie umfassend die Abdeckung der Plattform geworden ist.

Wichtige Änderungen, die vor dem Upgrade überprüft werden sollten

Upgrades sind bis zum Zeitpunkt, an dem die Erstellung der App stoppt, äußerst spannend – überspringen Sie daher diesen Teil nicht. Bevor Sie ein echtes Projekt auf SDK 58 verschieben, überprüfen Sie Folgendes.

Tiefe Importe in React Native

Suchen Sie im Codebasis nach diesem Pfadpräfix:

react-native/Libraries/

Jeder Treffer stellt einen Import interner React Native-Dateien dar, der von der strengen TypeScript-API abgelehnt werden kann. Überprüfen Sie auch node_modules, oder zumindest die fehlerhaften Abhängigkeiten, da Bibliotheken eine häufige Quelle solcher Probleme sind.

Ausgeschaltete React Native-APIs

Stellen Sie sicher, dass weder Ihre App noch ihre Abhängigkeiten weiterhin APIs verwenden, die in React Native 0.87 und 0.88 entfernt wurden, wie beispielsweise InteractionManager.

Custom AppDelegate-Code

Falls das iOS-Projekt native Anpassungen des Lebenszyklus enthält, prüfen Sie diese im Vergleich zum auf Szenen basierenden Lebenszyklus, der von iOS 27 gefordert wird.

Custom-Navigation in Expo Router

Kundenspezifische Navigator-Implementierungen sowie Importe aus expo-router/react-navigation werden durch die überarbeiteten Interna beeinflusst; folgen Sie dem Migrationsleitfaden.

Schreibvorgänge im Dateisystem

File.write() ist nun asynchron. Code, der davon ausgeht, dass die Datei bereits vorhanden ist, wird fehlschlagen, es sei denn, er wartet auf den Aufruf. Falls Sie tatsächlich ein synchrones Verhalten benötigen, wechseln Sie zu:

File.writeSync()

Node.js-Version

Die von Expo unterstützten Node.js-Versionen haben sich weiterentwickelt. Überprüfen Sie Ihre lokale Umgebung sowie Ihre CI-Images, bevor Sie annehmen, dass ein fehlgeschlagener Build auf einen Fehler bei Expo zurückzuführen ist.

Eine sichere Methode zur Testung des Updates

Fangen Sie nicht auf der Hauptproduktionsbranche an. Erstellen Sie eine eigene Migrationsbranche und führen Sie dort das Update durch:

npx expo install expo@next --fix

Die expo@next-Tagging-Option installiert die Beta-Version, und --fix stellt sicher, dass Ihre anderen Expo-Pakete mit kompatiblen Versionen abgestimmt sind.

Testen Sie zunächst die weniger auffälligen Abläufe, denn genau diese werden von den Nutzern bemerkt, wenn sie fehlschlagen:

• Lädt die App überhaupt?
• Funktionieren Anmelden und Authentifizierung?
• Können Nutzer zwischen den Hauptbildschirmen wechseln?
• Öffnen Deep Links die richtigen Seiten?
• Kommen Push-Benachrichtigungen an?
• Können Nutzer Bilder und Dateien hochladen?
• Sind Zahlungen erfolgreich abgeschlossen?
• Erfolgt der Build für Android reibungslos?
• Erfolgt der Build für iOS reibungslos?

Nur wenn diese Tests bestehen, lohnt es sich, neue Funktionen zu untersuchen. Neue APIs sind interessant zum Ausprobieren; Regressionstests sorgen dafür, dass Ihre Nutzer zufrieden bleiben.

Wohin Expo steuert

Betrachtet man das SDK 58 insgesamt, ist die allgemeine Richtung wichtiger als irgendwelche einzelnen Funktionen. Expo entstand ursprünglich, um React Native benutzerfreundlicher zu machen, und entwickelt sich zunehmend zu einer vollständigen Anwendungsplattform:

• Expo Router für die App-Struktur und Navigation
• Expo Modules für native APIs
• EAS Build zur Erstellung von Builds
• EAS Update zum Bereitstellen von Updates
• EAS Observe zur Überwachung in der Produktion
• Expo UI für Komponenten einer nativen Benutzeroberfläche
• Widgets und App Intents für die Integration in das Betriebssystem
• Agent-Tools für entwicklungserleichternde KI-Funktionen

Neben diesen Funktionen setzt Expo weiterhin auf die Infrastruktur, die Entwickler täglich nutzen: schnellere Builds, günstigere Anrufe zu nativen Systemen, weniger Neubuilds, bessere Tunnels, verbesserte Simulator-Tools und möglicherweise schnelleres Bündeln. Keine dieser Funktionen erzeugt beeindruckende Screenshote, doch sie verbessern die tägliche Arbeit. Für einen umfassenderen Überblick darüber, wie dies Expo positioniert, siehe warum Shoppiefs Ausstieg aus React Native Expo nicht bedroht.

Sollten Sie jetzt upgraden?

Für eine Produktanwendung sollten Sie vor dem Commit testen. SDK 58 ist noch in der Beta-Phase, React Native 0.88 ist als Release Candidate enthalten, mehrere der neuen APIs sind experimentell oder in der Alpha-Version, und es werden weitere Korrekturen vor der stabilen Veröffentlichung erwartet.

Für ein Nebenprojekt, ein internes Tool oder eine Migrations-Branch lohnt es sich sehr, es jetzt auszuprobieren – insbesondere wenn Sie Unterstützung für iOS 27 benötigen oder den React Native-Änderungen voraus sein möchten. Probleme, die Sie während der Beta finden, können weiterhin gemeldet und vor der stabilen Veröffentlichung behoben werden, was weitaus einfacher ist als danach, wenn alle anderen bereits upgegraded haben.

Der Befehl, den Sie sich merken sollten, ist derselbe, mit dem Sie beginnen:

npx expo install expo@next --fix

Führen Sie ihn in einer Branch aus, nicht in der Produktumgebung.

Hauptpunkte

• Die Änderungen, die am ehesten zu Fehlern bei einem Upgrade führen, sind tiefe Importe, entfernte APIs wie InteractionManager, benutzerdefinierter -Code sowie eigene Expo Router-Navigatoren.
• Schnellere Android-Kompilierungen, günstigere native Aufrufe sowie weniger Neucompilierungen aufgrund von Fingerabdruck-Änderungen gehören kostenlos zum Upgrade dazu.
• Expo Modules 2.0, die agent CLI, Device Hub sowie der Noxcturnal Transformer sind noch experimentell oder in der Beta-Version; prüfen Sie sie, verlassen Sie sich aber noch nicht darauf.
• expo-app-intents befindet sich in der Alpha-Version, während Android-Widgets Funktionen des Startbildschirms für cross-platform Teams ermöglichen.
• Führen Sie das Upgrade auf einer separaten Branch durch, testen Sie zunächst die kritischen Benutzerflüsse und erkunden Sie neue Funktionen erst, nachdem diese erfolgreich getestet wurden.