Shopify kehrt von React Native zu Native zurück
Shopify moves back to Native from React Native
Shopify vollzieht eine überraschende Kehrtwende: Nach fünf Jahren React Native migrieren die Kanadier ihre mobilen Apps zurück zu Swift und Kotlin. Der Grund ist der rasante Fortschritt von LLMs – KI-Agenten übernehmen Implementierung, Übersetzung und Tests, sodass die doppelte Pflege beider Plattformen nicht mehr der entscheidende Kostenfaktor ist. Die Shop-App wurde bereits in nur zwölf Wochen komplett neu als native App veröffentlicht, das System Helix sichert die Qualität durch automatische Checkpoints.
Wir halten nicht an einer Entscheidung fest, nur weil sie damals erfolgreich war. Wenn sich eine Kernannahme ändert, sind wir bereit, zurückzugehen und zu fragen, ob sie noch die richtige ist.
- Waterluvian
Wenn man jedes Unternehmen, das eine App braucht/hat, auf ein Spektrum setzt, gibt es irgendwo eine Linie, die sie grob in zwei Gruppen teilt: wo Electron/React Native/etc. Sinn ergibt oder nicht. Es ist einfach eine normale Engineering-Entscheidung: Probleme mit begrenzten Ressourcen lösen. Unternehmen haben unterschiedliche Probleme und unterschiedliche Ressourcen.
Ich denke, die Leute in der Tech-Community haben wahrscheinlich auch bemerkt, dass es ziemlich beliebt ist, eine absolute Meinung über die Güte oder Schlechtigkeit dieser Tools zu haben. Da ist so ein magisches Denken, geboren aus Unwissenheit, dass alle einfach nativ gehen sollten oder dass React Native das Allerbeste ist, das überall eingesetzt werden sollte, oder dass KI diese Linie völlig verschwinden lässt.
Ich denke, diese Takes bringen wenig Wert und lenken von dem ab, was interessant ist, und was der Untertitel dieses Artikels sagt: dass sich diese Linie aufgrund von KI verschiebt. Und ich denke, das stimmt wahrscheinlich.
- tonic_note
Modelle sind viel besser darin geworden, native iOS-Apps zu generieren. Der Hauptreiz von RN war, dass man seine Web-Entwickler für die Mobile-Entwicklung nutzen konnte. Das habe ich bei meiner letzten Firma gemacht. Und für ein Startup ist das in Ordnung, aber irgendwann will man dedizierte Native-Engineers, weil jede Plattform wirklich ihre eigenen technischen Meister verdient, die sie optimieren können.
Aber jetzt, wo der ganze Code generiert wird, gibt es kaum noch einen Vorteil, eine RN-App zu haben... fang einfach nativ an. Deine Entwickler werden sowieso kaum Code schreiben.
- atonse
Wir haben dasselbe gemacht – hatten 90% davon über Nacht. Dann haben wir ein paar Tage im Hintergrund damit verbracht, für den letzten Schliff zu feilen.
Unsere App ist kleiner und hat etwa 15-20 Screens. Ich habe um etwa 00:30 Uhr angefangen, dem Codex ein Ziel zu geben, und es hat jeden Screen basierend auf dem React Native Code inventarisiert, dann Android- und iOS-Verzeichnisse erstellt, maestro verwendet (ich hatte dieses Tooling bereits für einen früheren persönlichen App-Build ein paar Wochen zuvor eingerichtet) und hatte das Ganze am Morgen auf Android und iOS zum Laufen gebracht. Es hat etwa 6 Stunden gedauert, während ich geschlafen habe.
Die App ist viel kleiner, startet sofort, und die Android-App sieht (angeblich) nativ aus. Ich sage angeblich, weil ich keine Android-Telefone benutze. Aber sie verwendet Jetpack Compose und Kotlin.
Und ich kenne weder Swift noch Kotlin. Ich sehe ehrlich gesagt keinen Sinn mehr in React Native. Ich weiß, Expo macht sehr coole agentische Sachen, aber ich bin mir einfach nicht sicher, warum ich irgendetwas davon brauchen sollte, wenn ich eine native App schreiben kann.
- pkaler
Ich sitze hier an meinem Schreibtisch mit Blick auf die Cordova Street. Die Straße, nach der Apache Cordova benannt ist. Ich habe diese Debatte jetzt fast zwei Jahrzehnte lang gesehen.
Teams springen auf das neueste Cross-Platform-Framework auf, in der Annahme, dass es die Personalkosten senkt, auf Kosten einer Lowest-Common-Denominator-App auf jeder Plattform.
Letzteres ist wahr, aber Ersteres ist falsch.
Was am Ende passiert, ist, dass Teams mit 20 iOS-Engineers und 20 Android-Engineers anfangen. Sie übernehmen so etwas wie React Native. Dann hat man am Ende ein Team aus 20 Produkt-Engineers und 20 Tooling- und Framework-Engineers.
Ich habe das in den letzten zwei Jahrzehnten unzählige Male gesehen.
- fnthawar2
Wir halten nicht an einer Entscheidung fest, nur weil sie damals erfolgreich war. Wenn sich eine Kernannahme ändert, sind wir bereit, zurückzugehen und zu fragen, ob es noch die richtige Entscheidung ist. LLMs haben eine der Kernannahmen hinter unserer Entscheidung von 2020 verändert, also haben wir unseren Mobile-Stack von Grund auf neu bewertet.
Was wir fanden, führte uns zurück zu Native.
- netshade
Ich stimme zu, dass man Leuten raten sollte, von React Native wegzugehen, obwohl ich denke, dass die Geschichte, dass „LLM eine ansonsten zu teure Migration ermöglicht hat“, nicht korrekt ist.
Ich sage das, weil ich Teil einer Migration von einer mittelgroßen React Native App zu einer Swift/Kotlin Native App-Neufassung war. Ich habe den Großteil der technischen Arbeit daran gemacht. Der Großteil der Arbeit fand vor Januar 2026 statt und ohne LLM-Code-Unterstützung, obwohl spätere Features in der App definitiv etwas davon genutzt haben.
Für alle, die das in Betracht ziehen, würde ich sagen, dass die Migration definitiv eine Überlegung wert ist, selbst ohne LLM-Unterstützung in Betracht zu ziehen. Die anhaltende React-Native-Steuer von unnötig schwierigen Upgrades, Impedanz-Mismatch mit den zugrundeliegenden Kernframeworks und unglaublich ungleichmäßige Bibliotheksqualität führen dazu, dass dein Unternehmen wirklich viel Zeit damit verbringt, die Technologie über die Ziellinie zu bringen. Es ist ziemlich wunderbar, zurück in der Welt von „build, compile, ship, be sure“ zu sein. Eine Sache als grundlegendes Prinzip, die der Shopify-Artikel, wie ich denke, ‚versteht‘, ist die Bedeutung des Feedback-Zyklus – frühzeitig Zeit in unsere Integrationstest-Story zu investieren, hat sowohl meinen Zykluszeiten geholfen als auch später dabei, Leitplanken für LLM-Unterstützung zu bieten.
Alles in allem: Diese Entscheidung ist eine Überlegung wert, selbst ohne LLM-Unterstützung in Betracht zu ziehen.
- lmf4lol
Gestern, kurz vor dem Schlafengehen, habe ich Astra auf unsere Electron Desktop-App gerichtet und es gebeten, mir eine native Swift-App für iOS zu schreiben.
Die Electron-App hat 750 Unit-Tests und 50 irgendwas Integrationstests. Sie hatte auch über mcp Zugriff auf die Electron-App und konnte herumklicken und sie inspizieren. Ich habe Astra auch Nur-Lese-Zugriff auf den Backend-Code gegeben.
Es arbeitete 3 Stunden und lieferte einen fast funktionsvollständigen Port. Heute habe ich beim manuellen Testen 3 Bugs und 1 Performance-Problem gefunden, die es danach alle behoben hat. Um das Performance-Problem zu beheben, hat es mehrere verschiedene Builds erstellt und sie mit Xcode profiliert.
Gegen 12:30 Uhr hatte ich einen vollständig nativen App-Port unseres Produkts auf meinem iPhone und iPad und konnte ihn meiner Crew zeigen. Es hat sogar Hoch- und Querformat korrekt hinbekommen!
Selbstverständlich war ich verblüfft. Einerseits liebe ich es, ich kann jetzt all diese coolen Sachen bauen, aber andererseits ist es eine komplette Entwertung meines Handwerks. Ich rede mir irgendwie ein, dass ich immer noch derjenige war, der eine ordentliche Umgebung dafür eingerichtet hat und dass nicht jeder das kann. Aber das ist Coping. Verdammtes Coping… und ich weiß es.
- underdeserver
Und ich sitze hier und schaue mir die Codex Desktop Mac App an und frage mich, warum eine Liste, ein Chat-Fenster und eine Textbox einen 579 MB großen Download (komprimiert) und 4 GB RAM benötigen.
- jrochkind1
Ich folge dem Teil mit dem/den Simulator(en) nicht ganz, wahrscheinlich weil ich noch nie tatsächlich Mobile-Entwicklung gemacht habe.
> Wenn Simulator-Interaktion benötigt wird, kann sich die CLI über einen Remote-Modus mit ihnen verbinden und die UI über Befehle steuern, ohne das Layout oder den Accessibility-Tree inspizieren zu müssen. Dies ermöglicht blitzschnelle Performance und E2E-Tests.
Ich glaube, ich folge nicht. Muss man nicht trotzdem den Accessibility-Tree und das Layout in der tatsächlichen Schicht testen, mit der der Benutzer interagiert?
- asimovDev
React fallen lassen und als Nächstes zurück zu rohem JavaScript?
Ich trauere immer noch um das GitHub vor React. Vielleicht rosarote Brille, aber es war so angenehm zu benutzen