Cross-Platform oder Native, neu gerechnet

Im Januar 2020 hat Shopify erklärt, React Native sei die Zukunft seiner mobilen Apps. Nach fünf Jahren, im Januar 2025, legte das Team nach: Die Apps seien schnell, und die Zukunft von React Native sei "bright". Am 10.09.2026 kam die Kehrtwende. Shopify baut alle vier großen Apps (Shopify, Shop, Point of Sale, Inbox) neu, in Swift und Kotlin.

Die Begründung ist für alle interessant, die gerade eine Framework-Entscheidung treffen oder eine alte verteidigen. Shopify sagt nicht, React Native sei schlecht geworden. Im Ankündigungstext steht ausdrücklich: "React Native apps can be fast. Ours are." Geändert hat sich eine Annahme, auf der die Entscheidung von 2020 stand, und zwar durch Coding-Agenten.

Was sich an der Rechnung geändert hat

2020 hatte Shopify drei Gründe für React Native: Features nicht zweimal bauen, Entwickler über den ganzen Stack arbeiten lassen, weniger Zeit mit Feature-Parität verlieren. Seit Ende 2025 stellen Agenten die erste Annahme in Frage. Shopify formuliert es so: Die Modelle "were capable of making us question whether building software twice still meant doing twice the work."

Beim Prototyping hat das Team Kernteile der größten Apps mit Agenten in Swift und Kotlin nachgebaut. Die Agenten konnten ein Feature auf Android nach dem Vorbild der iOS-Version umsetzen und umgekehrt, sie halfen Entwicklern beim Arbeiten außerhalb ihres Stacks, und gemeinsame Spezifikationen, Tests und Review-Checkpoints senkten die Kosten für die Parität.

Wichtig ist, was Shopify nicht behauptet: "Native still means building and maintaining software on two platforms, that cost has not disappeared." Die doppelte Arbeit ist noch da. Sie ist nur nicht mehr das Argument, das alles entscheidet. Übrig bleiben die Vorteile der Plattform, also Nähe zu den Systemfunktionen, die Werkzeuge von Apple und Google und weniger Schichten zwischen eigenem Code und Betriebssystem.

Was Shopify dafür gebaut hat

Der naheliegende Weg funktioniert laut Shopify nicht: den Agenten auf die React-Native-Codebasis zeigen und die Features in einem Rutsch nativ nachbauen lassen. Selbst mit viel Vorarbeit in Spezifikationen und Aufgabendateien entstehe dabei "a huge amount of unmaintainable code that can't be shipped."

Stattdessen hat das Team ein System namens Helix gebaut, das vom ersten Ergebnis gar nicht erst erwartet, dass es stimmt. Die Arbeit wird in kleine Checkpoints zerlegt, und keiner kommt weiter, bevor er nicht mehrere Prüfungen bestanden hat.

flowchart TB
  A["Entwickler zeigt auf einen Screen"] --> B["Helix liest den React-Native-Code<br/>und plant kleine Checkpoints"]
  B --> C["Agent baut den nächsten Checkpoint<br/>in Swift und Kotlin"]
  C --> D{"Tests grün, visueller Abgleich passt,<br/>zwei kritische Reviews bestanden?"}
  D -- nein --> C
  D -- ja --> E{"Mensch stimmt zu?"}
  E -- nein --> C
  E -- ja --> F["Commit, nächster Checkpoint"]
  class D,E decision
  class F success
  classDef decision fill:#1A3A4A,stroke:#F59E0B,color:#FDE68A
  classDef success fill:#14532D,stroke:#22C55E,color:#86EFAC

Das zweite Werkzeug ist unscheinbarer und für die Framework-Frage vielleicht wichtiger. Agenten ändern Code in Sekunden, brauchen aber Minuten, um das Ergebnis im Simulator zu prüfen. Shopify schreibt dazu: "It doesn't matter how good the model is if it can't test its work quickly, which is especially difficult on mobile." Die Antwort ist Architektur. Die Geschäftslogik wird komplett von der Oberfläche getrennt, läuft ohne UI auf dem Desktop und ist für Agenten über eine Kommandozeile erreichbar. Ein Durchlauf dauert dann Millisekunden statt Minuten. Wie man solche Prüfschleifen um einen Agenten herum grundsätzlich baut, beschreibt Harness Engineering.

