Jedes Anwendungsprojekt beginnt mit derselben Frage. Ein Kunde kommt zu unserem Software House und sagt: “Ich brauche eine Anwendung, aber soll sie fürs Handy sein oder reicht eine Website?”. Klingt technisch, oder? Nur auf den ersten Blick. Denn tatsächlich entscheidet diese eine Frage über das Budget der kommenden Jahre, darüber, wie viele Entwickler das Produkt pflegen werden, wie schnell Sie nach einer Nutzermeldung eine Korrektur ausliefern und ob Sie den Termin überhaupt halten. Die Einführung einer PWA im Unternehmen erweist sich immer häufiger als die Antwort, die der Kunde gesucht hat, obwohl er mit der festen Annahme kam, man müsse “eine App für iOS und Android bauen”.
Eine Progressive Web App ist eine Anwendung, die mit Webtechnologien gebaut wird. Sie läuft im Browser, verhält sich aber wie ein auf dem Gerät installiertes Programm. Man kann sie zum Startbildschirm hinzufügen, im Vollbild ohne Adressleiste öffnen, offline nutzen und Benachrichtigungen empfangen. Der Unterschied zu einer nativen App aus dem Store ist grundlegend: Sie laden sie weder aus dem App Store noch aus Google Play herunter, Sie durchlaufen kein Freigabeverfahren, und ein einziger Code bedient Telefon, Tablet und Computer. Eine native Anwendung ist ein eigenes Programm, das für ein bestimmtes System kompiliert wird. Sie hat Zugriff auf den vollen Funktionsumfang der Hardware, zieht aber den gesamten Ballast getrennter Teams, Sprachen und Vertriebswege nach sich.
Dieser Artikel ist weder ein neutraler Marktvergleich noch ein theoretischer Ratgeber vom Typ “10 Vorteile von Webanwendungen”. Wir schreiben ihn als Team von Web Systems, das sich seit 2006 mit professioneller Softwareentwicklung beschäftigt: Wir konzipieren und realisieren Web- und Mobilanwendungen, B2B-Systeme, API-Integrationen und Automatisierungen. Wir zeigen also das, was wir in Projekten tatsächlich sehen: wo Unternehmen Budget verbrennen, welche Fehler sie bei der Beauftragung machen und wann eine PWA einer mobilen App wirklich überlegen ist und wann man dem Kunden besser davon abrät. Wenn Sie eine Umsetzung planen und die Folgen Ihrer Entscheidung verstehen wollen, bevor Sie einen Vertrag unterschreiben, ist das eine Lektüre für Sie.
Spis treści
PWA gegen mobile App: warum diese Wahl über das Projektbudget entscheidet
Stellen Sie sich eine typische Situation vor. Ein Dienstleistungsunternehmen möchte seinen Kunden ein Werkzeug geben, um Termine zu vereinbaren, den Status eines Auftrags einzusehen und den Support zu kontaktieren. Im Kopf hat es “eine App”, denn alle haben Apps, und der Geschäftsführer hat bei der Konkurrenz ein Symbol auf dem Telefon gesehen. Es fragt nach einem Angebot für eine App für iOS und Android. Und hier beginnt unsere Arbeit. Denn unsere Pflicht als Dienstleister ist es, zuerst die Absicht zu verstehen und nicht nur den Auftrag anzunehmen. Fragen wir nach, was diese Anwendung real leisten soll, zeigt sich: Es geht um Formulare, Listen, Statusinformationen und Benachrichtigungen. Also genau um das Szenario, in dem die Einführung einer PWA im Unternehmen denselben geschäftlichen Effekt zu einem Bruchteil der Kosten bringt.
Eine Progressive Web App ist keine “schlechtere Website” und keine “vereinfachte App”. Sie ist eine vollwertige Anwendung, die moderne Mechanismen des Browsers nutzt: Service Worker für den Offlinebetrieb, ein Manifest, mit dem sie sich auf dem Startbildschirm installieren lässt, und eine responsive Oberfläche, die sich an jeden Bildschirm anpasst. Aus Sicht der Nutzer öffnet sie sich wie ein normales Programm, hat ein eigenes Symbol und läuft flüssig. Aus Sicht des Unternehmens liegt der Unterschied woanders – in der Art, wie sie gebaut, verteilt und gepflegt wird. Und genau diese drei Bereiche erzeugen Kosten, die sich über Jahre verteilen.
Eine native mobile Anwendung erfordert eigenen Code für iOS, eigenen für Android und, wenn das Unternehmen im Internet sichtbar sein will, zusätzlich eine Webversion. Das sind drei Codebasen, drei Testprozesse, drei Veröffentlichungswege und oft drei unterschiedliche Kompetenzen im Team. Jede hat ihren eigenen Lebenszyklus, jede braucht Aktualisierungen für neue Betriebssystemversionen und jede erzeugt technische Schulden. Ein Kunde, der “eine App für iOS und Android” bestellt, ist sich selten bewusst, dass er gerade die Pflege von zwei oder drei Produkten parallel beauftragt hat.
Die Wahl zwischen PWA und nativ ist keine Frage der Mode oder des Geschmacks der Entwickler. Es ist eine Entscheidung, die auf die Gesamtkosten des Produkts durchschlägt. Der günstigere Aufbau ist erst der Anfang. Das echte Geld steckt in der Pflege: in den Arbeitsstunden, die Entwickler für Aktualisierungen aufwenden, in der Reaktionszeit auf Fehler, in der Häufigkeit neuer Funktionen. Ein Unternehmen, das eine für seine Bedürfnisse unpassende Architektur wählt, zahlt diesen Unterschied jeden Monat. Und versteht oft nicht einmal, woher er kommt.
Deshalb ist der erste Schritt in unseren Projekten nicht das Schreiben von Code, sondern die Analyse der Absicht. Wir fragen, wer die Anwendung nutzen wird, auf welchen Geräten, wie oft, ob Zugriff auf die Hardware des Telefons nötig ist, ob die Anwendung in der Suchmaschine sichtbar sein soll und wie schnell das Unternehmen iterieren möchte. Erst die Antworten auf diese Fragen erlauben eine seriöse Technologieempfehlung. In den meisten B2B- und Dienstleistungsprojekten, die uns begegnen, lautet die Antwort: Eine PWA deckt den Bedarf, und die Ersparnis geht schon im ersten Jahr in die Zehntausende Złoty.
In den folgenden Abschnitten zerlegen wir diese Vorteile in ihre Bestandteile. Wir zeigen aber ehrlich auch die Grenzen. Denn ein guter Dienstleister verkauft nicht eine Technologie für alles, sondern wählt das Werkzeug passend zum Problem.
Ein Code statt drei: niedrigere Kosten für Aufbau und Pflege
Der greifbarste Vorteil einer PWA zeigt sich schon bei der Kalkulation. Die Umsetzung einer Progressive Web App stützt sich auf eine Codebasis, die ein einziges Frontend-Team betreut. Sie brauchen keinen Swift-Spezialisten für iOS, keinen zweiten für Kotlin auf Android und keinen dritten für die Webversion. Diese Kompetenzen sind teuer und knapp, und sie parallel vorzuhalten vervielfacht die Projektkosten. Indem Sie den Bedarf an drei Teams beseitigen, senken Sie nicht nur die Ausgaben, sondern auch das organisatorische Risiko, mehrere Mannschaften zu koordinieren, die am selben Produkt arbeiten.
Es lohnt sich, zwei Kostenarten zu unterscheiden, die Kunden häufig verwechseln. Die Aufbaukosten sind eine einmalige Ausgabe für die Erstellung der Anwendung. Die Pflegekosten sind eine wiederkehrende, monatliche Last, die über einige Jahre den Aufbau meist übersteigt. Bei nativen Anwendungen sind diese zweiten Kosten heimtückisch. Sie wachsen schrittweise und werden im ursprünglichen Angebot selten ehrlich ausgewiesen.
- Aktualisierungen der Betriebssysteme: Apple und Google veröffentlichen jedes Jahr neue Versionen von iOS und Android, die die Kompatibilität einer Anwendung brechen können. Jede solche Änderung erfordert Entwicklerarbeit, Tests und eine erneute Veröffentlichung, unabhängig davon, ob Sie eine neue Funktion ergänzt haben.
- Doppelte oder dreifache Arbeit bei jeder Korrektur: Einen von Nutzern gemeldeten Fehler muss man auf jeder Plattform getrennt beheben, getrennt testen und getrennt ausliefern. Was in einer PWA eine Korrektur ist, sind bei nativen Apps oft drei.
- Technische Schulden: Drei Codebasen altern unabhängig voneinander, und Bibliotheken sowie Frameworks verlangen Migrationen. Je mehr Code, desto mehr Schulden und desto höher die Kosten ihrer Tilgung.
- Kosten für Entwicklerkonten und Zertifikate: Jahresgebühren, die Verwaltung von Signaturschlüsseln und die Erneuerung von Zertifikaten sind kleine, aber wiederkehrende Verwaltungslasten.
Ein typischer Fehler, den wir immer wieder sehen, ist die Beauftragung getrennter nativer Anwendungen, ohne vorher die tatsächlichen Bedürfnisse der Nutzer zu analysieren. Das Unternehmen nimmt an, “wenn es eine App ist, muss sie nativ sein”, obwohl das Produkt keine Funktion nutzt, die eine PWA nicht tragen würde. Es zahlt dann doppelt für den Aufbau und dreifach für die Pflege und erhält genau denselben geschäftlichen Effekt, den eine einzige Webanwendung gebracht hätte. Das ist ein bisschen so, als kaufte man drei Autos, um auf einer Strecke zur Arbeit zu fahren.
In der Projektpraxis sehen wir auch das umgekehrte Risiko: die Scheinersparnis. Der Kunde wählt nativ “auf Vorrat”, weil “wir vielleicht irgendwann Zugriff auf die Hardware brauchen”. Dieses Irgendwann kommt selten, während das Budget für die Pflege von drei Codebasen ununterbrochen abfließt. Die bessere Strategie? Mit einer PWA starten und erst dann zu nativ wechseln, wenn ein konkreter, belegter Bedarf auftritt. Eine Webarchitektur verschließt den Weg zu nativ in der Zukunft nicht und erlaubt es, heute schneller und günstiger loszulegen.
Tipp: Bevor Sie ein Angebot für eine native Anwendung annehmen, bitten Sie den Dienstleister um eine Aufschlüsselung der Pflegekosten über drei Jahre, nicht nur um den Preis für den Aufbau. Kann oder will der Dienstleister das nicht zeigen, ist das ein Warnsignal. Die realen Kosten eines digitalen Produkts misst man über seinen gesamten Lebenszyklus, nicht an der ersten Rechnung.
Ein Code bedeutet außerdem ein einfacheres Team, eine schnellere Einarbeitung neuer Entwickler und ein geringeres Risiko, dass der Weggang eines einzelnen Spezialisten die Weiterentwicklung des Produkts stoppt. Das schreibt man in keine Kalkulation. Und doch entscheiden auf lange Sicht gerade diese Dinge darüber, ob ein Projekt weiterentwickelbar bleibt oder zu einer schwer zu pflegenden Last wird.
Kein Store, kein Warten: schnellere Rollouts und Aktualisierungen
Der zweite Vorteil einer Progressive Web App, den Kunden erst im Lauf der Zusammenarbeit zu schätzen wissen, betrifft die Verteilung. Eine native Anwendung muss das Freigabeverfahren von App Store und Google Play durchlaufen. Und nein, das ist keine Formalität. Eine Prüfung bei Apple kann von wenigen Stunden bis zu mehreren Tagen dauern, mitunter wird eine Anwendung aus Gründen abgelehnt, die sich nicht vorhersehen lassen, und eine kritische Korrektur wartet in der Warteschlange, während Nutzer den Fehler melden. In einer PWA gibt es dieses Problem schlicht nicht. Die Anwendung liegt auf Ihrem Server, und Sie veröffentlichen sie so, wie man eine Website veröffentlicht.
Für Unternehmen im B2B-Modell, in dem die Reaktionszeit auf eine Kundenmeldung die Geschäftsbeziehung beeinflusst, kann dieser Unterschied entscheidend sein. Stellen Sie sich vor, in einer Anwendung zur Auftragsabwicklung tritt ein Fehler auf, der die Bestellung unmöglich macht. In einer PWA spielen Sie die Korrektur in wenigen Minuten aus, und der Nutzer sieht sie beim nächsten Öffnen der Anwendung, ohne selbst etwas tun zu müssen. Bei nativen Apps bedeutet dieselbe Korrektur einen Build, Tests, die Einreichung im Store, das Warten auf die Prüfung und die Hoffnung, dass der Nutzer die Anwendung überhaupt aktualisiert.
- Sofortige Auslieferung einer Korrektur: Die Änderung geht im Tempo eines Website-Deployments in Produktion, ohne Zwischeninstanzen und ohne Prüfungswarteschlange.
- Keine erzwungenen Aktualisierungen aufseiten der Nutzer: Nutzer müssen nichts herunterladen und nicht auf “Aktualisieren” klicken. Der Service Worker lädt die neue Version im Hintergrund, und die Anwendung frischt sich selbst auf.
- Eine Produktionsversion für alle: Es gibt kein Problem verstreuter Versionen, bei dem ein Teil der Nutzer die alte Anwendung hat, ein Teil die neue und der technische Support raten muss, welche Version jemand gestartet hat.
- Keine Gebühren und keine Store-Richtlinien: Sie unterliegen keinen wechselnden Plattformbestimmungen und keinen Verkaufsprovisionen, die in manchen Geschäftsmodellen mehrere Dutzend Prozent erreichen.
Dieser letzte Punkt verdient gesonderte Aufmerksamkeit. App-Stores ändern die Regeln, und eine Anwendung, die heute den Vorgaben entspricht, kann morgen einen Umbau erfordern, weil die Plattform eine neue Anforderung eingeführt hat. Unternehmen, die ihre Verteilung ausschließlich auf einen Store gestützt haben, werden mitunter zu Geiseln der Entscheidungen von Apple oder Google. Eine PWA gibt Unabhängigkeit: Sie entscheiden, wann und wie Sie Änderungen ausliefern, ohne jemanden um Erlaubnis zu fragen.
Die Auswirkung auf den Entwicklungszyklus ist tiefgreifend. Wenn das Ausliefern einer Korrektur Minuten statt Tage dauert, kann das Team häufiger und mutiger iterieren. Statt Änderungen zu großen, riskanten Releases einmal im Quartal anzusammeln, führen Sie laufend kleine Verbesserungen ein. Das verändert die gesamte Arbeitskultur am Produkt: Rückmeldungen der Nutzer erreichen die Anwendung schnell, und das Unternehmen reagiert fast in Echtzeit auf den Markt. In B2B-Projekten, in denen sich die Anforderungen mit den Prozessen des Kunden weiterentwickeln, ist diese Beweglichkeit ein realer Wettbewerbsvorteil.
In einem Punkt muss man allerdings ehrlich sein. Die Abwesenheit im Store kann ein Marketingnachteil sein, wenn Ihr Geschäftsmodell davon ausgeht, dass Nutzer Anwendungen über die Suche im App Store entdecken. Für Verbraucheranwendungen, die im Store um Aufmerksamkeit konkurrieren, hat Sichtbarkeit dort einen Wert. Für Unternehmensanwendungen, B2B-Produkte und interne Werkzeuge dagegen, bei denen der Nutzer einen Link erhält und die Anwendung mit einem Klick installiert, ist die Abwesenheit im Store ein Vorteil und kein Problem. Wie immer besteht der Schlüssel darin zu verstehen, wer die Anwendung wie erreicht.
Architekturentscheidungen: wann eine PWA reicht und wann nicht
Ein seriöser Dienstleister tut nicht so, als sei eine PWA die Lösung für alles. Diese Technologie hat klar umrissene Möglichkeiten und ebenso klare Grenzen, und wer beide kennt, kann die richtige Architekturentscheidung treffen. Beginnen wir damit, was eine PWA kann, denn die Liste ist länger, als viele Kunden meinen. Service Worker, also Skripte, die im Hintergrund des Browsers laufen, ermöglichen das Zwischenspeichern von Ressourcen und den Offlinebetrieb. Die Anwendung kann ohne Verbindung arbeiten, zuvor geladene Daten anzeigen und Änderungen nach Rückkehr des Netzes synchronisieren. Das Manifest der Anwendung erlaubt es, sie mit eigenem Symbol auf dem Startbildschirm zu installieren und im Vollbildmodus ohne Browserleiste zu starten.
Das deckt einen erstaunlich weiten Anwendungsbereich ab: B2B-Panels, Systeme zur Auftragsabwicklung, interne Werkzeuge, Dashboards, Buchungsanwendungen, Shops und Konfiguratoren. Überall dort, wo eine Anwendung mit Daten, Formularen, Listen und der Kommunikation mit einem Backend arbeitet, erfüllt eine PWA die Aufgabe vollständig. Mehr noch, sie tut das auf allen Geräten gleichzeitig, denn derselbe Code läuft auf einem Android-Telefon, einem iPhone, einem Tablet und einem Computer.
Die Grenzen zeigen sich dort, wo eine Anwendung tiefen Zugriff auf die Hardware oder fortgeschrittene Systemfunktionen braucht. Die wichtigsten Einschränkungen, die wir bei einer Empfehlung berücksichtigen, sind:
- Push-Benachrichtigungen auf iOS: Jahrelang waren sie in PWAs auf Apple-Geräten nicht verfügbar, und obwohl sich die Lage gebessert hat, bleibt die Unterstützung eingeschränkter und launischer als auf Android. Sind Benachrichtigungen das Herz des Produkts, ist das ein wesentlicher Faktor.
- Zugriff auf fortgeschrittene Hardwarefunktionen: Bluetooth, NFC, Sensoren, anspruchsvolle Kameraoperationen oder präzise Geolokalisierung im Hintergrund sind im Browser mitunter nicht verfügbar oder eingeschränkt, besonders auf iOS.
- Native Integrationen und Grafikleistung: Anwendungen, die intensive 3D-Grafik, Videoverarbeitung in Echtzeit oder eine tiefe Integration in Systemfunktionen erfordern, erzielen nativ bessere Ergebnisse.
- Präsenz im Store als geschäftliche Anforderung: Verlangt das Vertriebsmodell zwingend Sichtbarkeit im App Store, ersetzt eine PWA das nicht, auch wenn es Techniken gibt, eine Webanwendung in einen Container zu verpacken.
Ein Beispiel aus der Praxis. Zu uns kommt ein Kunde mit der Idee für eine Anwendung für Servicetechniker im Außendienst. Die Anwendung soll eine Auftragsliste, Berichtsformulare, Fotos vom Einsatzort und eine Karte zeigen. Der erste Reflex des Kunden? Nativ, natürlich. Wir analysieren den Bedarf: Liste, Formulare, Fotos mit der Standardkamera, Karte mit Standort. All das bewältigt eine PWA problemlos, und der Offlinemodus mit Synchronisation nach Rückkehr des Netzes ist für die Arbeit im Außendienst, wo der Empfang schwach sein kann, geradezu ideal. Wir empfehlen eine PWA, und der Kunde spart einen erheblichen Teil des Budgets.
Ein anderer Fall: eine Anwendung, die im Hintergrund permanent den Standort eines Kuriers überwachen, bei jeder Statusänderung sofort Push-Benachrichtigungen senden und sich über Bluetooth mit einem Barcodeleser verbinden soll. Hier empfehlen wir ehrlich nativ oder einen hybriden Ansatz, denn eine PWA auf iOS trägt die Anforderungen an Hintergrundbetrieb und Hardware nicht. Die Kunst besteht darin, diese Grenze in der Analysephase zu erkennen und nicht erst, nachdem das Budget ausgegeben ist.
Es lohnt sich, an einen allgemeinen Grundsatz guter Architektur zu denken, den die Android-Dokumentation mit Blick auf den Entwurf von Anwendungen formuliert:
“The most important principle is separation of concerns: separating your app into methods, classes, files, packages, modules and layers that have clearly defined responsibilities and boundaries.”
Derselbe Grundsatz gilt bei der Technologiewahl. Die Trennung der Geschäftslogik von der Präsentationsschicht sorgt dafür, dass ein gut entworfenes Backend samt API unangetastet bleibt, selbst wenn Sie mit einer PWA beginnen und künftig für eine bestimmte Funktion nativ brauchen. Die Entscheidung für eine PWA muss keine Entscheidung für immer sein, solange die Architektur von Anfang an eine Trennung der Verantwortlichkeiten vorsieht.
Sicherheit, Daten und Integrationen: worauf Sie bei der Einführung einer PWA achten sollten
Da eine Progressive Web App im Browser läuft, gewinnen Fragen der Sicherheit und der Datenverwaltung besondere Bedeutung. Die erste, nicht verhandelbare Anforderung ist HTTPS. Service Worker, die den Offlinemodus und die Installation der Anwendung ermöglichen, funktionieren ausschließlich in einem sicheren Kontext. Das ist nicht nur ein technisches Detail, sondern ein Fundament des Vertrauens: Die gesamte Kommunikation zwischen Anwendung und Server muss verschlüsselt und das Zertifikat korrekt eingerichtet sein. In den Projekten, die wir führen, sind HTTPS und eine korrekte Konfiguration der Sicherheits-Header der Nullpunkt, an dem wir beginnen, und keine Funktion, die man am Ende ergänzt.
Der zweite Bereich ist die Verwaltung der Sitzung und die Datenspeicherung aufseiten des Browsers. Einer PWA stehen mehrere Mechanismen zur Verfügung: localStorage, sessionStorage, IndexedDB und der Cache des Service Workers. Jeder dient einem anderen Zweck und jeder bringt ein anderes Risiko mit sich. Autorisierungstoken, die unvorsichtig im localStorage abgelegt werden, sind ein leichtes Ziel für XSS-Angriffe. Sensible Daten, die offline zwischengespeichert werden, können länger auf dem Gerät bleiben, als sie sollten. Beim Entwurf der Datenschicht müssen wir bewusst entscheiden, was wir lokal speichern, wie lange und wie wir es absichern. Das sind Entscheidungen, die sich nach der Einführung schwer umkehren lassen. Deshalb treffen wir sie am Anfang.
Der dritte Bereich, für Unternehmen zentral, sind Integrationen. Eine Unternehmensanwendung ist selten eine einsame Insel. Sie verbindet sich mit einem ERP-System, einem CRM, einem Zahlungs-Gateway, einem Lagersystem, Werkzeugen zur Rechnungsstellung oder Automatisierungen aufseiten des Backends. Eine PWA kommuniziert mit diesen Systemen über eine API, genau wie eine native Anwendung, in Sachen Integration gibt es also keinerlei Kompromiss. Die gesamte Geschäftslogik, die Autorisierung und die Datenverarbeitung leben im Backend, und die Anwendung, ob Web oder nativ, ist nur eine Präsentationsschicht, die diese API konsumiert. Genau deshalb ist ein gut entworfenes Backend wichtiger als die Wahl der Frontend-Technologie.
In B2B-Projekten sind Integrationen häufig der teuerste und riskanteste Teil. Das System des Kunden hat seine eigene API, seine eigenen Einschränkungen, seine eigenen Anfragelimits und seine eigenen Eigenheiten, die aus Jahren der Entwicklung stammen. Unsere Aufgabe als Dienstleister ist es, die Integrationsschicht so zu entwerfen, dass sie gegen Ausfälle externer Systeme gewappnet ist und Wiederholungsversuche, Warteschlangen und Fehlerprotokollierung beherrscht. Eine Anwendung, die hängen bleibt, weil das Lagersystem nicht binnen einer Sekunde geantwortet hat, ist ein Entwurfsfehler. Unabhängig davon, ob sie eine PWA oder nativ ist.
Die Dokumentation zur Anwendungsarchitektur bringt die Rolle der Datenschicht in einem digitalen Produkt treffend auf den Punkt:
“Business logic is what gives value to your app – it comprises rules that determine how your app creates, stores, and changes data.”
Diesen Satz sollte man sich bei der Planung einer PWA-Einführung merken. Der Wert einer Anwendung liegt nicht darin, ein hübsches Symbol auf dem Startbildschirm zu haben, sondern in der Geschäftslogik und den Daten, mit denen sie arbeitet. Deshalb lautet der wichtigste Tipp dieses Abschnitts: Planen Sie Datenmodell und Autorisierung, bevor der erste Bildschirm entsteht. Zu viele Projekte beginnen mit dem Entwurf der Oberfläche und schieben Datenmodell und Rechtemechanismus im Nachhinein nach, während sie Unstimmigkeiten flicken. Das Ergebnis? Sicherheitslücken, Leistungsprobleme und teure Umbauten.
In der Praxis heißt das: Vor der ersten Zeile Frontend-Code entwerfen wir das Datenschema, definieren Rollen und Berechtigungen, legen die Art der Authentifizierung und Autorisierung fest und kartieren die Integrationen. Erst wenn dieses Fundament solide ist, bauen wir die Oberfläche. Diese Reihenfolge wirkt selbstverständlich, und trotzdem ist sie eine der am häufigsten übersprungenen Phasen in Projekten, die später zur Rettung bei uns landen. Die Modernisierung einer schlecht entworfenen Anwendung kann teurer sein, als sie neu zu bauen, deshalb ist Ordnung bei Daten und Autorisierung eine Investition, die sich vielfach auszahlt.
Skalierbarkeit und SEO: die PWA als Teil des sichtbaren Ökosystems eines Unternehmens
Es gibt einen Vorteil der Progressive Web App, den eine native Anwendung schon von ihrer Anlage her nicht bietet: Sichtbarkeit in der Suchmaschine. Eine PWA ist weiterhin eine Website, ihre Inhalte sind also für Google indexierbar. Nutzer können Ihr Produkt über die Suche finden, über einen direkten Link auf einem bestimmten Bildschirm landen und ihn weitergeben. Eine native Anwendung ist in dieser Hinsicht eine Blackbox: Ihre Inhalte existieren für die Suchmaschine nicht, und der einzige Weg dorthin führt über den App-Store oder eine direkte Empfehlung. Für Unternehmen, die eine Anwendung als Teil eines breiteren Marketing- und Vertriebsökosystems verstehen, ist dieser Unterschied grundlegend.
Indexierbarkeit bedeutet, dass Inhalte, Angebote, Artikel oder Produktkarten in einer PWA auf die Positionierung der Domain einzahlen. Jeder wertvolle Bildschirm kann zu einer Landingpage für organischen Traffic werden. Eine native Anwendung braucht ein eigenes Werbebudget, weil sie keinen natürlichen Traffic aus der Suchmaschine nutzt. In einem Modell, in dem ein Unternehmen in Inhalte und Sichtbarkeit investiert, verbindet eine PWA die Funktionalität einer Anwendung mit der Reichweite einer Website, was nativ nicht zusammenbringt.
Die andere Seite der Medaille sind Skalierbarkeit und Leistung auf unterschiedlichen Geräten und Formfaktoren. Eine PWA ist von Natur aus responsiv und läuft auf Telefon, Tablet, Laptop und großem Bildschirm. Hier lohnt es sich, an einen Grundsatz zu erinnern, den die Dokumentation zur Anwendungsarchitektur formuliert:
“Build apps that gracefully handle configuration changes, such as device orientation changes or changes in the size of the app window.”
Eine gut gebaute PWA setzt diesen Grundsatz unmittelbar um, denn ein flexibles Layout ist ihr in die DNA geschrieben. Das Skalieren des Traffics ist wiederum eine Frage des Backends und der Infrastruktur, nicht der Frontend-Technologie. Eine Webanwendung, die hinter einem passenden Load Balancer und mit gut entworfenem Cache betrieben wird, skaliert so, wie jede moderne Internetanwendung skaliert. Das ist ein reifes, gut erschlossenes Feld der Ingenieurarbeit, in dem die Risiken vorhersehbar und die Kosten kontrollierbar sind.
Der Ordnung halber fassen wir in Kurzform die acht Gründe zusammen, aus denen die Einführung einer PWA im Unternehmen in den meisten geschäftlichen Szenarien einer mobilen App überlegen ist:
- Ein Code statt drei – niedrigere Aufbaukosten und kein Bedarf, getrennte Teams für iOS, Android und Web vorzuhalten.
- Günstigere Pflege – eine Codebasis bedeutet eine technische Schuld und einen Aktualisierungspfad statt drei.
- Kein Freigabeverfahren der Stores – Rollouts und Korrekturen ohne die Prüfungswarteschlange von App Store und Google Play.
- Sofortige Aktualisierungen – Nutzer haben immer die neueste Version, ohne manuell etwas herunterzuladen.
- Eine Produktionsversion – Schluss mit verstreuten Versionen und dem Raten, welche Anwendung ein Nutzer gestartet hat.
- Sichtbarkeit in der Suchmaschine – für Google indexierbare Inhalte, was nativ nicht bietet.
- Plattformübergreifend aus einem Code – Telefon, Tablet und Computer gleichzeitig bedient.
- Unabhängigkeit von der Plattformpolitik – keine Provisionen und keine wechselnden Store-Bestimmungen.
Diese Liste bedeutet nicht, dass eine PWA immer gewinnt. Sie bedeutet, dass in einem typischen Unternehmens-, B2B- oder Dienstleistungsprojekt der Vorsprung so deutlich ist, dass die Beweislast bei dem liegt, der die Wahl von nativ begründen will. Als Dienstleister behandeln wir nativ als bewusste Entscheidung, die aus einem konkreten Bedarf folgt, und nicht als Standardwahl aus Gewohnheit. Ein skalierbares, sichtbares und in der Pflege günstiges Produkt ist in den meisten Fällen ein Produkt, das als PWA gebaut wurde.
Häufige Fragen zur Einführung einer PWA (FAQ)
Ersetzt eine PWA die native Anwendung in meinem Unternehmen?
In den meisten geschäftlichen Anwendungsfällen ja, aber nicht in allen. Wenn Ihre Anwendung mit Daten, Formularen, Listen, Integrationen in B2B-Systeme und der Kommunikation mit einem Backend arbeitet, deckt eine PWA den Bedarf vollständig und liefert denselben Effekt zu geringeren Kosten. Verlangt das Produkt dagegen tiefen Zugriff auf die Hardware, Hintergrundbetrieb, fortgeschrittene Push-Benachrichtigungen auf iOS oder intensive Grafik, sind nativ oder ein hybrider Ansatz treffender. Der Schlüssel ist die Analyse der realen Nutzerbedürfnisse vor der Technologiewahl. In der Praxis empfehlen wir, mit einer PWA zu beginnen und erst dann zu nativ zu greifen, wenn eine konkrete, belegte Funktion auftritt, die der Browser nicht trägt.
Wie lange dauert die Einführung einer PWA und was kostet sie im Vergleich zu einer mobilen App?
Eine PWA ist in der Umsetzung meist deutlich günstiger und schneller, weil Sie einen Code statt drei bauen und pflegen. Die Ersparnis betrifft nicht nur den einmaligen Aufbau, sondern vor allem die über Jahre verteilte Pflege: Aktualisierungen, Korrekturen und den Umgang mit technischen Schulden. Ein konkretes Angebot hängt von der Komplexität der Geschäftslogik, der Zahl der Integrationen und den Anforderungen an den Offlinemodus ab, deshalb legt ein seriöser Dienstleister eine Kalkulation nach der Bedarfsanalyse vor und nicht aus einer Preisliste. Es lohnt sich, eine Aufschlüsselung der Kosten in Aufbau und Pflege über mehrere Jahre zu verlangen, denn dieser zweite Posten entscheidet am häufigsten über die Gesamtwirtschaftlichkeit des Projekts.
Funktioniert eine PWA offline und unterstützt sie Benachrichtigungen?
Ja, eine PWA funktioniert offline dank der Service Worker, die Ressourcen und Daten zwischenspeichern und es erlauben, die Anwendung ohne Verbindung zu nutzen und Änderungen nach Rückkehr des Netzes zu synchronisieren. Das ist besonders bei der Arbeit im Außendienst wertvoll, wo der Empfang instabil sein kann. Push-Benachrichtigungen funktionieren auf Android und dem Desktop gut, auf iOS ist die Unterstützung dagegen neuer und stärker eingeschränkt. Sind Benachrichtigungen das Herz Ihres Produkts, insbesondere auf Apple-Geräten, sollten Sie diese Anforderung mit dem Dienstleister in der Analysephase besprechen, um einzuschätzen, ob eine PWA genügt oder ob ein hybrider Ansatz nötig wird.
Fazit: die PWA als vernünftige Wahl und nächster Schritt
Wir sind acht Gründe durchgegangen, aus denen die Einführung einer PWA im Unternehmen in den meisten realen Projekten einer mobilen App überlegen ist. Ein Code statt drei senkt die Kosten für Aufbau und Pflege. Das fehlende Freigabeverfahren der Stores beschleunigt Rollouts und erlaubt laufendes Iterieren. Sichtbarkeit in der Suchmaschine macht die Anwendung zum Teil des Marketingökosystems des Unternehmens. Plattformübergreifende Nutzung, Unabhängigkeit von der Plattformpolitik und vorhersehbare Skalierbarkeit runden das Bild ab. Diese Vorteile sind nicht theoretisch. Sie folgen aus dem, was wir in Projekten sehen, die wir seit 2006 führen.
Zugleich tun wir nicht so, als sei eine PWA die Antwort auf jede Frage. Dort, wo ein Produkt tiefen Zugriff auf die Hardware, Hintergrundbetrieb oder fortgeschrittene Benachrichtigungen auf iOS braucht, empfehlen wir ehrlich nativ oder eine hybride Lösung. Ein guter Dienstleister wählt die Technologie passend zum Problem und nicht das Problem passend zu der Technologie, die er gerade lieber verkauft. Die wichtigste Entscheidung fällt nicht bei der Wahl des Frontends, sondern beim soliden Entwurf von Datenmodell, Autorisierung und Integrationen, denn sie bestimmen Wert und Beständigkeit der Anwendung.
Bei Web Systems gehen wir jedes Projekt von den realen geschäftlichen Bedürfnissen her an: Wir analysieren, wer die Anwendung wie nutzen wird, welche Systeme zu integrieren sind und wie das Produkt wachsen soll. Wir konzipieren und realisieren MVPs, Web- und Mobilanwendungen, B2B-Systeme, API-Integrationen, Automatisierungen sowie KI-Lösungen und modernisieren außerdem bestehende Systeme, die dem Unternehmen nicht mehr folgen können. Als technischer Partner helfen wir Ihnen, die richtige Architekturentscheidung zu treffen, bevor Sie das Budget ausgeben, und nicht erst im Nachhinein.
Wenn Sie die Einführung einer PWA, den Bau einer Anwendung, die Integration von Systemen, die Automatisierung von Prozessen oder die Modernisierung des Bestehenden planen, schreiben Sie uns. Wir beginnen mit einem Gespräch über Ihre realen Bedürfnisse und sagen Ihnen, welche Lösung sich wirklich rechnet und nicht nur im Angebot gut klingt.
