Blog Background

Drei Ansätze für mobile Apps: Vergleich zwischen PWA, Flutter und nativer Entwicklung

Das erste Smartphone erschien viel früher, als die meisten Menschen denken. Bereits 1994 brachte IBM das IBM Simon auf den Markt – ein Touchscreen-Telefon, das Faxe und E-Mails versenden konnte und mit einem Kalender, einem Adressbuch, Notizen und einem Taschenrechner ausgestattet war.

Dies war der erste konkrete Schritt in Richtung mobiler Anwendungen. Einige Jahre später erschien in Japan der Dienst i-mode von NTT DoCoMo – eine Plattform, über die Inhalte auf Mobiltelefone heruntergeladen werden konnten: Dienste, Spiele, Einkäufe, Informationen. Dies war der erste echte kommerzielle Anstoß für das, was wir heute unter App Store und Google Play verstehen: mobile Inhalte + Zugriff über das Telefon.

Seitdem haben sich mobile Anwendungen von einfachen Dienstprogrammen zu vollwertigen Produkten entwickelt, auf denen Finanzdienstleistungen, medizinische Plattformen, soziale Netzwerke und staatliche Dienste basieren. Aber mit den Möglichkeiten wuchs auch die Komplexität der Auswahl. Denn die Entwicklung einer mobilen Anwendung ist nicht nur eine Frage der Funktionalität, sondern auch eine strategische Entscheidung: Wie soll sie umgesetzt werden, wie viel wird sie kosten, wie schnell kann sie gestartet werden und mit welchen Einschränkungen ist zu rechnen?

Heute wählen Unternehmen meist zwischen drei Ansätzen:

  • Native Entwicklung – für maximale Leistung und Integration mit dem Gerät;
  • Flutter – eine plattformübergreifende Lösung mit einer einzigen Codebasis;
  • PWA – eine flexible Alternative für einen schnellen Start ohne App Store.

Genau darüber wird es in unserem Artikel gehen.

Native Entwicklung: maximale Kontrolle, maximale Kosten

Native Apps werden für jede mobile Plattform separat erstellt:

  • Swift/Objective-C für iOS
  • Kotlin/Java für Android

Dies ist ein Klassiker des Genres, der nach wie vor der Goldstandard ist, wenn maximale Leistung, Zugriff auf alle Funktionen des Geräts und vollständige Kontrolle über die Benutzererfahrung erforderlich sind.

Wann ist das gerechtfertigt?

  • Wenn die App aktiv die Funktionen des Smartphones nutzt: Kamera, Bluetooth, Bewegungssensoren, Biometrie usw.
  • Wenn Sie eine makellose native Benutzererfahrung benötigen: in komplexen Schnittstellen, mit Animationen, nicht standardmäßiger Logik.
  • Wenn die Plattform strenge Sicherheits- oder Zertifizierungsanforderungen hat (z. B. Bankprodukte, medizinische Dienstleistungen).

Vorteile:

  • Maximale Geschwindigkeit und Stabilität, was besonders für produktive Anwendungen wichtig ist.
  • Voller Zugriff auf alle APIs der Plattform.
  • Die beste Unterstützung von Apple/Google – native SDK-orientierte Betriebssystem-Updates, sodass neue Funktionen zuerst in nativen Umgebungen erscheinen.

Nachteile:

  • Doppelte Entwicklung: Es müssen zwei separate Versionen für iOS und Android geschrieben und gepflegt werden.
  • Höhere Kosten: zwei Teams, separate Releases, mehr QA.
  • Längere Aktualisierungszyklen aufgrund von Bürokratie im App Store/Google Play, Überprüfungen, Genehmigungen.

Native Entwicklung lässt sich mit der Anfertigung eines maßgeschneiderten Anzugs vergleichen: teuer, zeitaufwendig, aber perfekt auf die Parameter abgestimmt. Wenn das Produkt eine komplexe Logik, eine enge Integration mit dem Gerät und hohe Qualitätsanforderungen aufweist, ist dies immer noch der zuverlässigste Weg.

Für viele Unternehmen, die schneller auf den Markt kommen, ihre Hypothese überprüfen oder Kosten sparen möchten, kann dieser Ansatz jedoch übertrieben sein.

Flutter: ein Code – zwei Anwendungen

Flutter ist ein Framework von Google, mit dem mobile Anwendungen für iOS und Android mit einer einzigen Codebasis erstellt werden können. Das bedeutet: ein Team, eine Logik und als Ergebnis Anwendungen für iOS und Android, die wie native Anwendungen aussehen.