Eine Prüfschleife erwähnt Shopify nicht, obwohl der Wechsel sie gleich mitbringt: den Compiler. Swift und Kotlin sind statisch typisiert. Passt ein Typ nicht, lehnt der Compiler den Code ab, bevor der erste Test startet. Für einen Agenten ist das die billigste Rückmeldung überhaupt, und sie fängt viel ab. In einer Studie von Forschenden der ETH Zürich und der UC Berkeley gingen bei TypeScript-Code, den Sprachmodelle erzeugt hatten, im Schnitt 94 Prozent der Kompilierfehler auf fehlgeschlagene Typprüfungen zurück. GitHub nennt die Studie im Octoverse 2025 als einen Grund dafür, dass TypeScript im August 2025 zur meistgenutzten Sprache auf der Plattform wurde: "Typed systems help identify LLM-generated compile errors earlier in the pipeline."

Zur Einordnung: Auch Shopifys React-Native-Code war typisiert, im Rückblick von 2025 schreibt das Team über TypeScript. Nur ist TypeScript nachgiebig. Typen sind optional, ein any schaltet die Prüfung ab, und zur Laufzeit sind die Typen verschwunden. Swift und Kotlin erzwingen sie dagegen, samt Null-Sicherheit. Wer ein Frontend in reinem JavaScript betreibt, hat diese Schleife gar nicht und bezahlt jeden Typfehler mit einem Testlauf, im schlechtesten Fall mit einem Bug in Produktion. Dass die Typisierung bei Shopifys Entscheidung eine Rolle gespielt hat, steht in keinem der Texte. Das ist unsere Einordnung, keine Aussage von Shopify.

Was die erste App gebracht hat

Die Shop-App ist bereits umgestellt. Laut Shopifys Bericht hat ein Ingenieur eine Woche lang mit Agenten einen Prototyp gebaut, danach haben sechs Leute die Grundlagen und die wichtigsten Abläufe umgesetzt, Feature-Teams kamen später dazu. Vom Prototyp bis zur Veröffentlichung in den App Stores vergingen zwölf Wochen.

Beim Lesen dieser Zahlen helfen zwei Hinweise aus demselben Bericht. Shopify hat die Migration genutzt, um die App zu vereinfachen, und dabei "deliberately retiring some screens and streamlining others". Die native App macht also nicht exakt dasselbe wie die alte. Außerdem stand der Umstieg auf die New Architecture von React Native noch aus, verglichen wurde mit dem alten Stand. Beides spricht nicht gegen die Zahlen, aber gegen die Lesart, Native sei pauschal doppelt so schnell.

Der ehrlichste Satz im Bericht betrifft die Agenten selbst: "Native expertise remained essential. Generated code could satisfy feature requirements while still introducing duplication, architectural drift, or performance problems."

Die Gegenrechnung

In der Diskussion auf Hacker News mit über 1.000 Punkten kommen die Einwände, die man auch im eigenen Team hören wird.

Divergenz. Ein Kommentator verlegt die Kosten vom Schreiben ins Auseinanderlaufen: "Feature parity isn't an implementation cost. It's a divergence cost." Sie wächst über Jahre, mit jedem Experiment, jedem Analytics-Event und jedem Sonderfall, der auf einer Plattform anders gelöst wird. Dass zwei Implementierungen heute gleich aussehen, sagt darüber wenig. Shopify weiß das: Der Bericht zur Shop-App beschreibt ein eigenes Werkzeug, das Screenshots und Analytics-Events beider Apps an festen Punkten vergleicht.

Lesen und Testen. Ein anderer Kommentar nennt die zwei Kosten, die mit KI nicht im selben Maß sinken: "1. Reading code 2. Manually testing code". Wer zwei Codebasen hat, liest und testet doppelt. Dazu kommen die Token, denn auch das Generieren und Prüfen kostet pro Plattform.

