Wann lohnt sich eine Cross-Compiled-Entwicklung mit Flutter?

Wie liefert man seinen Kunden möglichst schnell und kostensparend ein qualitativ hochwertiges Produkt, das möglichst viele potenzielle Nutzer erreicht? Diese Frage stellen sich Mobile-Entwickler:innen allerorten und haben hierbei die Qual der Wahl. Neben der klassischen nativen Anwendungsentwicklung haben sich aus dieser Fragestellung heraus in den letzten Jahren zahlreiche alternative Entwicklungsansätze, sogenannte Cross-Plattform Frameworks, am Markt etabliert, die mit möglichst wenig Mehraufwand gleich mehrere Betriebssysteme abdecken.

Neben hybriden und Interpreted-Ansätzen, erfreuen sich vor allem Cross-Compiled Frameworks wie React Native oder Flutter großer Beliebtheit. Aber was ist eigentlich ein Cross-Compiled Framework? Und wann lohnt sich eine Entwicklung damit?

Überblick über Entwicklungsansätze

Nativer Ansatz: Beim nativen Ansatz werden die plattformspezifischen Tools und Programmiersprache(n) verwendet. Der Vorteil hiervon ist vor allem der volle und direkte Zugriff auf alle Hardware-Funktionalitäten und UI-Elemente. Dadurch bleibt die Performance, verglichen mit alternativen Entwicklungsansätzen, ungeschlagen. Der größte Nachteil bei nativer Entwicklung ist der deutliche Mehraufwand, da jede Plattform mit einer eigenen Anwendung bedient werden muss.

So hat man nahezu den doppelten Entwicklungsaufwand, wenn man nur die beiden populärsten Betriebssysteme Android und iOS in sein Projekt einbezieht. Auch unterscheiden sich die Anwendungen für verschiedene Plattformen hier in ihrer Entwicklungsweise, wodurch für die jeweilige Plattform eigene Mitarbeiter nötig werden, zumindest aber entsprechendes Know-how aufzubauen ist. Auch etwaige Wartungsarbeiten werden so schnell zu einem Zeitfresser.

Cross-Compiled-Ansatz: Beim Cross-Compiled-Ansatz schreibt der Entwickler oder die Entwicklerin in der Regel eine Codebasis in einer einzigen Sprache, beispielsweise in Dart für das Framework Flutter. Dieser Code wird im nächsten Schritt in nativen Code der jeweils gewünschten Plattform übersetzt. Die Vorteile dieses Ansatzes sind, dass Entwicklerinnen und Entwickler nicht mehrere Plattform-spezifische Eigenheiten im Detail kennen müssen, sich die Code-Menge im Vergleich zum nativen Ansatz deutlich in Grenzen hält und es trotzdem möglich ist, einen Großteil der Hardwarefunktionen anzusprechen.

Ebenso wie die Code-Menge halten sich auch die Nachteile stark in Grenzen: Möglicherweise muss man für bestimmte Features noch nativen Code hinzufügen. Außerdem ist es bis dato noch nicht möglich, wirklich alle Features zu nutzen, die die Betriebssysteme für ihre nativen Anwendungen zur Verfügung stellen. Doch auch an dieser Baustelle arbeiten die Entwickler der Frameworks und liefern regelmäßig Schnittstellen dieser Features nach.

Hinzu kommt, dass sich je nach Framework die Performance kaum noch von nativen Anwendungen unterscheidet.

Andere Entwicklungsansätze:

• Der Web-Ansatz ist im Grunde nichts weiter als eine für mobile Endgeräte optimierte Website.
• Der hybride Ansatz verbindet Elemente des nativen und des Web-Ansatz’. Er basiert, genau wie der Web-Ansatz, auf gängigen Web-Technologien wie HTML, CSS und PHP. Allerdings wird der Web-basierte Code in einen sogenannten nativen Container, um Zugriff auf Hardware-Funktionen zu erhalten.
• Beim Interpreted-Ansatz wird der Code in der Regel in gängigen Programmiersprachen wie JavaScript geschrieben. Doch im Vergleich zum Cross-Compiled-Ansatz wird der Code nicht in die jeweilige Sprache der Zielplattform übersetzt. Stattdessen erfolgen Zugriffe der Anwendung über eine abstrakte Schicht der nativen API des Endgeräts, die den dafür genutzten Code teilweise erst zur Laufzeit interpretiert.

Warum Cross-Compiled eine gute Alternative zum nativen Ansatz ist

