Am 10. September hat Mustafa Ali im Shopify-Engineering-Blog geschrieben, dass Shopify React Native für seine großen Mobile-Apps aufgibt und sie in Swift und Kotlin neu baut. Das ist die Nachricht. Die Begründung ist die eigentliche Geschichte.
Nicht React Native ist schlechter geworden
Shopify sagt nicht, dass React Native nachgelassen hat. Sie sagen, die Rechnung stimmt nicht mehr: Coding-Modelle seien dramatisch besser geworden, und für ihre Apps und ihr Team kostet dasselbe Feature zweimal, einmal in Swift und einmal in Kotlin, nicht mehr so viel wie früher.
Genau darauf stand der ganze Cross-Platform-Fall. Eine Codebasis statt zwei, ein Team statt zwei, ein Feature statt zwei. Wer diese Zahl halbiert, halbiert das Argument.
Konkret nennt Shopify drei Dinge, die ihre Agenten seit Ende 2025 können: ein Feature auf einer Plattform bauen und die andere als Vorlage nehmen. Entwicklern helfen, außerhalb ihres Spezialgebiets zu arbeiten – der iOS-Mensch kommt im Kotlin-Code weiter, als er allein käme. Und die Plattform-Parität über gemeinsame Spezifikationen, Tests und Review-Punkte halten, statt über gemeinsamen Code.
Als Beleg steht die Shop-App da: von der Idee bis in den App Store in zwölf Wochen, mit KI-Unterstützung. Die Shop-App ist schon native ausgeliefert, die Shopify-App ist unterwegs und soll noch 2026 kommen, die übrigen folgen.
Drei Bibliotheken verlieren ihren Sponsor
Das ist der Teil, der über Shopify hinausgeht. Shopify hat React Native nicht nur benutzt, sondern große Teile seines Ökosystems bezahlt:
- React Native Skia wird bis Ende 2026 weiter gesponsert. Danach wird das Repo archiviert. William Candillon forkt es und veröffentlicht es unter neuem Namen weiter.
- FlashList hat zwei Millionen Downloads pro Woche. Shopify behebt nur noch kritische Fehler und sucht jemanden, der langfristig übernimmt.
- Restyle wird archiviert, bis Ende 2026 gepflegt, danach nicht mehr.
Zwei Millionen Downloads pro Woche für eine Liste, die niemand mehr betreut, ist das eigentliche Risiko dieser Ankündigung. Nicht für Shopify – für alle anderen.
Was daran neu ist
Wir haben in den letzten Monaten viel darüber gelesen, dass Agenten Code schreiben, Tests reparieren und Reviews machen. Das ist Arbeit innerhalb einer Architektur, die vorher schon feststand.
Hier passiert etwas anderes. Eine Architekturentscheidung, die vor zehn Jahren aus Kostengründen getroffen wurde, wird zurückgenommen, weil die Kosten sich verschoben haben. Das ist die erste große Umkehr dieser Art, die ich sehe, und die Logik ist auf unangenehme Weise sauber: Wenn doppelte Arbeit billig wird, verliert jede Abstraktion, deren Zweck es war, doppelte Arbeit zu vermeiden.
Man kann das weiterdenken, und ich bin nicht sicher, ob mir gefällt, wo es hinführt. Cross-Platform-Frameworks sind nur ein Fall. Geteilte Bibliotheken, Monorepos, generische Schichten für zwei Fälle statt zwei konkreter Lösungen – vieles davon existiert aus demselben Grund. Wer die Shopify-Begründung ernst nimmt, muss diese Frage an jede dieser Stellen neu stellen.
Zwei Einschränkungen gehören dazu. Shopify hat ein großes Mobile-Team, viele Nutzer und Geld für so einen Umbau – die Rechnung fällt bei drei Entwicklern und einer App anders aus. Und geteilter Code spart nicht nur Tipparbeit, sondern hält Verhalten synchron. Spezifikationen und Tests können das auch, nur muss sie jemand pflegen, und diese Arbeit taucht in Shopifys Rechnung nicht auf.
Quellen: Shopify Engineering: Back to Native, Simon Willison