Teamgröße. Mehrere Stimmen halten die Entscheidung für richtig bei großen Firmen mit viel Budget und für falsch bei Start-ups, die sich zwei Mobile-Teams nicht leisten können. Das deckt sich mit einem Detail aus Shopifys Text: Das Team konnte Helix, eine Test-Kommandozeile und eine Vergleichsinfrastruktur bauen. Das ist eigene Werkzeugentwicklung, keine Einstellung in einem Tool.

Kausalität. Ein Entwickler, der nach eigener Aussage eine ähnliche Migration technisch geleitet hat, schreibt, dort sei der Großteil der Arbeit vor Januar 2026 und ohne KI-Hilfe gelaufen. Sein Grund für den Wechsel war der Aufwand, den React Native im Alltag macht, etwa bei Upgrades. Das ist eine Einzelstimme, erinnert aber daran, dass "wegen der Agenten" auch eine bequeme Erzählung für eine Entscheidung sein kann, die ohnehin fällig war.

Mittelweg. Häufig gefragt wird, warum Shopify Kotlin Multiplatform nicht erwähnt, also geteilte Logik mit nativen Oberflächen. Die Frage bleibt im Ankündigungstext unbeantwortet.

Einen historischen Vergleich gibt es auch. Airbnb hat sich 2018 von React Native verabschiedet, weil das Versprechen vom einmal geschriebenen Code dort nicht aufging: Am Ende pflegte man nach eigener Darstellung Code auf drei Plattformen statt auf zwei. Medium hat dem Text inzwischen einen Hinweis vorangestellt, er spiegle den Stand von Ende 2017 wider und sei kein alleiniger Grund gegen React Native. Mit KI hatte Airbnbs Entscheidung nichts zu tun.

Was das für die eigene Framework-Wahl heißt

Die eigentliche Verschiebung ist nicht "Native gewinnt". Der Engpass wandert: Früher war das Schreiben von Code der teure Teil, und Cross-Platform sparte genau dort. Wenn Agenten das Schreiben übernehmen, wird das Prüfen zum teuren Teil, also Lesen, Testen und Gleichhalten. Die Frage lautet dann nicht mehr "Wie oft müssen wir etwas bauen?", sondern "Wie oft können wir es verlässlich prüfen?". Warum bei KI-Code die Verifikation zum Flaschenhals wird, steht in Akzeptanzrate und Verifikation von KI-Code.

Daraus lassen sich Prüffragen ableiten, die eine Entscheidung besser tragen als die Schlagzeile:

Für eine laufende React-Native-App gibt es noch einen ganz praktischen Punkt. Shopify hat einige der wichtigsten Bibliotheken im Ökosystem gepflegt, und deren Zukunft ändert sich jetzt: React Native Skia wird vom Maintainer unter neuem Namen weitergeführt, das Original-Repo danach archiviert. Für FlashList sucht Shopify eine Firma, die die Pflege übernimmt. Restyle wird bis Ende 2026 am Laufen gehalten und dann nicht mehr gepflegt. Warum solche Wechsel in der Werkzeugkette Aufmerksamkeit verdienen, beschreibt Wenn dein Werkzeug den Besitzer wechselt.

Fazit

Shopify hat keine Glaubensfrage entschieden, sondern eine Rechnung neu aufgemacht, weil sich eine Zahl darin geändert hat. Das ist das eigentlich Übertragbare: Framework-Entscheidungen beruhen auf Annahmen über Kosten, und Coding-Agenten verschieben diese Kosten vom Schreiben zum Prüfen. Wer die Rechnung für sein eigenes Team aufmacht, kommt je nach Größe, Prüfkapazität und Nähe zur Plattform zu einem anderen Ergebnis als Shopify. Ob Shopifys Wette aufgeht, zeigt sich erst, wenn beide Apps ein Jahr lang neue Features bekommen haben.