Bei den im vorherigen Abschnitt beschriebenen Entwicklungsansätzen muss man häufig an der einen oder anderen Stelle Abstriche machen. Für Web-Apps ist beispielsweise in der Regel eine Internetverbindung erforderlich. Zudem schwächeln sie in Puncto Performance und der Menge an nutzbaren Hardware-Funktionalitäten. Doch auch komplexere Entwicklungsansätze wie der Hybrid-Ansatz können nicht mit ihrer Performance überzeugen. Zudem ist hier vor allem der Ressourcenverbrauch von Batterie und Arbeitsspeicher hoch. Zwar sieht es bzgl. des Ressourcenverbrauchs beim Interpreted-Ansatz besser aus, aber auch dieser kommt durch die abstrakte Schicht zwischen Anwendung und Geräte-API weder an die Performance noch an den geringen Ressourcenverbrauch von nativen oder Cross-Compiled-Anwendungen ran. Obwohl durchaus geeignete Anwendungsfälle für die genannten Entwicklungsansätze existieren, scheint für den Großteil der App-Vorhaben aktuell lediglich der Cross-Compiled-Ansatz eine wirkliche Alternative zum nativen Ansatz darzustellen.

Flutter

Flutter ist ein von Google entwickeltes Open Source Framework, das entweder als eigenständiges Projekt native Anwendungen als Ergebnis liefert oder aber in bestehende native Anwendungen integriert wird. Flutter-Anwendungen werden in der objektorientierten Programmiersprache Dart geschrieben. Es ist jedoch möglich, nativen Code für bestimmte Funktionalitäten zu integrieren.

Im Gegensatz zu anderen Entwicklungsansätzen ist Flutter weder abhängig von einem Web-Browser noch von den nativen Widgets des jeweiligen Betriebssystems. Denn Flutter zeichnet die Widgets mit einer eigenen Render Engine in den Stilen von Material Design (Android) und Cupertino (iOS).

Zudem sind die meisten Hardware-Funktionalitäten in Dart implementiert. Das Kernkonzept von Flutter sind die bereits erwähnten Widgets. Jedes UI-Element in Flutter basiert auf einer Zusammenstellung dieser Widgets. Außerdem ist es möglich, eigene Widgets zu erstellen. Flutter trennt nicht zwischen Logik und Layout wie beispielsweise Android. Hier wird die Logik in Java- bzw. Kotlin-Dateien geschrieben und das Layout in XML-Dateien definiert. In Flutter wird alles in den Widgets selbst implementiert.

Ein weiteres Alleinstellungsmerkmal von Flutter ist die vereinfachte Entwicklung im Debug-Modus: Dort werden die Anwendungen mit einem Just-in-Time-Compiler kompiliert und in der Dart-VM ausgeführt. Dadurch ist der sogenannte „Hot-Reload“ möglich.  Aktualisierte Daten werden in die Dart-VM eingespeist und Änderungen OnDemand angezeigt – ohne dass man die Anwendung erneut kompilieren muss und ohne dass man erneut zur gewünschten Stelle der Anwendung navigieren muss.

Wann lohnt sich die Entwicklung mit Flutter?

In vielen Fällen lohnt sich die Entwicklung mit Flutter. Dennoch sollte man das Framework trotz der vielen Vorteile nicht als pauschale Antwort für jeden Anwendungsfall betrachten. Wir beleuchten drei Anwendungsfälle, um aufzuzeigen, wann der Einsatz von Flutter Aufwand und Kosten minimiert und in welchen Fällen eine native Entwicklung unumgänglich ist:

1. Informations-Anwendung

   Rahmenbedingungen: In diesem Szenario möchte ein Unternehmen eine Anwendung entwickeln, in der lediglich Informationen abgerufen werden können. Diese beinhalten statische Informationen, wie zum Beispiel die Geschichte des Unternehmens sowie dynamische Informationen, wie zum Beispiel die Ankündigung von bevorstehenden Veranstaltungen.

   Betrachtung: Für Anwendungen dieser Art müssen keine komplexeren Hardware-Funktionalitäten des Betriebssystems angesprochen werden. Daher sind Alternativen zur nativen Entwicklung nicht generell auszuschließen.  Die Performance zwischen nativer und Cross-Compiled-Anwendungen macht bei Features dieser Art keinen Unterschied.

   Da keine Funktionalitäten nativ nachgebessert werden müssen, erhöht sich in diesem Fall der Mehraufwand für die Entwicklung mit Flutter für mehrere Plattformen höchstens minimal. Für diesen Fall empfiehlt sich eine Entwicklung mit Flutter.

