Bis vor Kurzem haben wir uns bei der Entwicklung von Apps auf die native Umsetzung konzentriert: Eine App wird separat für iOS und Android in der jeweiligen Sprache erstellt und auf die jeweilige Plattform ausgerichtet. Das hat Vorteile, zum Beispiel kann man immer sofort auf Neuerungen der jeweiligen Plattformen reagieren und natürlich auch die Eigenheiten von iOS oder Android berücksichtigen.
Seit den Anfängen der App-Entwicklung gab es plattformübergreifende Lösungen, die kamen und wieder verschwanden. Jede hatte ihre Vor- und Nachteile, aber unter dem Strich hat uns keine wirklich überzeugt. Im Dezember 2018 hat Google mit Flutter eine weitere plattformübergreifende Lösung vorgestellt, die in letzter Zeit immer mehr Anhänger findet.
Auch wir sind vor einiger Zeit auf den Flutter-Zug aufgesprungen und haben in einigen Projekten unsere Erfahrungen gemacht. Hier möchten wir nun einen Überblick über diese Erfahrungen geben und auf die Stärken und Schwächen von Flutter eingehen. Mit dem Wissen, was Flutter gut kann und was vielleicht weniger, lässt sich dann auch ein bisschen besser abschätzen, mit welchen Einsparungen man bei der Umsetzung einer App rechnen darf.
Flutter – Stärken und Schwächen
Nun, was kann Flutter und was kann Flutter nicht? Um eine Ahnung von der Antwort zu erhalten, hilft ein Blick in den Wikipedia-Eintrag (https://de.wikipedia.org/wiki/Flutter_(Software)) zu Flutter:
Flutter ist ein -UI-Entwicklungs-Kit von . Mit Flutter können in der Programmiersprache entwickelt werden.
Etwas überspitzt gesagt, kann man mit Flutter also in erster Linie UIs (User-Interfaces) erstellen. Mit verhältnismässig wenig Aufwand lassen sich toll aussehende Apps erstellen und diese auch für unterschiedliche Plattformen bereitstellen – in unserem Fall iOS und Android. Apps bieten aber noch viele weitere Funktionalitäten nebst ansprechenden UIs: sie können über Bluetooth mit anderen Geräten kommunizieren, unterschiedlichste Dateien auf dem Mobil-Telefon lesen oder erstellen, die aktuelle Geoposition bestimmen und unzählige weitere Dinge. Die meisten dieser Funktionalitäten sind jedoch sehr plattformspezifisch umgesetzt und müssen auch so angewendet werden. Das heisst für einen Entwickler, dass er für die Bluetooth-Kommunikation mit einem anderen Gerät den Code für iOS und Android jeweils anders erstellen muss. Flutter wäre nicht so erfolgreich, wenn bereits nach den UIs Schluss wäre und zum Beispiel keine Bluetooth-Kommunikation in einer App eingebunden werden könnte.
Framework & Packages
Flutter als Framework konzentriert sich wie bereits erwähnt auf das Erstellen von UIs und dem Builden von Apps für unterschiedliche Plattformen. Alles, was darüber hinausgeht, wird nicht direkt als Funktionalität des Flutter-Frameworks bereitgestellt, sondern als sogenannte Package, welche von jedermann erstellt und veröffentlicht werden können. Um beim Beispiel der Bluetooth-Kommunikation zu bleiben, bedeutet dies, dass hierfür auf https://pub.dev/ ein entsprechendes Bluetooth-Package gesucht und dann in das entsprechende App-Projekt eingebunden werden kann. Es gibt zig-tausende Packages, welche alle nur erdenklichen Funktionalitäten bieten – der Himmel auf Erden für jeden Entwickler. Das Problem ist nur, es ist nicht garantiert, dass der Entwickler eines Packages dieses auch in Zukunft weiterhin betreut und weiterentwickelt. Sich auf Packages zu verlassen kann als durchaus auch riskant sein, da nicht sichergestellt ist, dass es auch in Zukunft noch brauchbar ist.
Das Verwenden von Packages kann also durchaus riskant sein, es besteht aber auch die Möglichkeit, dass für einen bestimmten Anwendungsfall gar kein Package existiert. Ein Beispiel hierfür kann das Einbinden einer Library eines Payment-Providers sein. In solch einem Fall kann man für Flutter auch selber Packages erstellen. Das kann zwar je nach Komplexität von relativ einfach bis sehr aufwändig sein, so oder so hat man aber die volle Kontrolle über den eingebundenen Code. Im Beispiel der Payment-Provider-Library müsste hierfür Code auf drei Ebenen geschrieben werden: im gemeinsamen Flutter-Teil, im iOS- und auch im Android-Teil. Das könnte dann zum Beispiel so aussehen:
In diesem Beispiel sehen die Code-Schnipsel auf iOS und Android sehr ähnlich aus – der Aufwand diese fiktive Payment-Provider-Library einzubinden scheint also relativ gering zu sein. Leider gibt es aber oftmals auch Libraries welche für iOS und Android komplett unterschiedlich einzubinden sind. In solch einem Fall steigt der Aufwand zum Einbinden sehr schnell an: Es gibt dann Komplexität in iOS, andere Komplexität in Android und als wäre das nicht genug, müssen die beiden komplexen Teile zusammen in Flutter noch angesprochen und orchestriert werden. In solch einem Fall schwinden die Vorteile einer Cross-Platform-Entwicklung natürlich rapide dahin.
Flutter – Vor- und Nachteile
Zusammenfassend kann man sagen, dass Flutter (und auch andere Cross-Platform-Lösungen) vor allem für Apps geeignet sind, welche sich auf UI mit plattformunabhängiger Business-Logik und auch Kommunikation mit irgendeinem Backend beschränken. Hier gewinnt man durch den Einsatz von Flutter am meisten.
Sobald plattformspezifische Funktionalitäten hinzukommen, muss man differenzieren: können diese Funktionalitäten durch bereits existierende, seriöse Packages eingebunden werden, kann sich ein Einsatz von Flutter durchaus immer noch lohnen, man muss jedoch die Abhängigkeit von diesen Packages berücksichtigen.
Sobald Libraries oder auch Funktionalitäten eingebunden werden, für welche es keine existierenden Packages gibt und sich diese zudem noch stark von Plattform zu Plattform unterscheiden, dann kann die zusätzliche Komplexität durchaus auch so stark ansteigen, dass die Vorteile von Flutter zunichte gemacht werden.
Eine weitere Einschränkung kann es geben, wenn bereits existierende UIs in das UI-System von Flutter eingebunden werden sollen. Hier kann der Vorteil von Flutter, dass das UI durch Flutter selber mittels der Graphics Engine Skia selber gezeichnet wird auch zum Nachteil werden: denn bestehende Views müssen von Flutter in das eigene System eingebunden und gezeichnet werden. Dies kann gerade auf älteren Android-Versionen (< Android 10) unter Umständen zu Performance-Einbussen führen.
Einsparungspotential durch den Einsatz von Flutter
Durch die Kenntnisse der zuvor besprochenen Vor- und Nachteile von Flutter lassen sich grobe Abschätzungen treffen, wie gross das Einsparungspotential für die Umsetzung einer App mit Flutter sein kann. Die weiter oben gemachte Einteilung in drei Komplexitätsbereiche lässt sich für die Kostenschätzung nutzen:
Alles in Flutter umsetzbar
Im idealen Fall ist so gut wie die ganze App mit ein paar wenigen Standard-Packages in Flutter umsetzbar. In diesem Szenario rechnen wir mit einer Kosteneinsparung von 20% bis zu 40% gegenüber der Umsetzung von zwei nativen Apps. Die Erwartung mit der Hälfte an Code (nur einmal Flutter-Code anstatt einmal iOS-Code und einmal Android-Code) ist leider illusorisch, denn auch wenn iOS- und Android-Apps aus einer Code-Basis gebuildet werden können, so müssen die Apps auch in die jeweiligen Stores verteilt werden und natürlich zuvor auch separat getestet werden. Ebenfalls muss man beispielsweise die iOS-App testen, wenn bei Android ein Bug gefunden und korrigiert wurde – spätestens wenn ich die iOS-App mit einem anderen Update releasen will.
Einsatz bestehender Packages
Müssen plattformabhängige Features in eine App eingebaut werden, hängt das Einsparungspotential natürlich stark davon ab, ob auf bestehende seriöse Packages zurückgegriffen werden kann oder ob eigene einfache Packages umgesetzt werden. In der Tendenz schrumpft das Einsparungspotential ein wenig, so dass wir im Schnitt von etwa 20% Einsparung ausgehen.
Komplexe Entwicklung von Packages
Fazit
Mit unserer Erfahrung in der Entwicklung von native und Flutter Apps sind wir in der Lage, Kunden spezifisch nach ihren Bedürfnissen bei der Technologiewahl zu beraten. Kosten zu sparen ist durch den Einsatz von Flutter natürlich immer sehr verlockend. Durch eine umfassende Beratung mit Blick in die Zukunft, möchten wir unsere Kunden aber begleiten, damit die Technologiewahl den Weg in die Digitalisierung unterstützt und nicht zum Stolperstein wird.
Gerne können Sie sich bei uns melden wenn Sie Fragen bei Ihrem Projekt haben: Kontaktieren Sie uns!
