<\/span><\/h2>\n\n\n\nBeginnen wir damit, mit einem verbreiteten Missverst\u00e4ndnis aufzur\u00e4umen. In den K\u00f6pfen vieler Unternehmer muss ein “ordentliches digitales Produkt” ein Symbol auf dem Handybildschirm haben, am besten im App Store und bei Google Play. Und diese \u00dcberzeugung kann teuer werden. Eine native Anwendung f\u00fcr iOS und Android bedeutet zwei getrennte Codebasen, zwei Ver\u00f6ffentlichungsprozesse, zwei Testreihen und ein Backend, das Sie ohnehin separat bauen m\u00fcssen. Noch bevor Sie den ersten Nutzer erreichen, tragen Sie die dreifachen Kosten.<\/p>\n\n\n\n
Die Wahl zwischen einer Web-Anwendung und einer mobilen Anwendung ist eine architektonische, keine \u00e4sthetische Entscheidung. Es geht nicht darum, “was in der Pr\u00e4sentation f\u00fcr die Gesch\u00e4ftsf\u00fchrung sch\u00f6ner aussieht”, sondern darum, wo Ihre Nutzer wirklich leben, welche Daten Sie verarbeiten, wie oft Sie \u00c4nderungen ausliefern und wie viele Menschen das Produkt nach dem Start betreuen. Die Architektur ist das Fundament, auf dem in den kommenden Jahren Weiterentwicklung, Sicherheit und Skalierbarkeit ruhen. Ein Fehler in dieser Phase kostet keine paar hundert Z\u0142oty. Er kostet Monate an Arbeit und Zehntausende Z\u0142oty an technischen Schulden.<\/p>\n\n\n\n
Ein typischer Fehler, den wir in der Praxis sehen, sieht so aus: Ein B2B-Unternehmen bestellt eine mobile Anwendung f\u00fcr seine Au\u00dfendienstmitarbeiter oder f\u00fcr ein internes Team, und nach der Einf\u00fchrung stellt sich heraus, dass die Mitarbeiter sie ohnehin vor allem am Computer nutzen. Denn die Dateneingabe auf einem Handybildschirm ist langsam und m\u00fchsam. Bezahlt wurde f\u00fcr native Mobilit\u00e4t, die niemand tats\u00e4chlich nutzt. Auf der anderen Seite treffen wir Start-ups, die sofort die App-Stores erobern wollen, obwohl ihre Gesch\u00e4ftshypothese noch an keinem einzigen Nutzer gepr\u00fcft wurde.<\/p>\n\n\n\n
In diesem Artikel finden Sie keinen neutralen, enzyklop\u00e4dischen Vergleich “Web gegen Mobile”. Wir zeigen Ihnen etwas Praktischeres: 7 konkrete Signale<\/strong>, die in unserer Projektarbeit meist bedeuten, dass ein digitales Produkt keine native Handy-App braucht, sondern eine gut entworfene Web-Anwendung oder PWA. Es sind Signale, die aus realen Problemen stammen: Kosten, Integration, Sicherheit und Wartung. Nicht aus der Theorie.<\/p>\n\n\n\nJedes dieser Signale betrachten wir aus der Perspektive des Dienstleisters, der diese Anwendung sp\u00e4ter weiterentwickeln und betreuen muss. Denn es ist leicht, einem Kunden zu verkaufen, was er m\u00f6chte. Schwieriger, aber ehrlicher ist es, ihm das zu empfehlen, was er wirklich braucht. Wenn Sie Ihr Produkt in mehreren der folgenden Punkte wiedererkennen, sind Ihr Geld und die Zeit Ihres Teams wahrscheinlich in einer soliden Webl\u00f6sung besser angelegt. Und wenn nicht, erfahren Sie, wann eine mobile Anwendung tats\u00e4chlich Sinn ergibt. Betrachten Sie die folgenden Abschnitte als Checkliste f\u00fcr eine bewusste Entscheidung, bevor Sie die erste Rechnung f\u00fcr die Entwicklung unterschreiben.<\/p>\n\n\n\n
<\/span>Signal 1: Ihre Nutzer arbeiten am Schreibtisch, nicht unterwegs<\/span><\/h2>\n\n\n\nDie erste Frage, die wir jedem Kunden stellen, lautet: Wo und wie nutzt Ihr Nutzer das Produkt physisch? Die Antwort sagt mehr als zehn Seiten Spezifikation. Wenn das typische Szenario eine Person ist, die am Schreibtisch sitzt, mit gro\u00dfem Monitor, Tastatur, Maus und einem Dutzend gleichzeitig ge\u00f6ffneter Browser-Tabs, dann sprechen wir von einem station\u00e4ren Kontext. Und ein station\u00e4rer Kontext spricht fast immer f\u00fcr eine Web-Anwendung.<\/p>\n\n\n\n
Denken Sie an die tats\u00e4chliche Arbeit in solchen L\u00f6sungen: das Verwaltungspanel eines Shops, ein CRM-System, in dem ein Vertriebler Gespr\u00e4chsnotizen erfasst, ein Werkzeug f\u00fcr die Projektsteuerung, ein ERP-System, ein Panel f\u00fcr die Auftragsabwicklung oder eine interne Buchhaltungsanwendung. In all diesen F\u00e4llen braucht der Nutzer Platz auf dem Bildschirm, schnelles Wechseln zwischen Ansichten, das Kopieren von Daten zwischen Modulen und das bequeme Eingeben l\u00e4ngerer Texte. Ein Handy ist hier weniger eine Einschr\u00e4nkung als ein echtes Hindernis f\u00fcr die Produktivit\u00e4t.<\/p>\n\n\n\n
Eine mobile Anwendung ergibt Sinn, wenn das Produkt den sogenannten mobilen Kontext nutzt: pr\u00e4zise GPS-Ortung, Kamera, Beschleunigungssensor, Push-Benachrichtigungen, die den Nutzer im Laufe des Tages erreichen, Arbeit im Au\u00dfeneinsatz ohne Zugang zu einem Computer. Ein Kurier, der Pakete scannt, ein Fahrer in einer Fahrdienst-App, ein Fitnesstrainer, eine App f\u00fcr kontaktloses Bezahlen: Das sind nat\u00fcrliche mobile Szenarien. Doch wenn Ihr Produkt weder Kamera noch Ortung braucht und Benachrichtigungen problemlos per E-Mail oder Browser laufen, wird der mobile Kontext hier schlicht nicht ben\u00f6tigt.<\/p>\n\n\n\n
Am wichtigsten ist jedoch die wirtschaftliche Rechnung. Die Kosten f\u00fcr Bau und Betrieb einer nativen mobilen Anwendung rentieren sich nicht, wenn der Nutzer ohnehin station\u00e4r arbeitet. Sie zahlen f\u00fcr den Zugang zu Handyfunktionen, die niemand nutzt, und f\u00fcr die Pr\u00e4senz in Stores, in die Ihre Zielgruppe gar nicht hineinschaut, weil sie sich morgens am B\u00fcrorechner anmeldet. Eine Ausgabe ohne Rendite.<\/p>\n\n\n\n
Im B2B-Segment ist das besonders deutlich zu sehen. Entscheider sagen oft “wir wollen eine App” und meinen damit einfach “wir wollen ein modernes Werkzeug”. Modern ist aber nicht das Symbol auf dem Handy-Startbildschirm, sondern eine responsive, schnelle Weboberfl\u00e4che, die nach der Anmeldung von jedem Ger\u00e4t aus verf\u00fcgbar ist. Eine gut entworfene Web-Anwendung \u00f6ffnet sich auf dem Desktop im B\u00fcro, auf dem Tablet im Besprechungsraum und im Notfall auf dem Handy unterwegs. Ohne dass Sie drei getrennte Produkte bauen m\u00fcssen.<\/p>\n\n\n\n
Tipp:<\/strong> Bevor Sie sich f\u00fcr eine Plattform entscheiden, machen Sie ein einfaches Experiment. Bitten Sie 5 Zielnutzer, eine Woche lang zu notieren, auf welchem Ger\u00e4t und in welcher Situation sie Ihr Werkzeug am h\u00e4ufigsten nutzen w\u00fcrden. Wenn die deutliche Mehrheit “Computer, am Schreibtisch, w\u00e4hrend der Arbeitszeit” angibt, haben Sie ein erstes starkes Signal, dass eine Handy-App ein \u00fcberfl\u00fcssiger Kostenpunkt ist und das Budget besser in die Ausarbeitung der Webversion und ihrer Integration mit den \u00fcbrigen Systemen des Unternehmens flie\u00dft.<\/p>\n\n\n\n<\/span>Signal 2: Sie brauchen schnelle Releases und eine Version f\u00fcr alle<\/span><\/h2>\n\n\n\nDas zweite Signal betrifft das Tempo, in dem Sie \u00c4nderungen einf\u00fchren wollen. Bei uns ist das oft der entscheidende Faktor, weil es sich direkt auf die Beweglichkeit des Gesch\u00e4fts auswirkt. Eine Web-Anwendung gibt Ihnen etwas, das eine native mobile App nie bieten wird: die volle Kontrolle \u00fcber den Zeitpunkt der Auslieferung. Sie spielen eine neue Version auf den Server, und in derselben Sekunde arbeiten alle Nutzer mit dem aktuellen Code. Ohne Warten, ohne Zwischeninstanzen, ohne Warteschlangen.<\/p>\n\n\n\n
In der Welt der mobilen Anwendungen durchl\u00e4uft jede Aktualisierung einen Freigabeprozess im App Store und bei Google Play. Eine Pr\u00fcfung durch Apple kann von einigen Stunden bis zu einigen Tagen dauern, und bei einer Ablehnung beginnt der ganze Zyklus von vorn. Sie entdecken am Freitagabend einen kritischen Fehler? Im mobilen Modell erreicht die Korrektur die Nutzer vielleicht erst n\u00e4chste Woche. Im Web-Modell spielen Sie den Patch sofort aus. F\u00fcr ein Produkt, das sich schnell ver\u00e4ndert, ist dieser Unterschied grundlegend.<\/p>\n\n\n\n
Dazu kommt die Frage der Anzahl der Codebasen. Ein vollwertiger nativer Ansatz bedeutet, drei getrennte Welten zu pflegen: die iOS-Anwendung, die Android-Anwendung und das Backend, das beide bedient. Jede neue Funktion muss dreifach umgesetzt, getestet und ausgeliefert werden. Eine Web-Anwendung bedeutet eine Codebasis im Frontend und ein Backend. Weniger Code hei\u00dft weniger Stellen, an denen ein Fehler auftreten kann, weniger Tests und deutlich niedrigere Entwicklungskosten im Zeitverlauf.<\/p>\n\n\n\n
Es lohnt sich, diese Vorteile an einer Stelle zu sammeln, denn im Eifer der Funktionsplanung \u00fcbersieht man sie leicht:<\/p>\n\n\n\n
\n- Sofortige Releases<\/strong> – eine \u00c4nderung erreicht alle Nutzer im Moment der Ver\u00f6ffentlichung auf dem Server, ohne Pr\u00fcfprozess der Stores.<\/li>\n
- Eine Codebasis<\/strong> – statt getrennter Teams f\u00fcr iOS, Android und Backend pflegen Sie ein einheitliches Frontend-Projekt.<\/li>\n
- Keine Installation<\/strong> – der Nutzer \u00f6ffnet einen Link im Browser und arbeitet sofort, was die Einstiegsh\u00fcrde nahezu auf null senkt.<\/li>\n
- Einheitliche Versionen<\/strong> – es gibt kein Problem mit Nutzern, die monatelang mit einer veralteten, nicht aktualisierten Version arbeiten.<\/li>\n
- Geringere technische Schulden<\/strong> – weniger Plattformen bedeuten weniger Abh\u00e4ngigkeiten zum Aktualisieren und weniger Risiko, dass sie auseinanderlaufen.<\/li>\n<\/ul>\n\n\n\n
Der Wegfall der Installation verdient besondere Aufmerksamkeit. Bei einer mobilen Anwendung steht zwischen Ihrem Produkt und dem Nutzer ein ganzer Weg: im Store finden, herunterladen, Berechtigungen erteilen, ein Konto anlegen. Jeder dieser Schritte ist ein Punkt, an dem ein Teil der Zielgruppe abspringt. Eine Web-Anwendung funktioniert sofort nach dem Klick auf einen Link, was besonders bei der Gewinnung neuer Kunden und beim Testen des Produkts enorm wichtig ist.<\/p>\n\n\n\n
Niedrigere Wartungskosten und geringere technische Schulden im Zeitverlauf sind keine Brosch\u00fcrenfloskeln, sondern echte Einsparungen. Je weniger Plattformen Sie synchron halten m\u00fcssen, desto langsamer w\u00e4chst die Komplexit\u00e4t des Systems und desto l\u00e4nger kann sich Ihr Team auf die Weiterentwicklung konzentrieren statt auf das L\u00f6schen von Br\u00e4nden, die aus den Unterschieden zwischen iOS und Android entstehen. F\u00fcr die meisten Gesch\u00e4ftsprodukte ist diese Berechenbarkeit mehr wert als native Animationen.<\/p>\n\n\n\n
<\/span>Signal 3: Das Herz des Produkts sind Daten, Integrationen und Gesch\u00e4ftslogik<\/span><\/h2>\n\n\n\nDas dritte Signal erkennen wir, sobald wir dar\u00fcber sprechen, worin der eigentliche Wert des Produkts liegt. Wenn sich zeigt, dass es nicht um eine effektvolle Oberfl\u00e4che geht, sondern um Daten, ihre Verarbeitung, die Verbindung mit anderen Systemen und um Gesch\u00e4ftsregeln, dann bauen Sie im Grunde ein Informationssystem. Und Informationssysteme f\u00fchlen sich in einer Web-Architektur am wohlsten, in der die gesamte Logik auf dem Server lebt, nahe an den Daten und Integrationen.<\/p>\n\n\n\n
In B2B-Projekten entsteht fast immer der Bedarf, andere Systeme anzubinden. In der Praxis ist das eine ganze Liste typischer Integrationen, die wir t\u00e4glich umsetzen:<\/p>\n\n\n\n
\n- REST API und Webhooks<\/strong> – Datenaustausch mit externen Diensten in Echtzeit.<\/li>\n
- ERP-Systeme<\/strong> – Synchronisation von Lagerbest\u00e4nden, Bestellungen und Buchhaltungsbelegen.<\/li>\n
- CRM-Systeme<\/strong> – Informationsfluss zu Kunden, Leads und Kontakthistorie.<\/li>\n
- Zahlungs-Gateways<\/strong> – Abwicklung von Transaktionen, Abonnements und Abrechnungen.<\/li>\n
- Data Warehouses und BI-Werkzeuge<\/strong> – Versorgung von Berichten und Gesch\u00e4ftsanalysen.<\/li>\n<\/ol>\n\n\n\n
Eine Web-Anwendung f\u00fcgt sich in ein solches \u00d6kosystem deutlich leichter ein. Sie arbeitet in derselben Netzwerkschicht wie die \u00fcbrigen Unternehmensdienste und kommuniziert mit ihnen serverseitig, ohne die Beschr\u00e4nkungen durch Handy-Betriebssysteme oder die Richtlinien der App-Stores. Automatisierungen, zyklisch gestartete Aufgaben, Verarbeitung im Hintergrund, Integrationen mit Partnersystemen: All das gelingt nat\u00fcrlicher, wenn die Produktlogik auf dem Server wohnt und nicht \u00fcber die Ger\u00e4te der Nutzer verstreut ist.<\/p>\n\n\n\n
Entscheidend wird hier die richtige interne Architektur. In einem gut entworfenen System trennen wir die Oberfl\u00e4chenschicht klar von der Schicht der Gesch\u00e4ftslogik und von der Datenschicht. Die Logik kapseln wir in Repositories, die als einzige Stelle f\u00fcr das Lesen und Schreiben eines bestimmten Datentyps zust\u00e4ndig sind. Die Oberfl\u00e4che zeigt nur an, was ihr die darunterliegende Schicht liefert, und gibt die vom Nutzer ausgel\u00f6sten Ereignisse nach unten weiter. Diese Trennung macht das System testbar, widerstandsf\u00e4hig gegen \u00c4nderungen und leicht durch nachfolgende Entwickler erweiterbar.<\/p>\n\n\n\n
Fachmaterialien zur Anwendungsarchitektur formulieren dieses Prinzip unmissverst\u00e4ndlich. Wie die Autoren der Architekturdokumentation betonen:<\/p>\n\n\n\n
Das wichtigste Prinzip ist die Trennung der Verantwortlichkeiten: die Aufteilung der Anwendung in Methoden, Klassen, Dateien, Pakete, Module und Schichten mit klar definierten Aufgaben und Grenzen.<\/blockquote>\n\n\n\nEng mit der Trennung der Verantwortlichkeiten verbunden ist die Idee einer einzigen Quelle der Wahrheit. Jeder Datentyp sollte einen Eigent\u00fcmer haben, der ihn als Einziger ver\u00e4ndern darf und der diese Daten dem \u00fcbrigen System bereitstellt. Dadurch geschehen alle \u00c4nderungen eines bestimmten Datentyps an einer Stelle, sind vor versehentlichen Eingriffen von au\u00dfen gesch\u00fctzt und leichter nachzuverfolgen, wenn die Fehlerquelle gefunden werden muss. In einer Web-Anwendung ist diese Quelle der Wahrheit \u00fcblicherweise die Datenbank auf der Serverseite.<\/p>\n\n\n\n
Und genau hier zeigt sich der Vorteil gegen\u00fcber dem verteilten mobilen Ansatz, bei dem der Zustand der Anwendung oft auf vielen Ger\u00e4ten gleichzeitig lebt und m\u00fchsam synchronisiert werden muss. Eine zentrale Quelle der Wahrheit bedeutet konsistente Daten, einfachere Logik und weniger Gelegenheiten f\u00fcr schwer auffindbare Fehler. Wenn Daten und Integrationen das Herz Ihres Produkts sind, gibt Ihnen die Web-Architektur eine Kontrolle dar\u00fcber, die die verteilte mobile Welt ohne enormen Aufwand schlicht nicht bietet.<\/p>\n\n\n\n
<\/span>Signal 4: Skalierbarkeit und Sicherheit wiegen schwerer als Touch-Gesten<\/span><\/h2>\n\n\n\nDas vierte Signal taucht \u00fcberall dort auf, wo ein Produkt sensible Daten verarbeitet oder eine wachsende Zahl von Nutzern bedienen muss. In solchen Projekten entscheiden nicht fl\u00fcssige Animationen oder effektvolle Touch-Gesten \u00fcber den Erfolg, sondern die Frage, wie das System mit Sicherheit, Zugriffskontrolle und Last umgeht. Die Web-Architektur bietet hier Vorteile, die kaum zu \u00fcbersch\u00e4tzen sind.<\/p>\n\n\n\n
Beginnen wir mit der Zugriffskontrolle. In einer Web-Anwendung erfolgt die Verwaltung von Berechtigungen, Rollen und Audits zentral auf der Serverseite. Der Server entscheidet, wer worauf Zugriff hat, und der Server protokolliert, wer wann welche Operation ausgef\u00fchrt hat. An einer Stelle k\u00f6nnen Sie einem ausgeschiedenen Mitarbeiter die Rechte entziehen, die Zugriffsrichtlinie f\u00fcr eine ganze Gruppe \u00e4ndern oder die vollst\u00e4ndige \u00c4nderungshistorie nachvollziehen. In einem Modell, in dem die Logik \u00fcber Ger\u00e4te verteilt ist, ist eine solche zentrale Hoheit \u00fcber den Zugriff deutlich schwerer zu erreichen.<\/p>\n\n\n\n
Der zweite gro\u00dfe Vorteil? Das Schlie\u00dfen von Sicherheitsl\u00fccken. Wenn Sie in einer Web-Anwendung eine L\u00fccke entdecken, spielen Sie die Korrektur auf dem Server aus, und das Problem verschwindet im selben Moment f\u00fcr alle Nutzer. In der mobilen Welt muss die Korrektur durch den Store, und danach warten Sie, bis die Nutzer die App auf ihren Handys aktualisieren. Ein Teil von ihnen tut das wochenlang nicht und l\u00e4sst die T\u00fcr offen. Aus Sicht der Sicherheit ist der Unterschied zwischen einem sofortigen Patch und einer vom Nutzer abh\u00e4ngigen Aktualisierung gewaltig.<\/p>\n\n\n\n
Der dritte Aspekt ist die Skalierbarkeit. Das Backend einer Web-Anwendung entwerfen wir so, dass es horizontal skaliert werden kann, also durch das Hinzuf\u00fcgen weiterer Serverinstanzen, wenn Traffic und Kundenzahl wachsen. Steigt die Zahl der Nutzer, f\u00fcgen Sie Rechenleistung hinzu, und die Architektur verteilt die Last darauf. Dieser Ansatz hat sich in unz\u00e4hligen Produktivsystemen bew\u00e4hrt. Eine gut entworfene Web-Anwendung w\u00e4chst mit Ihrem Gesch\u00e4ft, statt zum Flaschenhals zu werden.<\/p>\n\n\n\n
Der vierte, oft untersch\u00e4tzte Punkt ist die Kontrolle \u00fcber sensible Daten. In einer Web-Architektur speichern Sie Daten zentral, in einer kontrollierten und abgesicherten Serverumgebung. Im mobilen Modell landet ein erheblicher Teil der Daten auf den Ger\u00e4ten der Nutzer, und jedes verlorene oder gestohlene Handy wird zu einem m\u00f6glichen Datenleck. Je sensibler die Daten sind, die Sie verarbeiten, etwa medizinische, finanzielle oder personenbezogene, desto st\u00e4rker spricht das daf\u00fcr, sie an einem gut gesch\u00fctzten Ort zu halten, statt sie \u00fcber Hunderte Ger\u00e4te zu verstreuen.<\/p>\n\n\n\n
Tipp:<\/strong> Erstellen Sie bei der Vorbereitung der Projektannahmen eine einfache Datenkarte. Halten Sie fest, welche Informationen das System speichern wird, welche davon sensibel sind und wer Zugriff darauf haben sollte. Wenn diese Karte schnell um personenbezogene, finanzielle oder vertrauliche Unternehmensdaten w\u00e4chst, ist das ein deutliches Zeichen, dass Sie eine Architektur mit zentraler Zugriffskontrolle und Audit brauchen, also eine Webl\u00f6sung mit starkem Backend und keine Anwendung, die diese Daten \u00fcber die Handys von Mitarbeitern und Kunden verteilt.<\/p>\n\n\n\nAuf einen Satz gebracht: Wenn das Gespr\u00e4ch \u00fcber Ihr Produkt h\u00e4ufiger auf Rollen, Audit, DSGVO-Konformit\u00e4t und Lastfestigkeit kommt als darauf, wie sch\u00f6n sich eine Karte mit dem Finger verschieben l\u00e4sst, dann bauen Sie ein System, dessen nat\u00fcrliches Zuhause eine gut abgesicherte Web-Architektur ist. Sicherheit und Skalierbarkeit sind Fundamente, keine Zus\u00e4tze. Und sie sollten die Entscheidung \u00fcber die Plattform anf\u00fchren.<\/p>\n\n\n\n
<\/span>Signal 5: Sie bauen ein MVP und m\u00fcssen den Markt schnell pr\u00fcfen<\/span><\/h2>\n\n\n\nDas f\u00fcnfte Signal richtet sich vor allem an Gr\u00fcnderinnen und Gr\u00fcnder von Start-ups sowie an Unternehmen, die neue Produktlinien starten. Wenn Ihr Ziel ist, m\u00f6glichst schnell zu pr\u00fcfen, ob die Idee \u00fcberhaupt einen Markt hat, ist eine Web-Anwendung fast immer der richtige erste Schritt. Ein MVP, also ein Produkt mit minimal notwendigem Funktionsumfang, hat eine Aufgabe: die Gesch\u00e4ftshypothese mit m\u00f6glichst geringem Zeit- und Geldaufwand zu pr\u00fcfen. Das Web erf\u00fcllt dieses Ziel besser als jede andere Plattform.<\/p>\n\n\n\n
Der gr\u00f6\u00dfte Vorteil ist das Fehlen einer Einstiegsh\u00fcrde. Die Webversion stellen Sie Testern mit einem einfachen Link zur Verf\u00fcgung. Sie verschicken den Link per E-Mail, f\u00fcgen ihn in eine Nachricht ein, setzen ihn in eine Anzeige, und der Empf\u00e4nger klickt und nutzt das Produkt bereits. Er muss die App nicht im Store suchen, herunterladen, Berechtigungen zustimmen oder ein Konto anlegen, nur um einen Blick darauf zu werfen. Jeder dieser Schritte siebt in der mobilen Welt einen Teil der potenziellen Tester aus, und Ihnen liegt in dieser fr\u00fchen Phase daran, m\u00f6glichst viele Beobachtungen zu sammeln.<\/p>\n\n\n\n
Der zweite Vorteil ist Tempo und Kosten der Iteration. Die Pr\u00fcfung einer Idee ist kein einmaliger Schuss, sondern eine Folge schneller Zyklen: Sie ver\u00f6ffentlichen eine Version, beobachten die Reaktionen, nehmen \u00c4nderungen vor, ver\u00f6ffentlichen erneut. Im Web-Modell dauert ein solcher Zyklus Stunden, weil die neue Version die Nutzer sofort nach der Auslieferung erreicht. Im mobilen Modell bleibt jede Iteration im Ver\u00f6ffentlichungsprozess des Stores stecken. F\u00fcr ein Start-up, das gegen die Zeit und ein schrumpfendes Budget antritt, kann dieser Unterschied \u00fcber das \u00dcberleben entscheiden.<\/p>\n\n\n\n
Der dritte Nutzen ist die einfache Datenerhebung. In einer Web-Anwendung binden Sie problemlos Analysewerkzeuge, Heatmaps, Sitzungsaufzeichnungen und Feedback-Formulare ein. Alles geschieht in einer Umgebung, ohne dass Sie unterschiedliche Messsysteme f\u00fcr iOS und Android zusammenf\u00fchren m\u00fcssen. Sie erhalten ein stimmiges Bild davon, wie sich Nutzer durch das Produkt bewegen, wo sie sich verlieren und was sie anzieht. Diese Daten sind der Treibstoff f\u00fcr Entscheidungen \u00fcber die weitere Entwicklung.<\/p>\n\n\n\n
Hier kommt unsere h\u00e4ufigste Empfehlung f\u00fcr Kunden in der Ideenphase. Tipp: Beginnen Sie mit einer Web-Anwendung oder einer PWA und erg\u00e4nzen Sie eine native mobile App erst dann, wenn die gesammelten Daten das eindeutig rechtfertigen.<\/strong> Mit anderen Worten: Lassen Sie das reale Nutzerverhalten und nicht eine Annahme aus dem Businessplan \u00fcber die Investition in Mobilit\u00e4t entscheiden. Sollte sich zeigen, dass Ihre Zielgruppe das Produkt tats\u00e4chlich im Au\u00dfeneinsatz nutzen w\u00fcrde, die Kamera oder die Ortung braucht, dann ist der Ausbau um eine mobile Schicht eine bewusste, durch Belege gest\u00fctzte Entscheidung.<\/p>\n\n\n\nIn der Praxis stellen viele unserer Kunden nach der Phase des Web-MVP fest, dass sie eine mobile Anwendung \u00fcberhaupt nicht brauchen, weil das Produkt im Browser hervorragend funktioniert. Andere gehen den Schritt zur Mobilit\u00e4t, tun es aber mit vollem Wissen dar\u00fcber, welche Funktionen die Nutzer erwarten. In beiden F\u00e4llen sparen sie Geld, weil sie nicht in eine teure native L\u00f6sung investiert haben, bevor irgendjemand best\u00e4tigt hat, dass sie n\u00f6tig ist. Die vern\u00fcnftige Reihenfolge, erst Web und dann eventuell Mobile, sch\u00fctzt das Budget und ordnet die Produktentwicklung.<\/p>\n\n\n\n
<\/span>Signal 6: Eine PWA deckt Ihren Bedarf an Mobilit\u00e4t ab<\/span><\/h2>\n\n\n\nDas sechste Signal betrifft Zwischensituationen, in denen Sie ein wenig Mobilit\u00e4t brauchen, aber nicht unbedingt eine vollst\u00e4ndige native Anwendung. Die Antwort ist hier oft eine Progressive Web App, kurz PWA. Das ist eine Technologie, die daf\u00fcr sorgt, dass sich eine Web-Anwendung weitgehend wie eine auf dem Handy installierte App verh\u00e4lt und zugleich eine gew\u00f6hnliche, im Browser laufende Seite bleibt. F\u00fcr viele Produkte ist das der goldene Mittelweg zwischen Kosten und M\u00f6glichkeiten.<\/p>\n\n\n\n
Was bietet eine PWA konkret? Der Nutzer kann die Anwendung auf dem Startbildschirm des Handys ablegen und sie \u00fcber ein Symbol starten, genau wie eine native App. Die Anwendung kann offline arbeiten und dabei zuvor gespeicherte Daten nutzen, wenn die Verbindung verschwindet. Sie kann au\u00dferdem Benachrichtigungen senden und den Nutzer so an sich erinnern. All das ohne Ver\u00f6ffentlichung in den Stores, ohne Pr\u00fcfprozess und ohne eine eigene Codebasis f\u00fcr jedes System.<\/p>\n\n\n\n
Die zweite S\u00e4ule ist die Responsivit\u00e4t. Eine gut entworfene Web-Anwendung nutzt adaptive Layouts, die sich an die Bildschirmgr\u00f6\u00dfe anpassen. Dasselbe Produkt sieht auf dem Handy, auf dem Tablet und auf einem gro\u00dfen Monitor sinnvoll aus und funktioniert dort auch. Fachmaterialien zur Anwendungsarchitektur empfehlen ausdr\u00fccklich, Oberfl\u00e4chen so zu bauen, dass sie Konfigurations\u00e4nderungen wie das Drehen des Ger\u00e4ts oder das \u00c4ndern der Fenstergr\u00f6\u00dfe \u00fcberstehen und den Zustand des Nutzers dabei bewahren. Ein responsives Layout ist heute Standard, kein Luxus.<\/p>\n\n\n\n
Man muss aber ehrlich sagen, wo die M\u00f6glichkeiten einer PWA enden. Wenn Ihr Produkt tiefen Zugriff auf native Systemfunktionen ben\u00f6tigt, etwa fortgeschrittene Bildverarbeitung aus der Kamera, l\u00e4ngere Arbeit im Hintergrund, Integration mit den Systemkontakten, Bluetooth Low Energy f\u00fcr spezialisierte Ger\u00e4te oder die h\u00f6chstm\u00f6gliche Grafikleistung in Spielen, dann brauchen Sie tats\u00e4chlich eine native Anwendung. Eine PWA deckt die \u00fcberwiegende Mehrheit typischer mobiler Anforderungen ab, aber nicht alle. Unsere Aufgabe als Dienstleister ist es, ehrlich zu beurteilen, auf welcher Seite dieser Grenze Ihr Produkt liegt.<\/p>\n\n\n\n
F\u00fcr mobile Produkte ist das Thema der Verf\u00fcgbarkeit von Offline-Daten und ihrer Aktualit\u00e4t besonders wichtig. Bei Anwendungen, die im Au\u00dfeneinsatz laufen, ist die Verbindung mitunter unzuverl\u00e4ssig, und der Nutzer sollte nicht vor einem leeren Bildschirm sitzen. Die Architekturdokumentation formuliert dieses Prinzip klar:<\/p>\n\n\n\n
Speichern Sie so viele relevante und aktuelle Daten wie m\u00f6glich. So k\u00f6nnen Nutzer die Funktionen der Anwendung auch dann verwenden, wenn ihr Ger\u00e4t offline ist. Denken Sie daran, dass nicht alle Nutzer eine dauerhafte, schnelle Verbindung haben, und selbst wenn sie sie haben, kann der Empfang an belebten Orten schlecht sein.<\/blockquote>\n\n\n\nDieses Prinzip l\u00e4sst sich in einer PWA wirksam umsetzen. Die Anwendung speichert die ben\u00f6tigten Daten lokal, funktioniert bei schwacher oder fehlender Verbindung und synchronisiert die \u00c4nderungen nach der R\u00fcckkehr des Netzes mit der zentralen Quelle der Wahrheit auf dem Server. F\u00fcr viele Produkte, die Kunden zun\u00e4chst als “unbedingt n\u00f6tige mobile App” sehen, erweist sich die PWA als ausreichende L\u00f6sung, die in Umsetzung und Betrieb deutlich g\u00fcnstiger ist und dabei die wichtigsten Eigenschaften von Mobilit\u00e4t liefert. Bevor Sie sich f\u00fcr volle Nativit\u00e4t entscheiden, pr\u00fcfen Sie, ob eine progressive Web-Anwendung nicht bereits alles abdeckt, was Sie wirklich brauchen.<\/p>\n\n\n\n
<\/span>Signal 7: Ihr Team und Ihr Budget tragen keine zwei getrennten Anwendungen<\/span><\/h2>\n\n\n\nDas siebte Signal ist das bodenst\u00e4ndigste und zugleich das in der Praxis am h\u00e4ufigsten entscheidende: die Ressourcen. Sie m\u00f6gen den Ehrgeiz haben, native Anwendungen f\u00fcr iOS und Android zu bauen, doch die eigentliche Frage lautet, ob Ihr Team und Ihr Budget deren Betrieb \u00fcber die n\u00e4chsten Jahre tragen. Nach unserer Erfahrung ist es gerade die Phase des Betriebs und nicht die der ersten Einf\u00fchrung, die Unternehmen am h\u00e4ufigsten \u00fcberfordert, die sich ohne k\u00fchle Kalkulation f\u00fcr volle Nativit\u00e4t entschieden haben.<\/p>\n\n\n\n
Der Betrieb nativer Anwendungen bedeutet doppelte, oft dreifache Kosten. Jede neue Funktion muss getrennt f\u00fcr iOS und getrennt f\u00fcr Android entstehen, auf beiden Plattformen getestet und mit dem Backend synchronisiert werden. Sie brauchen Entwickler, die unterschiedliche Technologien beherrschen, getrennte Testzyklen und eine getrennte Behandlung von Fehlern, die f\u00fcr das jeweilige System spezifisch sind. Wo eine Web-Anwendung ein Team an einer Codebasis erfordert, vervielfacht das native Modell Arbeitsaufwand und Kosten.<\/p>\n\n\n\n
Mit der Vielzahl an Plattformen verbindet sich das Risiko, dass die Funktionen auseinanderlaufen. Wenn iOS, Android und Backend parallel weiterentwickelt werden, entsteht leicht eine Situation, in der etwas auf einem System anders funktioniert als auf dem anderen, und die Unterschiede wachsen mit der Zeit. Es treten Fehler auf, die es nur auf einer Plattform gibt, Funktionen, die in einer App ausgeliefert und in der anderen vergessen wurden, Abweichungen in der Verarbeitung derselben Daten. Jede solche Unstimmigkeit kostet zus\u00e4tzliche Zeit f\u00fcr Diagnose und Behebung, und f\u00fcr den Nutzer ist es eine frustrierende Erfahrung, die davon abh\u00e4ngt, welches Handy er besitzt.<\/p>\n\n\n\n
Dazu kommen echte, harte Kosten, die allein mit der Pr\u00e4senz in den Stores verbunden sind und die man in der Planungsphase leicht vergisst. Es lohnt sich, sie aufzuschreiben:<\/p>\n\n\n\n
\n- Geb\u00fchren und Entwicklerkonten<\/strong> – j\u00e4hrliche Kosten f\u00fcr die Konten in den App-Stores.<\/li>\n
- Zertifikate und Signaturen<\/strong> – Verwaltung der Zertifikate, Schl\u00fcssel und Profile, die f\u00fcr die Ver\u00f6ffentlichung n\u00f6tig sind.<\/li>\n
- Pr\u00fcfprozess<\/strong> – Zeit und Arbeit f\u00fcr die Freigabe jeder einzelnen Version.<\/li>\n
- Konformit\u00e4t mit den Plattformvorgaben<\/strong> – Anpassung der App an die sich \u00e4ndernden Richtlinien von Apple und Google.<\/li>\n
- Unterst\u00fctzung \u00e4lterer Systemversionen<\/strong> – Tests und Korrekturen f\u00fcr die verschiedenen im Einsatz befindlichen Versionen von iOS und Android.<\/li>\n<\/ul>\n\n\n\n
Diese Kosten verschwinden nach dem Launch nicht. Sie kehren bei jedem Release und bei jeder \u00c4nderung der Store-Richtlinien zur\u00fcck. F\u00fcr ein kleines Team k\u00f6nnen sie mehr Energie verschlingen als die Produktentwicklung selbst. Eine Web-Anwendung beseitigt die meisten davon, weil sie weder den Prozessen der Stores noch deren Zertifizierungsanforderungen unterliegt.<\/p>\n\n\n\n
Der Kern dieses Signals ist ein Grundsatz, den wir unseren Kunden immer wieder nennen: St\u00fctzen Sie die Entscheidung \u00fcber die Plattform auf die realen Ressourcen Ihres Teams und nicht auf technologische Mode. Dass der Wettbewerb eine App im Store hat, hei\u00dft nicht, dass Sie eine brauchen. Wenn Sie wissen, dass das Produkt nach der Einf\u00fchrung von einem kleinen Team oder einem einzelnen externen Partner betreut wird, setzen Sie auf eine Architektur, die Sie realistisch tragen k\u00f6nnen. In den meisten F\u00e4llen ist das eine gut entworfene Web-Anwendung, eventuell um eine PWA erweitert, und nicht ein kostspieliges Paar getrennter nativer Apps, die mit der Zeit zum Klotz am Bein werden.<\/p>\n\n\n\n