Warum Shoppys Verzicht auf React Native Expo nicht bedroht
Erklärt, warum Shoppys Wechsel von React Native zu den nativen Sprachen Swift und Kotlin nicht das Ende der cross-plattformbasierten Expo-Entwicklung für die meisten Teams bedeutet.
Am 10. September 2026 kündigte Shopify an, seine Kern-Mobile-Apps aus React Native zu entfernen und sie stattdessen native mit Swift und Kotlin neu zu entwickeln. Innerhalb weniger Stunden waren Entwicklerforen voller Spekulationen. In sozialen Medien wurden Diskussionen geführt, ob dies das Ende von React Native bedeute. Mehrere Blogbeiträge gingen sogar so weit zu behaupten, die plattformübergreifende Mobile-Entwicklung sei beendet.
Falls Sie mit Expo entwickeln, sollte Sie all das nicht beunruhigen.
Was Shopify tatsächlich getan hat – und warum
Shopifys angegebene Begründung war recht einfach: KI-basierte Programmierassistenten haben es deutlich günstiger gemacht, zwei separate native Codebasen für iOS und Android zu pflegen. Der ursprüngliche Verkaufsargument von React Native bestand darin, Entwicklungszeit durch Code-Teilung über verschiedene Plattformen einzusparen. Sobald KI-Tools in der Lage sind, native Code in Swift und Kotlin in hoher Geschwindigkeit zu erzeugen, ändert sich diese Rechnung für eine Organisation von Shoppihos Größe.
Der entscheidende Aspekt ist „eine Organisation von der Größe von Shopify“.
Shopify betreibt eine der komplexesten mobilen Anwendungen der Welt – mit Hunderten von Ingenieuren, Millionen von Händlern sowie Leistungsanforderungen, die jedes Framework auf die Probe stellen. Wenn Shopify behauptet, KI habe die Entwicklung nativer Anwendungen erschwinglicher gemacht, spricht es aus der Position eines Unternehmens, das gleichzeitig zwei große, komplexe Codebasen betreuen kann.
Die meisten Expo-Entwickler befinden sich nicht in dieser Lage, genauso wenig wie die typischen Teams, die heute Anwendungen veröffentlichen.
Expo und Shopify lösen unterschiedliche Probleme
Für Shopify war React Native hauptsächlich ein Mittel, die Kosten in einer riesigen Ingenieurorganisation zu senken. Für Expo-Entwickler ist React Native das Werkzeug, mit dem ein Einzelentwickler oder ein kleines Team eine vollständige, hochwertige App für iOS und Android veröffentlichen kann, ohne Spezialist für eine der nativen Plattformen zu sein.
Diese beiden Anwendungsfälle haben fast nichts miteinander zu tun.
Expo verfügt über ein eigenes Kernteam, das jahrelang daran gearbeitet hat, eine der besten Entwicklererfahrungen im mobilen Bereich zu schaffen. Die kürzlich veröffentlichte SDK-Version 57 brachte weitere Verbesserungen in Bezug auf Leistung, Build-Tools sowie die tägliche Arbeit der Entwickler. Umgebende Bibliotheken wie NativeWind, Reanimated und Expo Router sind stabiler und für die Produktion bereit als je zuvor.
Das alles ändert sich nicht nur deshalb, weil ein großer Händler beschlossen hat, wegzugehen.
Die Zahlen erzählen eine andere Geschichte
Während Kommentatoren damit beschäftigt waren, zu behaupten, React Native sei fertiggestellt, wiesen die Adoptionszahlen eine andere Richtung auf.
NativeWind, die stilistische Lösung im Stil von Tailwind CSS für React Native, erreichte im Jahr 2026 mehr als 1,3 Millionen wöchentliche Downloads und zeigte weiterhin einen Anstieg. Expo bleibt in Entwicklergemeinschaften und Diskussionen weiterhin stark präsent. Neuere Stilbibliotheken wie Uniwind wurden eingeführt und erzielten bereits innerhalb weniger Monate Hunderttausende von wöchentlichen Downloads.
Diese Zahlen beschreiben kein schrumpfendes Ökosystem – sie beschreiben eines, das sich noch weiter entwickelt.
Diejenigen, die React Native in dem Moment verließen, als Shopify seine Ankündigung machte, waren wahrscheinlich dieselben Personen, die ohnehin nächsten Monat einen anderen Grund gefunden hätten, um wegzugehen. Die Entwickler, die tatsächlich echte Produkte mit Expo veröffentlichen, überdenken nichts.
KI beschleunigt die Entwicklung mit Expo – macht es aber nicht überflüssig
In der Behauptung, KI habe React Native zerstört, steckt eine echte Ironie: KI-basierte Werkzeuge haben das Arbeiten mit Expo tatsächlich deutlich verbessert, anstatt es zu verschlechtern.
Hilfsprogramme wie Claude, Cursor und GitHub Copilot verfügen über ein tiefes Verständnis des Expo-Ökosystems. Wenn es eine gut strukturierte CLAUDE.md-Datei gibt, die Ihre Komponentenkonventionen und Architekturmuster dokumentiert, können diese Assistenten neue Screens hinzufügen, Funktionen entwickeln und bestehenden Code überarbeiten, ohne mit dem Rest Ihres Codebases in Konflikt zu geraten.
Die Nutzer, die am meisten von diesem Workflow profitieren – manchmal als „Vibe Coders“ bezeichnet, weil sie ein Ergebnis beschreiben und dem Assistenten die Umsetzung überlassen – benötigen dennoch eine solide Ausgangsstruktur. KI-Tools sind hervorragend darin, Code zu schreiben. Bei der Entscheidung über die Architektur, dem Entwurf von Navigationsschleifen, dem Aufbau eines Themensystems oder der Erstellung einer konsistenten Sammlung gemeinsamer Komponenten von Grund auf sind sie hingegen weitaus weniger zuverlässig.
Genau diese Lücke wird durch ein gut konstruiertes Expo-Startvorlage ausgefüllt. Es geht dabei nicht um den Code, den ein KI-Assistent auf Anfrage generieren könnte – es geht vielmehr um die zugrundeliegende Struktur, die das kI-gestützte Programmieren tatsächlich produktiv macht.
Vorlagen bilden die Grundlage für kI-gestütztes Entwickeln
Wenn ein Entwickler Cursor oder Claude öffnet, um eine neue App zu erstellen, stellt sich die erste wichtige Frage: Von welcher Codebasis aus soll er arbeiten?
Wenn man mit einem reinen create-expo-app-Ausgabeformat beginnt, bedeutet das, dass man die ersten Stunden damit verbringt, die Navigation einzurichten, die Unterstützung für den Dunkelmodus hinzuzufügen, grundlegende UI-Komponenten zu erstellen und Konventionen festzulegen. KI kann bei Teilen dieser Arbeit helfen, erfordert aber dennoch menschliche Entscheidungen, Konfigurationen sowie wiederholte Anpassungen, bevor eine nutzbare Grundlage vorhanden ist.
Wenn man hingegen mit einem für die Produktion bereiten Template beginnt, sind diese Vorbereitungen bereits abgeschlossen. Man öffnet den KI-Editor, beschreibt die nächste gewünschte Funktion – und der Assistent verfügt bereits über eine kohärente, gut strukturierte Codebasis, die er erweitern kann.
Deshalb sind Templates, die mit KI-gestützten Arbeitsabläufen im Sinn entwickelt wurden – inklusive detaillierter CLAUDE.md-Dokumentation, klaren Anmerkungen auf Komponentenebene sowie konsistenten Mustern – heute wichtiger als vor zwei Jahren, und nicht weniger.
Die Entwickler, die sich tatsächlich Sorgen machen sollten
Falls Shoppys Entscheidung jemanden beunruhigen sollte, dann sind es die Entwickler, die reine React Native-Apps außerhalb des Expo-Ecosystems erstellen, direkt auf das React Native CLI vertrauen und Kunden im Unternehmensumfeld ansprechen, die über ausreichend Entwicklerteams verfügen, um vollständig native Entwicklung zu rechtfertigen.
Das beschreibt nur einen recht kleinen Teil aller React Native-Nutzer.
Falls Sie hingegen ein unabhängiger Entwickler, Freiberufler, kleines Studio oder jemand sind, der seine erste App hauptsächlich durch Beschreibungen an einen KI-Assistenten erstellt, bleibt Expo der schnellste Weg von einer Idee bis zu einer veröffentlichten App auf beiden großen Mobilplattformen. Shoppys Entscheidung ändert daran nichts.
Was das für Sie bedeutet
Fahren Sie mit Expo weiterhin mit der Entwicklung fort und veröffentlichen Sie Ihre Anwendungen damit. Das Ökosystem ist in guter Verfassung, die Werkzeuge verbessern sich mit jeder neuen Version weiter, und die Community darum herum verschwindet nicht.
Falls Sie ein neues React Native-Projekt starten, beginnen Sie mit einem für die Produktion bereiten Template statt mit einem leeren Projekt und überlassen Sie den Implementierungsdetails die KI-Assistenten auf dieser Grundlage. Diese Kombination ermöglicht es Ihnen, schneller zu veröffentlichen als bei der Arbeit von Grund auf.
Einige Entwickler werden in den kommenden Wochen wegen einer Ankündigung eines Unternehmens heiße Diskussionen lesen und ihre Technologieentscheidungen in Frage stellen. Andere werden einfach weiterhin ihre Apps veröffentlichen.
Zielen Sie darauf ab, zur zweiten Gruppe zu gehören.
Verwandte Artikel
- Nitro Modules: Wie statische Bindungen React Native TurboModules übertrifft — Erklärt, wie Nitro Modules vorkompilierte statische Bindungen anstelle dynamischer Abfragen verwenden, um in React Native deutlich bessere Leistungen als TurboModules und Expo Modules zu erbringen.
- React Native, Flutter und weitere Plattformen: Cross-Platform-Mobilentwicklung im Jahr 2026 — Ein vergleichender Überblick über React Native, Flutter, Kotlin Multiplatform, Ionic, NativeScript und PWA hinsichtlich Leistung, Entwicklererfahrung und Reifegrad des Ökosystems.