Diese Lösung ist besonders beliebt bei Start-ups und Produktteams, die schneller starten und Kosten senken möchten, ohne dabei an Qualität der Benutzeroberfläche einzubüßen.

Wann macht es Sinn?

  • Wenn Sie ein MVP starten und gleichzeitig auf zwei Plattformen auf den Markt kommen müssen.
  • Wenn die Anwendung nicht kritisch von den umfangreichen Funktionen des Smartphones abhängig ist.
  • Wenn Sie Releases beschleunigen und Doppelarbeit der Teams vermeiden möchten.

Vorteile:

  • Schnellere Entwicklung im Vergleich zu nativen Anwendungen: ein Team, ein Stack.
  • Bequemer Support und Updates: Änderungen werden sofort für beide Plattformen vorgenommen.
  • Hohe UI-Qualität: Flutter verfügt über ein eigenes Rendering, sodass die Benutzeroberfläche flüssig und modern wirkt, auch wenn sie nicht vollständig dem nativen Stil von iOS oder Android entspricht.
  • Aktive Community und Unterstützung durch Google: ständige Aktualisierung, große Datenbank mit fertigen Lösungen.

Nachteile:

  • Die Größe der Anwendung ist größer als bei nativen Analoga.
  • Nicht immer Zugriff auf spezifische Gerätefunktionen: Für komplexe Hardware-Integrationen sind zusätzliche Wrapper erforderlich.
  • Trotzdem ist eine Veröffentlichung im App Store und bei Google Play mit allen damit verbundenen Einschränkungen erforderlich.

Flutter ist die optimale Wahl für viele moderne Produkte, insbesondere wenn Zeit, Budget und Aufwand gespart werden sollen. Dieser Ansatz wird oft sogar von großen Unternehmen gewählt.

Es ist jedoch wichtig zu bedenken, dass Flutter immer noch nach den Regeln der Plattformen spielt. Und wenn ein Produkt mit Marktplatzbeschränkungen oder regulatorischen Hindernissen konfrontiert ist, hilft selbst das schnellste Flutter nicht, die Moderation zu passieren.

PWA: Start ohne Marktplätze und mit vollständiger Kontrolle

PWA (Progressive Web App) ist eine Webanwendung, die wie eine mobile App aussieht und funktioniert. Sie kann auf dem Startbildschirm eines Smartphones installiert werden und verfügt über Offline-Funktionen. Außerdem unterstützt sie Push-Benachrichtigungen und Caching: All dies über den Browser, ohne dass eine Veröffentlichung im App Store oder bei Google Play erforderlich ist.

Dieser Ansatz ermöglicht es, einen mobilen Dienst direkt zu starten, ohne Moderation, Überprüfungen und technische Einschränkungen seitens der Plattformen.

Wann macht das Sinn?

  • Wenn die Anwendung die Moderation nicht besteht (aufgrund von Altersbeschränkungen, Themen oder lokalen Vorschriften).
  • Wenn Sie so schnell wie möglich auf den Markt kommen möchten, ohne Verzögerungen bei der Veröffentlichung.
  • Wenn die mobile Erfahrung eine Erweiterung des bestehenden Webprodukts ist, macht es keinen Sinn, eine separate native Architektur aufzubauen.
  • Wenn Flexibilität und schnelle Updates wichtig sind.

Vorteile:

  • Keine Genehmigung durch den App Store oder Google Play erforderlich.
  • Schnellerer Start und Bereitstellung ohne Überprüfung und technische Bürokratie.
  • Geringere Entwicklungskosten: ein Team, eine Codebasis.
  • Updates erfolgen automatisch, ohne dass der Benutzer eingreifen muss.

Nachteile:

  • Push-Benachrichtigungen werden unterstützt, jedoch mit Einschränkungen unter iOS: Sie funktionieren nur über Safari, sofern die PWA auf dem Startbildschirm installiert und zugelassen sind.
  • Es besteht kein vollständiger Zugriff auf alle Funktionen des Geräts.
  • Nicht alle Nutzer wissen, wie man eine PWA installiert – es bedarf einer gut durchdachten Anleitung oder eines UX-Onboardings.
  • Keine Präsenz auf Marktplätzen, kein organischer Traffic aus dem App Store.

