
Die göttliche Komödie des alltäglichen Benutzers
Uns wurde ein digitales Paradies versprochen....
Weiterlesen
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?
Genau darüber wird es in unserem Artikel gehen.
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.
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 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.
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 (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.
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.
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.
| Kriterium | Native Entwicklung | Flutter | PWA |
|---|---|---|---|
| Codebasis | Separate für iOS und Android | Eine Codebasis für zwei Plattformen | Einheitliche Codebasis (Web) |
| Zugriff auf Gerätefunktionen | Vollständig | Fast vollständig (abhängig von Plugins) | Eingeschränkt (Browser-APIs) |
| UI/UX-Qualität | Maximal, nativ | Hoch, nahezu nativ | Abhängig von der Umsetzung, aber für die meisten Fälle ausreichend |
| Entwicklungsgeschwindigkeit | Niedrig (3–6 Monate) | Mittel (2–4 Monate) | Hoch (2–6 Wochen) |
| Entwicklungskosten | Am höchsten | Mittel | Am niedrigsten |
| Updates | Über App-Marktplätze, mit Verzögerung | Über App-Marktplätze | Sofort, wie im Web |
| Notwendigkeit der Moderation | Ja (App Store, Google Play) | Ja | Nein |
| Regulatorische Einschränkungen | Hohes Risiko | Gleiche Risiken wie bei nativer Entwicklung | Minimal, 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.

Uns wurde ein digitales Paradies versprochen....
Weiterlesen
Vor vielen Jahren, als Datenschutz in...
Weiterlesen
Logistik-App für die Verwaltung von Fuhrpark,...
Weiterlesen