Nachdem ich im letzten Artikel die vielen Vorteile der Arbeit mit Figma hervorgehoben habe, musste ich die Nutzung von Figma unerwartet unterbrechen.
Wo lag das Problem?
Mein Ziel war es, sämtliche Benutzeroberflächen und Interaktionen in Figma zu modellieren, sodass ich in der späteren Entwicklung keine Designentscheidungen mehr treffen müsste. Leider musste ich jedoch die Entscheidung für den Tech-Stack meiner nativen App-Entwicklung vorziehen. Das Problem dabei: Zu diesem Zeitpunkt wusste ich noch nicht, mit welchen nativen Elementen und Gestaltungsmöglichkeiten ich arbeiten würde. Die Gefahr bestand also, ein Design zu entwerfen, das nur mit erheblichem Aufwand umsetzbar gewesen wäre – und das konnte ich mir aufgrund meiner ohnehin knappen Zeit nicht leisten.
Warum es keine PWA werden sollte
Mit rund 14 Jahren Berufserfahrung als Webentwickler liegt es für mich nahe, eine App mit vertrauten Technologien zu entwickeln. Der erste Gedanke vieler Webentwickler führt hier zu PWAs (Progressive Web Apps). Grundsätzlich ist eine PWA nichts anderes als eine Webseite, deren Ressourcen wie JavaScript, Bilder und HTML lokal auf dem Smartphone gespeichert werden und die im Browser ohne Adresszeile gestartet wird. PWAs werden jedoch nicht über die offiziellen Stores von Apple oder Google installiert, sondern müssen über „versteckte“ Funktionen (bei iOS mehr als bei Android) auf einer Webseite installiert werden.
Für Nutzer, die nicht aus der Tech-Welt kommen, kann das zu Irritationen führen und Misstrauen hervorrufen, noch bevor die App überhaupt auf dem Startbildschirm des Smartphones erscheint. Wenn man Werte wie Vertrauen und Zuverlässigkeit vermitteln möchte, hat man damit schon verloren, bevor die App genutzt wurde. Hinzu kommt, dass Apple die Unterstützung für PWAs in der EU fast komplett deaktiviert hatte. Auch wenn diese Entscheidung teilweise rückgängig gemacht wurde, zeigt es doch, dass PWAs eher stiefmütterlich behandelt werden. Deshalb kam die Möglichkeit, meine Webentwicklungserfahrung über PWAs einzusetzen, nicht infrage.
Warum ich keine separate App für Android und iOS entwickeln wollte
Gleichzeitig wollte ich nicht die Zeit investieren, jeweils eine eigene App für Android und iOS zu entwickeln. Zumal ich in den Programmiersprachen Java/Kotlin und Objective-C/Swift keine ausreichende Erfahrung habe – das wäre ein zeitlicher Albtraum.
Cross Mobile App Entwicklung
Die Anforderungen waren also klar: Eine native App für iOS und Android, aber mit einer gemeinsamen Codebasis. Idealerweise in einer Programmiersprache, die ich bereits beherrsche. In die engere Auswahl kamen für mich Flutter, React Native und NativeScript.
Flutter
Die Ergebnisse, die mit Flutter erzielt werden, sind durchaus beeindruckend. Allerdings stört mich, dass Flutter in Dart entwickelt wird. Dart ist eine von Google entwickelte Programmiersprache, die ursprünglich als Alternative zu JavaScript positioniert wurde. Das Problem: Abseits von Flutter hat Dart kaum Relevanz. Ein weiteres Problem, das ich mit Flutter sehe, ist die begrenzte Unterstützung nativer Geräte-APIs, wenn diese nicht bereits vorhanden sind. Der dritte und letzte Kritikpunkt: Obwohl Flutter-Apps nativ installiert werden, werden die UI-Elemente in einer eigenen Rendering-Engine von Flutter gezeichnet. Auch wenn das Ergebnis gut aussieht und es für einige ein Vorteil sein mag, dass die App auf iOS und Android identisch wirkt, empfinde ich das als Nachteil. Ich möchte eine native App entwickeln, die sich auch nativ anfühlt.
React Native und NativeScript
React Native ist der große Konkurrent in diesem Bereich und hat sich mittlerweile etabliert. Hier wird in React und JavaScript/TypeScript entwickelt, und es werden native Komponenten wie Buttons oder Listen generiert. Sobald jedoch eine Interaktion stattfindet, wird zwischen den nativen Elementen und JavaScript hin- und hergewechselt, wobei die Logik in JavaScript ausgeführt wird.
Dieser Ansatz erlaubt es mir, meine Erfahrung als Webentwickler wiederzuverwenden und gleichzeitig eine (hoffentlich) native App zu entwickeln.
Da React Native vollständig auf dem JavaScript-Framework React basiert und ich hauptsächlich Erfahrung mit Angular habe, entschied ich mich für NativeScript. NativeScript verfolgt einen ähnlichen Ansatz wie React Native, ist jedoch von JavaScript-Frameworks unabhängig. Optional können Frameworks wie Angular, Vue oder auch React eingesetzt werden, aber die Entwickler sind nicht darauf angewiesen.
Das hat mich sehr angesprochen, also habe ich direkt mit einem Tutorial für NativeScript und Angular begonnen.
Ausblick
Im nächsten Kapitel erfährst du, warum ich diese Entscheidung für NativeScript bereut habe und wofür ich mich stattdessen entschieden habe.