Nativ oder plattformübergreifend: wie wir entscheiden
Mit beiden Ansätzen lassen sich gute Apps veröffentlichen. Welcher der richtige ist, hängt vom Produkt, dem Team und der Zeit nach der Veröffentlichung ab.
Eine der ersten technischen Fragen bei einer neuen App ist, ob man sie zweimal baut – einmal für jede Plattform – oder einmal mit einem plattformübergreifenden Framework. Auf beiden Seiten gibt es starke Meinungen. Wir haben keinen festen Favoriten. Wir beginnen mit einigen Fragen zum Produkt und den Personen, die es künftig betreuen.
Die Optionen
Nativ bedeutet, die iOS-App in Swift und die Android-App in Kotlin zu entwickeln – jeweils mit den eigenen Werkzeugen und Interface-Frameworks der Plattform. Plattformübergreifende Frameworks wie React Native und Flutter ermöglichen es, eine einzige Codebasis auf beiden Systemen auszuführen. Kotlin Multiplatform liegt dazwischen: geteilte Geschäftslogik mit Benutzeroberflächen, die entweder geteilt oder auf jeder Seite nativ geschrieben werden können.
Wann sich nativ lohnt
Nativ ist sinnvoll, wenn die App stark auf die jeweilige Plattform angewiesen ist: anspruchsvolle Kamera- oder Audiofunktionen, Widgets und Watch-Apps, tiefe Integrationen in Systemfunktionen oder fordernde Grafiken. Es hilft auch dann, wenn sich die App auf jeder Plattform vollkommen vertraut anfühlen und neue Plattform-Features sofort nach Erscheinen nutzen soll. Der Preis dafür sind zwei Codebasen, was meist mehr Personal, mehr Zeit oder beides bedeutet.
Wann sich plattformübergreifend lohnt
Plattformübergreifend ist sinnvoll, wenn die App überwiegend aus Ansichten, Formularen, Listen und Netzwerkabfragen besteht – was auf viele geschäftliche Apps zutrifft. Eine Codebasis bedeutet, dass Funktionen nur einmal entwickelt und getestet werden müssen, und beide Plattformen gleichzeitig erscheinen. Wenn das Team bereits TypeScript für das Web schreibt, kann es mit React Native diese Kenntnisse und Teile des Codes wiederverwenden.
Achten Sie auf das Team, nicht nur auf die App
Die beste Technologie ist die, die Ihr Team nach der Veröffentlichung auch pflegen kann. Wenn die App an ein internes Team übergeben werden soll, bauen Sie mit Technologien, die dieses Team bereits kennt oder für die es Personal einstellen kann. Ein Framework, das niemand im Team versteht, wird zum Risiko, sobald etwas auf eine Weise fehlschlägt, die nicht in der Dokumentation steht.
Rechnen Sie dennoch mit nativem Aufwand
Plattformübergreifend bedeutet selten, dass gar kein plattformspezifischer Code nötig ist. Push-Benachrichtigungen, In-App-Käufe, Hintergrundaufgaben und manche Gerätefunktionen erfordern weiterhin eine native Einrichtung, und jeder Store hat seinen eigenen Release-Prozess. Planen Sie bei jedem plattformübergreifenden Projekt etwas native Arbeit ein, und stellen Sie sicher, dass jemand im Team das beherrscht.
Die Geschäftslogik portabel halten
Welchen Weg Sie auch wählen: Halten Sie die Geschäftslogik des Produkts – wie Preise, Berechtigungen und Berechnungen – getrennt von den Benutzeroberflächen und nach Möglichkeit auf dem Server. Das erleichtert das Testen, sorgt für Konsistenz zwischen den Plattformen und macht einen späteren Strategiewechsel deutlich weniger schmerzhaft.
Die Kurzfassung
Wählen Sie nativ, wenn die App stark von der Plattform abhängt, und plattformübergreifend, wenn es vor allem um Ansichten und Daten geht. Entscheiden Sie sich in jedem Fall für eine Lösung, die das Team über Jahre hinweg pflegen kann. Die Wahl wiegt weniger schwer als eine saubere Umsetzung.