Shopify verlässt React Native für Swift und Kotlin. Der Grund ist nicht das, was Sie denken.
Shopify wendet sich von React Native ab. Am 10. September 2026 veröffentlichte Mustafa Ali, der Leiter des Mobile-Bereichs des Unternehmens, zwei Engineering-Beiträge, in denen er bekannt gab, dass Shopifys Apps in Swift und Kotlin neu entwickelt werden – wieder eine Codebasis pro Plattform. Die Shop-App wurde bereits als vollständig nativer Build veröffentlicht. Die Haupt-Shopify-App mit mehr als 300 Screens, einer Watch-App und Sperrbildschirm-Widgets folgt als Nächstes und ist für später in diesem Jahr geplant.
Was diese Meldung lesenswert macht, ist das Timing. Im Januar 2025 schrieb dieselbe Person einen Beitrag mit dem Titel „Fünf Jahre React Native bei Shopify“ und teilte der Branche mit, dass jetzt ein guter Zeitpunkt sei, React Native erneut auszuprobieren, falls man es schon länger nicht mehr angeschaut hatte. Zwanzig Monate später migriert er davon weg. Das ist kein Unternehmen, das die Liebe zu einem Framework verloren hat. Es ist ein Unternehmen, das beobachtet hat, wie sich eine seiner Kernannahmen verändert hat, und den Mut hatte, dies öffentlich zu sagen.
Die Annahme betraf die Kosten. Shopify wechselte 2020 zu React Native, um aufzuhören, jede Funktion zweimal zu entwickeln. Ali stellt klar, dass das Framework seine Arbeit erledigt hat: „React Native Apps können schnell sein. Unsere sind es.“ Der Grund für den Wechsel ist nicht die Performance. Es liegt daran, dass KI-Coding-Agenten gut genug geworden sind, dass das Schreiben derselben Funktion in Swift und Kotlin nicht mehr so viel kostet wie früher. Sobald ein Agent einen Großteil der zweiten Implementierung übernehmen kann, wird das Hauptargument für eine gemeinsame Codebasis schwächer, während die Vorteile des nativen Ansatzes – näher an der Plattform und weniger Abhängigkeitsebenen – genau dort bleiben, wo sie waren.
Die Zahlen sprechen für sich. In der nativen Neuentwicklung reduzierte die Shop-App den Kaltstart um 23% auf iOS und 50% auf Android. Absturzende Sitzungen sanken ungefähr um das Zehnfache, von 99,5% Sitzungsstabilität auf 99,95%. Android-Release-Builds wurden etwa 75% schneller, das Android-Binärformat schrumpfte um 109 MB, und der Feed läuft beim Scrollen mit 120 FPS. Sechs Ingenieure brachten es in 12 Wochen vom Proof of Concept in den App Store, nachdem ein einzelner Ingenieur eine Woche damit verbracht hatte, die Durchführbarkeit zu beweisen.
Wo wir Sie verlangsamen würden
Die Schlagzeile, die alle geteilt haben, lautet „KI hat Cross-Platform getötet.“ Das nützlichere Detail steckt im Migrations-Write-up: Shopifys größter Geschwindigkeitsgewinn kam durch die Entkopplung der Geschäftslogik von der UI, sodass sie ohne UI läuft, gesteuert von einem Kommandozeilen-Tool statt einem Simulator. Ihre Agenten konnten dann in Millisekunden iterieren, anstatt einen Simulator minutenlang für jede Änderung zu beobachten. Dieser Trick hat nichts mit Swift oder Kotlin zu tun. Sie können ihn heute in React Native umsetzen. Lagern Sie Ihre Logik in reine Module ohne UI-Imports aus, führen Sie sie unter Node hinter einer schlanken CLI aus, und Ihre Agenten – sowie Ihre Tests – erhalten denselben schnellen Ablauf. In unserer nativen iOS- und Android-Arbeit und in den Healthcare- und IoT-Apps, die wir entwickelt haben, wo Korrektheit mehr zählt als Pixel, ist diese Trennung die einzige Änderung, die sich auszahlt – unabhängig davon, ob ein Agent jemals den Code berührt.
Ein zweiter Punkt, der ausgesprochen werden sollte: Shopify brauchte immer noch Native-Experten. Ihr eigener Beitrag gibt zu, dass der generierte Code Duplikate, architektonische Abweichungen und Performanceprobleme einführte, und dass native Expertise weiterhin unverzichtbar war. Die Kosten zweier Codebasen verschwanden nicht. Sie verlagerten sich vom Schreiben von Code auf das Überprüfen. Swift zu reviewen, den man nicht selbst geschrieben hat, und zu beurteilen, ob er wirklich gut ist, ist der teure Teil – und er lässt sich nicht so parallelisieren wie das Generieren. Ein Fünf-Personen-Startup hat nicht Shopifys Review-Kapazität. Die Entscheidung zu kopieren, ohne die Review-Kapazität zu kopieren, führt zu zwei Codebasen und halbem Vertrauen.
Die konkrete Empfehlung lautet daher: Lesen Sie das nicht als Signal, irgendetwas neu zu schreiben. Lesen Sie es als Anstoß, ein Experiment durchzuführen. Wählen Sie einen Screen, extrahieren Sie seine Logik aus der UI in ein Headless-Modul mit eigenen Tests, und messen Sie, wie viel schneller sowohl Ihre Ingenieure als auch Ihre Agenten damit arbeiten. Das ist ein Tag Refactoring, es ist reversibel, und es sagt Ihnen mehr über Ihre eigene Codebasis als jede Shopify-Metrik.
In Alis Beitrag von 2025 steckt auch eine leisere Sicherheitslektion. Er wies darauf hin, dass React Natives Abhängigkeit von Drittanbieter-Bibliotheken die Angriffsfläche der Lieferkette vergrößert. Das stimmt nach wie vor und ist nicht auf React Native beschränkt. Jedes native Projekt stützt sich ebenfalls auf Pakete. Bei unseren Penetrationstests ist der Abhängigkeitsbaum einer der ersten Orte, die wir untersuchen, denn ein kompromittiertes transitives Paket ist ein weitaus häufigerer Einstiegspunkt als ein Bug im eigenen Code. Weniger Framework-Ebenen können weniger bewegliche Teile bedeuten, die überprüft werden müssen – aber nur, wenn Sie tatsächlich verfolgen, was Sie einbinden.
Das bedeutet nicht, dass React Native erledigt ist. Shopify ist ein sehr spezifischer Fall: riesige Apps, Budget für KI-Inferenz und native Reviewer sowie eine bevorstehende New Architecture-Migration, die einen Neuaufbau von Grund auf gegenüber einem Upgrade an Ort und Stelle wettbewerbsfähig machte. Die meisten Teams befinden sich nicht in dieser Situation. Der richtige Stack hängt immer noch von Ihrem Team, Ihren Apps und davon ab, wie viel des zweiten Builds Sie einem Agenten ehrlich zutrauen.
Wenn Sie sich fragen, ob Sie für Ihre nächste Mobile-Version auf Native, Cross-Platform oder ein Headless-Refactoring setzen sollen, sprechen Sie uns an. Wir haben sowohl native als auch Cross-Platform-Apps ausgeliefert, und wir sagen Ihnen klar, wann ein Rewrite die falsche Entscheidung wäre.