Das ist wohl die Frage schlechthin bei jedem App-Projekt gerade. Aber erst einen Schritt zurück.
Android und iOS sind grundlegend unterschiedliche Systeme, genau wie macOS und Windows. Eine iOS-App läuft nicht auf Android und umgekehrt. Das heißt: für eine Smartphone-App entwickelt man eigentlich zwei Apps. Einmal für iOS, einmal für Android. Doppelter Aufwand, doppelte Kosten. Da schluckt man, ja.
Cross-Platform: Die Lösung?
Es gibt Ansätze, die genau das lösen sollen: Cross-Platform-Entwicklung und Hybrid-Apps. Z.B. Webseiten laufen auf beiden Plattformen ohne Unterschied, also ist es eine naheliegende Idee, darauf aufzubauen. Ansätze wie Xamarin, Ionic, Flutter und Kotlin Multiplatform machen das möglich.
Der Haken an der Sache
Leider nicht ganz. Hybrid-Apps (Webseiten, die als Apps verpackt werden) fühlen sich oft nicht wirklich wie Apps an. Irgendetwas schwingt von Webseite mit. Meine persönlichen Erfahrungen mit Ionic sind geprägt von Inkompatibilität, Instabilität und mangelhafter Verlässlichkeit. Eine Einschätzung, die mir bereits mehrere Kollegen bestätigt haben.
Ähnlich verhält es sich mit Cross-Platform-Frameworks wie Xamarin und Flutter. In der Theorie eine tolle Idee. In der Praxis stößt man immer wieder auf Gegebenheiten, die man für iOS auf eine Art und für Android auf eine andere Art lösen muss. Eine Stelle, dann noch eine, dann noch eine… und plötzlich hat man ein Ungetüm, das schwer wartbar ist und im Kern doch wieder zwei Projekte in einem sind. Gewonnen hat man wenig, außer der Abhängigkeit zu einem Framework auf das man kaum Einfluss hat.
Das ist meine Ansicht, geteilt von befreundeten Entwicklern, aber natürlich nicht von allen.
Unter’m Strich kommt es auf folgende Fragen an:
- Was ist das Ziel der App?
- Wie lange soll sie leben und weiterentwickelt werden?
- Wie schnell muss sie auf den Markt?
- Kann danach mehr Zeit in eine saubere Version 2 investiert werden?
Ist die Zeit das entscheidende Kriterium, kann eine Cross-Platform- oder Hybrid-Lösung trotz aller Nachteile sinnvoll sein. Aber: Das dauerhafte Festhalten an kurzfristigen Lösungen sorgt dafür, dass nie langfristig geplant wird. In der Softwareentwicklung nennt man das technical debt, also technische Schulden, die irgendwann beglichen werden müssen. Manchmal sind diese so hoch, dass sich nach einem Jahr eine komplette Neuentwicklung wirtschaftlich lohnt.
Ist der langfristige Horizont entscheidend, empfehle ich eine native Lösung. Auf Dauer rechnet sich das, und man ist flexibel. Unabhängig von Limitierungen der Frameworks.