Einer aktuellen Meldung zufolge kehrt Shopify bei der Entwicklung seiner mobilen Anwendungen zur nativen Programmierung zurück. React Native – ein Framework, mit dem sich iOS- und Android-Apps aus einer gemeinsamen Codebasis erzeugen lassen – hat dort ausgedient. Als Begründung werden Fortschritte beim KI-gestützten Programmieren genannt: Der Mehraufwand, zwei getrennte Codebasen zu pflegen, wiegt offenbar nicht mehr so schwer wie bisher.

Die Nachricht ist aus zwei Gründen bemerkenswert. Erstens hatte Shopify Cross-Platform-Entwicklung über Jahre öffentlich vertreten. Zweitens berührt die Kehrtwende eine Abwägung, die in fast jedem Mobilprojekt früher oder später auf dem Tisch liegt.

Worum es bei der Abwägung eigentlich geht

Cross-Platform-Frameworks lösen ein ökonomisches Problem, kein technisches. Nativ entwickelte Apps – also Anwendungen, die mit den Werkzeugen und Sprachen der jeweiligen Plattform gebaut werden – gelten seit jeher als näher am System: bessere Integration neuer Betriebssystemfunktionen, feinere Kontrolle über Performance und Bedienverhalten. Der Preis dafür ist, dass jede Funktion zweimal gebaut, zweimal getestet und zweimal gewartet werden muss.

Genau dieser Preis war das Hauptargument für gemeinsame Codebasen. Ein Team statt zwei, eine Fachlogik statt zwei Varianten, ein Release-Prozess statt paralleler Abläufe. Wer knappe Entwicklungskapazität hat, wählte in der Regel den Weg, der weniger Personen bindet.

Wenn KI-Assistenten nun einen Teil der Routinearbeit übernehmen – Portierungen zwischen Sprachen, Boilerplate, Testgerüste, das Nachziehen einer Änderung in der zweiten Codebasis –, verschiebt sich diese Rechnung. Nicht, weil nativ plötzlich besser geworden wäre, sondern weil der Nachteil der doppelten Pflege an Gewicht verliert. Die Argumente für die Plattformnähe bleiben, die Gegenargumente schrumpfen.

Warum das nicht automatisch für jedes Projekt gilt

Aus einer einzelnen Entscheidung eines großen Anbieters lässt sich keine allgemeine Regel ableiten. Shopify verfügt über eigene Mobilteams, etablierte Werkzeugketten und genug Volumen, um Werkzeuge intern zu bauen und auszurollen. Ein mittelständisches Unternehmen mit einer App, die von einer externen Agentur betreut wird, steht vor anderen Rahmenbedingungen.

Entscheidend ist deshalb weniger, was Shopify tut, als welche Größe sich in der Gleichung verändert hat. Und das ist der Aufwand pro Codezeile in wiederkehrender, gut strukturierter Arbeit. Wer diese Größe in seiner eigenen Organisation nicht gemessen hat, kann die Rechnung auch nicht neu aufstellen.

Hinzu kommt: Doppelte Codebasen bedeuten nicht nur doppelte Entwicklungsarbeit. Sie bedeuten auch doppelte Abhängigkeitspflege, doppelte Sicherheitsupdates, doppelte Abstimmung mit dem Design, doppeltes Onboarding neuer Mitarbeitender. KI-Assistenz greift bei diesen Punkten unterschiedlich stark. Codegenerierung ist etwas anderes als die Verantwortung dafür, dass beide Apps sich in drei Jahren noch gleich verhalten.

Was das für laufende Technologieentscheidungen heißt

Viele Architekturentscheidungen in Unternehmen stammen aus einer Zeit, in der bestimmte Annahmen galten: Ein zweites Frontend ist teuer. Eine eigene Schnittstelle lohnt sich erst ab einer gewissen Größe. Eine Migration ist zu aufwendig, also bleibt das Altsystem. Diese Annahmen sind selten dokumentiert, sie stecken meist als stille Voraussetzung in Protokollen und Angeboten.

Sinnvoll ist daher ein nüchterner Blick auf die eigenen offenen Punkte:

  • Welche Entscheidung wurde primär mit Aufwand begründet? Dort lohnt eine Neubewertung am ehesten. Entscheidungen, die aus fachlichen oder regulatorischen Gründen fielen, bleiben davon unberührt.
  • Wie viel der betroffenen Arbeit ist tatsächlich repetitiv? Übersetzungsarbeit, Datenmodell-Mapping und Testabdeckung profitieren anders als Konzeption, Schnittstellendesign oder Fehlersuche in verteilten Systemen.
  • Wer trägt die Wartung? Ein Ansatz, der in der Erstellung günstiger wird, in der Pflege aber mehr Personen bindet, ist nicht zwingend der günstigere.
  • Gibt es belastbare eigene Erfahrungswerte? Ohne gemessene Durchlaufzeiten aus dem eigenen Team bleibt jede Aufwandsschätzung unter KI-Einsatz Spekulation.

Vorsicht vor der Gegenbewegung

Es wäre ein Missverständnis, aus dieser Meldung abzuleiten, dass gemeinsame Codebasen ausgedient hätten. Für viele Anwendungsfälle – Anwendungen mit überschaubarer Oberfläche, starkem Fokus auf Inhalte, klaren Standardinteraktionen – bleiben die alten Argumente gültig. Auch die Web-Variante einer Anwendung verschwindet nicht, nur weil native Entwicklung wieder attraktiver wird.

Realistisch ist eher, dass die Bandbreite vertretbarer Entscheidungen größer wird. Wo früher eine Option aus Kostengründen faktisch ausschied, stehen künftig mehrere Wege offen. Das erhöht den Anspruch an die Begründung: Eine Technologiewahl lässt sich nicht mehr allein damit rechtfertigen, dass sie die billigste sei.

Für Web- und Softwareprojekte bedeutet das vor allem eines: Architekturentscheidungen sollten ein Ablaufdatum bekommen. Wer festhält, unter welchen Annahmen eine Entscheidung getroffen wurde, kann sie überprüfen, sobald sich diese Annahmen ändern – und das geschieht derzeit spürbar. Der eigentliche Wettbewerbsvorteil liegt weniger im Werkzeug als in der Fähigkeit, alte Festlegungen ohne Prestigeverlust wieder aufzumachen.

Quellen