Eine Anwendung separat für iOS und Android zu entwickeln bedeutet, zwei Implementierungen zu pflegen. Über Jahre konnten Teams durch gemeinsam genutzten Code mehr Budget für Funktionen und deren Weiterentwicklung einsetzen. Programmieragenten können inzwischen einen Teil dieser Arbeit günstiger machen. Die technische Entscheidung verdient deshalb eine neue Prüfung.
Bei Appik sehen wir diese Veränderung als zusätzliche Möglichkeit für mobile Projekte. Unsere Erfahrung mit nativer Entwicklung, React Native und dem Web hilft uns, die Optionen anhand des Produkts, seiner Nutzer und seiner Wartung zu vergleichen.
Shopify und Coinbase prüfen ihre mobile Entwicklung neu
Am 10. September 2026 kündigte Shopify die Rückkehr zu Swift und Kotlin an. Agenten haben die Kosten für zwei Implementierungen verändert. Laut dem Unternehmen sind seine React-Native-Apps schnell, und das Framework hat die erwarteten Vorteile gebracht.
Coinbase beschreibt in einer offiziellen Stellenausschreibung eine KI-gestützte Neuentwicklung seiner mobilen App in Swift und Kotlin. Das Projekt läuft noch. Die Ausschreibung kündigt keine bereits abgeschlossene Migration an.
Diese Entscheidungen werfen eine nützliche Frage für Produktverantwortliche auf. Wenn die Entwicklung und Pflege zweier Versionen günstiger wird, welche plattformspezifischen Vorteile rechtfertigen diese Investition für unsere Anwendung? Die Antwort hängt auch von den verfügbaren Teams und Ressourcen ab.
Warum Appik gemeinsam genutzten Code eingeführt hat
Bevor wir mit React Native arbeiteten, entwickelten wir bereits native iOS- und Android-Anwendungen. Gemeinsam genutzter Code löste ein konkretes Problem. Eine Funktion, die auf einer Plattform verfügbar war, musste häufig auf der anderen neu entwickelt und danach auf dieselbe Weise weiterentwickelt werden.
Gemeinsam genutzter Code reduzierte diese wiederholte Arbeit und ermöglichte weiterhin leistungsfähige Anwendungen. Je nach Nutzerablauf konnten bestimmte Geschäftsregeln und Komponenten auch im Web verwendet werden. Anpassungen an die Plattformen blieben notwendig.
Für ein KMU, das ein Werkzeug auf dem Smartphone und dem Computer anbieten muss, bleibt dieser Ansatz sinnvoll. Das Budget kann in bessere Abläufe im Ausseneinsatz, die Anbindung des ERP oder die Vorbereitung einer Produktübernahme durch ein anderes Team fliessen. Der Anteil des gemeinsam genutzten Codes ist ein Mittel zum Zweck. Das Ziel ist ein nutzbares Produkt, das langfristig gepflegt werden kann.
React Native kann eine sehr gute Leistung bieten
Eine React-Native-Oberfläche ist keine Webseite innerhalb einer App. Die Architektur von React Native verbindet React mit nativen Komponenten und Funktionen. Anschliessend spielen die Wahl der Rendering-Werkzeuge und die Organisation der Berechnungen eine grosse Rolle.
Skia und Graphite für die Grafikdarstellung
React Native Skia verwendet die C++-Grafikengine Skia und deren JSI-Integration. Damit lassen sich Oberflächen, Diagramme und Effekte auf einem Canvas zeichnen, ohne dass JavaScript jedes Pixel berechnen muss.
Die Version 3.0.2 im Repository von William Candillon, veröffentlicht am 3. Oktober 2026, verwendet Graphite als Standard-API. Diese Änderung betrifft den neuen v3-Zweig. Sie bedeutet nicht, dass alle Anwendungen mit älteren Versionen die Engine gewechselt haben.
Google beschreibt Graphite als Architektur für moderne GPU-APIs. Sie ermöglicht unter anderem, Grafikarbeit mit unabhängigen Recordern vorzubereiten. Für individuelle Darstellungen ist das praktisch relevant. Der Einsatz muss auf den vorgesehenen Geräten geprüft werden.
Reanimated für Interaktionen und Animationen
Reanimated verwendet Worklets auf dem UI-Thread. Die Logik einer Animation kann dadurch laufen, ohne darauf zu warten, dass die JavaScript-Hauptlaufzeit eine andere Aufgabe beendet.
Das bietet geeignete Werkzeuge für das Verschieben einer Karte, ein interaktives Diagramm oder einen durch Gesten gesteuerten Übergang. Der Leitfaden zur Performance von Reanimated weist jedoch darauf hin, dass Versionen, animierte Eigenschaften und die Anzahl der Komponenten das Ergebnis beeinflussen. Eine Bibliothek behebt eine ressourcenintensive Architektur nicht automatisch.
Worklets für Berechnungen an der richtigen Stelle
React Native Worklets unterscheidet die Laufzeiten RN, UI und Worker. Bestimmte JavaScript-Funktionen können in einer eigenen Laufzeit ausgeführt werden, etwa für die Datenverarbeitung. Dadurch werden sie nicht zu Swift- oder Kotlin-Code.
Es geht darum, dass eine Berechnung die für Interaktionen benötigten Ressourcen nicht allein beansprucht. Auch der Austausch zwischen Laufzeiten verursacht Aufwand. Die gesamte Arbeit ohne Messung zu verlagern wäre eine schlechte Strategie.
Legend List für lange Listen
Legend List v2 verwendet Virtualisierung und bietet das Recycling von Komponenten. Beim Scrollen können Elemente wiederverwendet werden, statt sie neu zu erstellen. Die veröffentlichten Benchmarks vergleichen React-Native-Listenlösungen. Sie belegen keinen Vorteil gegenüber sämtlichen nativen Listen.
Diese Werkzeuge sind für einen Nachrichtenverlauf, einen Katalog oder eine Liste von Serviceeinsätzen relevant. Zu grosse Bilddateien oder Zeilen, die ihren Inhalt ständig neu berechnen, können das Scrollen trotzdem beeinträchtigen.
Kann React Native eine native Implementierung übertreffen?
Ja, das ist bei einem bestimmten Nutzerablauf möglich. Eine React-Native-Darstellung, die eine C++-Engine und die GPU nutzt, kann weniger Arbeit erfordern als eine andere Implementierung desselben Bildschirms mit vielen Komponenten und Aktualisierungen. Das ist eine technische Möglichkeit, die gemessen werden muss. Wir versprechen dieses Ergebnis nicht für jedes Projekt.
Auch Swift und Kotlin können die GPU und spezialisierte Engines nutzen. Die genannten Werkzeuge zeigen vor allem, warum eine Sprache oder ein Framework allein nicht ausreicht, um eine flüssige Bedienung vorherzusagen.
Für den Vergleich zweier Optionen verwenden wir dieselben Interaktionen, Inhalte und Geräte sowie Produktionsversionen. Wir untersuchen die Reaktionszeit, ausgelassene Frames beim Scrollen, den Start, den Speicherbedarf und den Energieverbrauch. Ein flüssiger Bildschirm auf einem leistungsstarken Smartphone beweist nicht, dass die gesamte Anwendung den Anforderungen im Ausseneinsatz entspricht.
KI erweitert die Möglichkeiten, auch für React Native
Agenten können helfen, eine Funktion anzupassen, Tests vorzubereiten und eine Implementierung für eine andere Plattform vorzuschlagen. In unserer Arbeit sind sie auch für React und React Native sehr nützlich. Wir können diese Wirksamkeit nicht sicher auf den Umfang ihrer Trainingsdaten zurückführen, da wir diesen nicht kennen.
Die wirtschaftliche Frage betrifft die Kosten des Produkts über die Zeit. Zwei native Anwendungen brauchen weiterhin Tests, Veröffentlichungen und die Beobachtung von Änderungen der Betriebssysteme. Eine gemeinsame Codebasis erfordert ebenfalls Arbeit an Abhängigkeiten, nativen Teilen und Unterschieden zwischen den Plattformen.
Eine Organisation, die zwei Versionen pflegen kann, profitiert möglicherweise stärker vom direkten Zugang zu den Werkzeugen von Apple und Google. Ein Team, das für Mobile und Web entwickeln muss, kann gemeinsam genutzten Code bevorzugen. Eine bestehende React-Native-Anwendung, die den Bedürfnissen ihrer Nutzer entspricht, sollte geprüft werden, bevor eine Neuentwicklung finanziert wird.
Bonani und unsere Arbeit mit nativer Entwicklung
Wir haben Bonani, ein kleines Geburtstagsnotizbuch, nativ für iOS und Android entwickelt. Der begrenzte Umfang erlaubt uns, diesen Ansatz an einem konkreten Produkt mit lokalen Daten, Zugriff auf Kontakte und Erinnerungen zu erproben.
Bonani verwendet SwiftUI und SwiftData auf iOS sowie Kotlin, Jetpack Compose und Room auf Android. Die Oberflächen sind getrennt, die Regeln und Testbeispiele bleiben jedoch gemeinsam. Für einen Geburtstag ohne Jahresangabe wird kein Alter berechnet. Ein Geburtstag am 29. Februar bleibt als solcher gespeichert, auch wenn die Erinnerung auf den 1. März fällt.
Bonani liefert keinen Performance-Benchmark gegen React Native. Aus dem begrenzten Umfang lassen sich keine Schlüsse für eine grosse Unternehmensanwendung ziehen.
Bei Appik möchten wir die Erfahrung nutzen, die wir in den vergangenen zehn Jahren gesammelt haben, um mit Unterstützung von Agenten die passende Technologie für jedes Projekt zu wählen. Das Team bleibt für die Architektur, die Prüfung auf Geräten und die Inbetriebnahme verantwortlich.
Welcher Ansatz passt zu Ihrer Anwendung?
Planen Sie eine mobile Anwendung oder möchten Sie ein bestehendes Produkt weiterentwickeln? Nehmen Sie Kontakt mit Appik auf, um Ihr Vorhaben zu besprechen. Wir können Ihre Anwendungsfälle, Integrationen und die Anforderungen prüfen, die die Wahl zwischen nativer Entwicklung, React Native und Web bestimmen.
Quellen und Referenzen
- Shopify · Rückkehr zur nativen Entwicklung
- Coinbase · Laufende Neuentwicklung der mobilen App
- React Native · Architektur
- Shopify · Skia, C++ und JSI
- React Native Skia · Graphite als Standard in v3.0.2
- Google · Graphite-Grafikarchitektur
- Reanimated · Animationen und Worklets
- Reanimated · Performance-Leitfaden
- React Native Worklets · RN-, UI- und Worker-Runtimes
- Legend List · Virtualisierung, Recycling und v2-Benchmarks
Swiss Made Software