PWA sollte nicht als vereinfachte Version einer Anwendung betrachtet werden. Es handelt sich um eine parallele Strategie für den mobilen Zugriff, die optimal ist, wenn regulatorische Hindernisse bestehen, eine schnelle Einführung erforderlich ist oder ein Webprodukt vorhanden ist, das ohne zusätzliche Kosten erweitert werden kann.

PWA in Aktion: ein Fallbeispiel aus unserer Erfahrung

British American Tobacco (BAT) – eines der größten multinationalen Unternehmen der Welt, das sich auf die Herstellung nikotinhaltiger Produkte spezialisiert hat, wandte sich mit der Anfrage an uns, eine mobile Anwendung für die Kategorie 18+ zu entwickeln. Die Anwendung sollte benutzerfreundlich und modern sein und über ein Smartphone zugänglich sein. Mit anderen Worten: Sie sollte alles bieten, was auch jeder andere gewöhnliche mobile Dienst bietet.

Von Anfang an war klar, dass der traditionelle Weg über den App Store und Google Play blockiert war. Aufgrund der Besonderheiten der Gesetzgebung und der Richtlinien der Marktplätze war die Veröffentlichung einer solchen App unmöglich.

Die einzige realistische Lösung war eine PWA, die keine Genehmigung durch die Marktplätze erforderte, es den Nutzern ermöglichte, ein Symbol auf dem Startbildschirm hinzuzufügen, die gewünschten Funktionen direkt über den Browser bereitstellte und die vollständige Kontrolle über Updates ohne zusätzliche Releases und Überprüfungen ermöglichte.

Das Ergebnis: Der Kunde konnte das Produkt innerhalb kurzer Zeit, ohne rechtliche Risiken und mit einer vollwertigen mobilen Schnittstelle auf den Markt bringen. Und vor allem musste er nicht auf die Genehmigung warten, um mit seinem eigenen Publikum zu arbeiten.

Es handelte sich nicht um eine vorübergehende Lösung oder ein MVP: Es war eine bewusste Entscheidung für eine Technologie, die Einschränkungen, Geschwindigkeit und Budget berücksichtigte. PWA vereinfachte nicht nur den Vertrieb, sondern eröffnete auch die Möglichkeit der direkten Skalierung über das Web, ohne geografische Beschränkungen, Überprüfungen oder Plattformzensur. Das Unternehmen erhielt einen mobilen Zugangskanal, der so aussieht und funktioniert, wie es der Nutzer erwartet.

Vergleich: PWA, Flutter und native Entwicklung

KriteriumNative EntwicklungFlutterPWA
CodebasisSeparate für iOS und AndroidEine Codebasis für zwei PlattformenEinheitliche Codebasis (Web)
Zugriff auf GerätefunktionenVollständigFast vollständig (abhängig von Plugins)Eingeschränkt (Browser-APIs)
UI/UX-QualitätMaximal, nativHoch, nahezu nativAbhängig von der Umsetzung, aber für die meisten Fälle ausreichend
EntwicklungsgeschwindigkeitNiedrig (3–6 Monate)Mittel (2–4 Monate)Hoch (2–6 Wochen)
EntwicklungskostenAm höchstenMittelAm niedrigsten
UpdatesÜber App-Marktplätze, mit VerzögerungÜber App-MarktplätzeSofort, wie im Web
Notwendigkeit der ModerationJa (App Store, Google Play)JaNein
Regulatorische EinschränkungenHohes RisikoGleiche Risiken wie bei nativer EntwicklungMinimal, volle Kontrolle über die Distribution
Verbreitung der AppÜber App-MarktplätzeÜber App-MarktplätzeÜber Link, QR-Code oder Website

Fazit:
Es gibt kein universelles Rezept dafür, welcher App-Typ besser funktioniert, da jeder Ansatz seine eigenen Vorteile, Einschränkungen und Anwendungsbereiche hat. In manchen Fällen spielen Leistung und vollständige Geräteintegration die entscheidende Rolle. In anderen Fällen sind Geschwindigkeit beim Markteintritt, Umgehung von Prüfverfahren oder Budgeteinsparungen wichtiger.

Wir bei Iwis bevorzugen keine bestimmte Lösung, sondern wählen das Format entsprechend den Zielen, Anforderungen und dem Kontext jedes einzelnen Kunden. Letztlich ist die App eine Brücke zwischen dem Service und seinen Nutzern – unser Ziel ist es, diese Brücke so direkt und benutzerfreundlich wie möglich zu gestalten.

Nächster Beitrag