Wann native Entwicklung gegen Cross-Platform-Frameworks gewinnt

Die kurze Antwort

Geh nativ, wenn das Produkt selbst aus Plattformfunktionen besteht. Kommt der Wert deiner App aus dem, was iOS oder Android ihr erlauben, spart eine gemeinsame UI-Schicht wenig, weil der plattformspezifische Teil das Produkt ist.

Wann nativ die bessere Wahl ist

• Tiefe Betriebssystem-Integration: Screen Time und App-Sperren auf iOS, Accessibility-Services auf Android, Widgets, Live Activities, App Intents und Siri-Kurzbefehle oder Hintergrundverarbeitung, die das System streng einschränkt.
• Neue Plattform-APIs vom ersten Tag an: Eine native App kann eine neue iOS- oder Android-Version übernehmen, sobald sie erscheint, während ein Framework erst eigene Unterstützung braucht.
• Ein plattformnatives Look-and-feel: SwiftUI auf iOS und Jetpack Compose mit Material 3 auf Android folgen standardmäßig der Designsprache und dem Verhalten der jeweiligen Plattform.
• Anspruchsvolle Grafik-, Kamera-, Audio- oder Sensorik-Arbeit, bei der du den kürzesten Weg zu den Plattform-Frameworks willst.
• Die App ist ein langlebiges Kernprodukt, und das Team investiert über Jahre in jede Plattform.

Was KI-gestützte Entwicklung ändert

Der klassische Grund für Cross-Platform waren die Kosten: eine Codebasis statt zwei. Code entsteht mit KI-Unterstützung heute deutlich schneller, und eine zweite Implementierung nach einer fertigen ersten ist eine Aufgabe, die KI-Werkzeuge gut lösen. Die Ersparnis durch eine gemeinsame Codebasis ist geschrumpft, der Preis einer zweiten nativen App gesunken.

Review und Tests brauchen auf beiden Plattformen weiterhin menschliche Zeit, nativ ist also nicht gratis. Aber bei Produkten, die ohnehin native Qualität brauchen, ist der Kostenabstand so klein geworden, dass er die Frage nicht mehr entscheiden sollte.

Ein echtes Beispiel: Momento

Momento, die eigene App von AppJoy, fragt, warum du eine App öffnen, bevor sie sich öffnet. Auf iOS stützt sich das auf die Screen-Time-API sowie Widgets und Live Activities. Auf Android stützt es sich auf einen Accessibility-Service. AppJoy hat es zuerst mit Flutter gebaut und dann als SwiftUI-App und Kotlin-App mit Jetpack Compose neu geschrieben, weil der Kern des Produkts plattformspezifisch ist und die gemeinsame Schicht dünn gewesen wäre.

Wann Cross-Platform weiterhin gewinnt

• Du brauchst Website und App mit gemeinsamem Code, wie bei HighratedHotels mit Expo und Next.js.
• Die Oberfläche ist individuell gestaltet und soll auf beiden Plattformen identisch aussehen.
• Hardwarezugriff ist der Hauptbedarf und es gibt ein gutes Plugin. caberQU spricht mit seinem Gerät per Bluetooth Low Energy aus einer Flutter-App, Bluetooth allein ist also kein Grund für nativ.
• Budget oder Zeit sind knapp und die App ist eine Standard-Business-App.

Fragen vor der Entscheidung

• Welche Funktionen gibt es nur auf einer Plattform, und sind sie der Kern des Produkts?
• Brauchst du eine Website, die Code mit der App teilt?
• Wer wartet die App in zwei Jahren, und welche Kenntnisse hat er?
• Reicht ein Prototyp in einem Framework, um das herauszufinden? Ein Neuschreiben ist möglich, wie Momento zeigt.