2. Online-Shop

   Rahmenbedingungen: In diesem Szenario will ein Unternehmen seinen bestehenden Online-Shop auch als mobile Anwendung anbieten. Dafür sind unter anderem eine Login-Funktion sowie einfache Such-Funktionen nach Waren und das Hinzufügen dieser Waren in den Warenkorb nötig. Da über die Anwendung auch die Käufe abgewickelt werden sollen, gibt es in diesem Szenario auch einen höheren Anspruch an Möglichkeiten der Verschlüsselung und Sicherheit.

   Betrachtung: Gängige Kommunikationsmethoden mit Backends, die für Warenwirtschaftssysteme dieser Art gebraucht werden, sind kein Problem für Cross-Compiled-Anwendungen. Dart ist eine breit gefächerte Sprache, mit der auch Backend-Kommunikation problemlos möglich ist. Cross-Compiled-Apps haben etwa das gleiche Sicherheitslevel wie native Apps, da die Endprodukte ebenfalls native Anwendungen sind. Selbstverständlich soll der Web-Shop in der App optisch dem bereits bestehenden in nichts nachstehen. Da trifft es sich gut, dass Flutter in den Bereichen Design und UI-Komponenten nahezu native Ergebnisse erzielt. Insgesamt eignet sich Flutter auch für mittelgroßen Vorhaben. Der Mehraufwand für die Entwicklung für eine weitere Plattform wäre auch hier minimal, im Zweifelsfall etwas mehr als beim ersten Beispiel (Kaufabwicklung etc.), jedoch immer noch im absolut lohnenden Bereich.

3. Social Media App

   Rahmenbedingungen: In diesem Szenario will ein Start-up eine neue Social-Media-Plattform für mobile Endgeräte entwickeln. Um mit den Big Playern in der Branche mithalten zu können, ist das Budget entsprechend hoch angesetzt. Dafür liegt bei der Anwendung der Fokus vor allem auf der Optik, dem betriebsystemspezifischen Verhalten der Anwendung und der Performance. Gleichzeitig soll es eine Reihe von Features geben, die zum Teil auf Hardware-Funktionen des Endgerätes zugreifen. Die App soll Fotos aufnehmen und Standorte übermitteln; außerdem soll sie einen eigenen Messenger enthalten.

   Betrachtung: Bei diesen Rahmenbedingungen kommen sowohl der native als auch der Cross-Compiled-Ansatz infrage. Wenn das Budget kaum eine Rolle spielt, ist die sicherste Variante, für jede Plattform eine native App zu entwickeln. Denn auf diese Art nutzt die Anwendung alle Hardware-Funktionen des Gerätes ohne Umwege. Native Besonderheiten des User Interfaces und auch andere Funktionalitäten wie Navigation sind jederzeit garantiert. Bei nativen Anwendungen ist die Performance im Vergleich zu Flutter-Anwendungen leicht verbessert. Nichtsdestotrotz wäre es auch möglich, eine Anwendung dieser Größenordnung mit Flutter zu entwickeln. Zwar müsste der Auftraggeber an der einen oder anderen Stelle minimale Abweichungen von nativ entwickelten Anwendungen hinnehmen, jedoch müsste er auf kein Feature verzichten.

   Ein in der Praxis sehr relevantes Argument, welches die meisten Unternehmen auch in einem solchen Szenario zu einer Entwicklung mit einem Cross Compiled Framework führen würde, wären die Kosten. Die Einsparungen mit einem Framework wie Flutter wären bei einem Projekt in dieser Größenordnung immens.

   Zudem wäre es für Randbereiche von Hardware-Funktionalitäten oder andere mögliche native Eigenheiten, bei denen Flutter möglicherweise an seine Grenzen stoßen würde, problemlos möglich, den Flutter-Code mit nativem Code zu vermischen.

Fazit

Über die letzten Jahre hinweg hat sich Flutter zu einer Alternative entwickelt, die man bei App-Vorhaben jeder Größe auf dem Schirm haben sollte:

Ein Großteil der Hardware-Features der Endgeräte können benutzt werden, ohne dabei Abstriche in Puncto Performance zu machen. Tatsächlich ist sie in den meisten Anwendungsfällen nicht von der Performance rein nativ entwickelter Anwendungen zu unterscheiden.

 Trotz minimaler zeitlicher Verzögerung bei der Zurverfügungstellung neuester Features, die oft mit überschaubarem Aufwand selber implementiert werden können, überzeugen Flutter-Anwendungen vor allem durch ihre deutlich geringere Komplexität und die damit verbundene Kosteneinsparung, die sich sowohl in der Entwicklung als auch bei der Wartung und Erweiterung der App zeigt.

Wir empfehlen inzwischen, sofern mit den geplanten Features vereinbar, bei den meisten Vorhaben eine Entwicklung mit Flutter. Unser Team kennt die positiven und negativen Eigenheiten des Frameworks und bessert bei Bedarf mit kreativen Workarounds nach, um auch spezielle Feature-Wünsche kostensparend möglich zu machen. Beispielsweise haben wir im Zuge eines Kundenprojektes ein Package weiterentwickelt, um es unseren Bedürfnissen anzupassen. Nähere Infos dazu gibt es im Blog-Post von Tobias.

Wir werden auch in Zukunft aktiv an der Open-Source-Community mitwirken und neue Packages zur Verfügung stellen, sodass Flutter für viele weitere Anwendungsfälle interessant wird.