Shop-App oder PWA: die Entscheidung nach Kosten und Nutzen

Die Frage kommt meist im selben Satz wie das Budget: Brauchen wir eine eigene App, oder genügt der Shop im Browser? Die verfügbaren Zahlen zeichnen ein nüchterneres Bild als das Bauchgefühl. Auf dem Smartphone teilt sich der Onlinekauf in Deutschland zur Hälfte zwischen Apps und mobilen Websites auf (HDE), und 69 Prozent der gesamten Onlineumsätze entfallen auf mobile Endgeräte (HDE). Beide Wege tragen also Umsatz, aber sie tragen ihn zu sehr unterschiedlichen Kosten. Eine native App bringt Eintrittsgebühren, Umsatzbeteiligungen, ein Freigabeverfahren und einen jährlichen Anpassungszwang mit sich. Eine Progressive Web App, kurz PWA, läuft vom eigenen Server und verlangt dafür Aufmerksamkeit an anderer Stelle: Ladezeit, Installierbarkeit und die Grenzen des Browsers auf dem jeweiligen Betriebssystem. Dieser Beitrag legt beide Wege nebeneinander, sortiert die Kostenarten und benennt die fünf Fragen, an denen die Entscheidung tatsächlich hängt. Dazu gehören die Grundlagen der technischen Umsetzung im Web und die Kennzahlen für die spätere Messung.

Wie viel Umsatz überhaupt am Smartphone entsteht

Der deutsche Onlinehandel im engeren Sinne ist 2025 um 3,9 Prozent auf 92,3 Milliarden Euro netto gewachsen (HDE). Diese Zahl trägt jede App-Diskussion, solange man sie nicht ins Verhältnis setzt: Der Onlineanteil am gesamten Einzelhandel liegt bei 13,5 Prozent, nach 13,4 Prozent im Vorjahr (HDE). Eine Shop-App bekommt also einen Anteil eines Anteils ab. Wer eine sechsstellige Investition mit einem prozentualen Zuwachs begründet, sollte zuerst die Bezugsgröße kennen: den eigenen mobilen Umsatz, nicht den Marktdurchschnitt. Wo der mobile Anteil klein ist, bleibt auch der Hebel klein; wo er groß ist, lohnt zuerst der Blick auf die Abbrüche im Bestellvorgang, weil dort der Umsatz verloren geht, bevor überhaupt ein zweiter Kanal ins Spiel kommt.

Innerhalb des mobilen Umsatzes liegt die eigentliche Überraschung. Die Hälfte der Onlinekäufe auf dem Smartphone läuft über Apps, die andere Hälfte über mobile Websites (HDE); im Vorjahr lag das Verhältnis bei 48 zu 52 zugunsten der Websites (HDE). Daraus folgt zweierlei. Erstens: Wer heute keine App hat, verliert nicht die Hälfte seines mobilen Geschäfts, sondern bedient den Teil des Marktes, der ohnehin im Browser kauft. Zweitens: Wer eine App baut, gewinnt selten neue Kunden, sondern verlagert bestehende. Der wirtschaftliche Effekt zeigt sich deshalb erfahrungsgemäß in der Wiederkaufrate von Stammkunden, nicht in der Neukundengewinnung. Eine belastbare Rechnung trennt den Umsatz, der ohne App ebenfalls entstanden wäre, von dem, der zusätzlich entsteht, und das gelingt nur mit einer sauberen Zuordnung im mobilen Kaufverhalten.

Was eine PWA ist und was der Browser ohne Store kann

Eine PWA ist kein Produkt, sondern die Kombination aus zwei Bausteinen: einem Service Worker, der Netzanfragen abfängt und Inhalte lokal vorhält, und einem Web-App-Manifest, das Name, Symbol, Startadresse und Anzeigemodus beschreibt. Erst beides zusammen macht eine Website auf dem Homebildschirm startfähig. Im Bestand des Netzes sind die Bausteine ungleich verteilt: 18,9 Prozent der erfassten Sites setzen einen Service Worker ein, aber nur rund 9 Prozent ein Manifest (Web Almanac). Der Grund ist banal, denn Service Worker kommen häufig als Beiwerk mit Verwaltungswerkzeugen ins Haus, ohne dass jemand eine PWA geplant hätte. Für die Entscheidung heißt das: Die technische Grundlage liegt in vielen Shops bereits vor, sie ist nur noch nicht als Produktentscheidung genutzt worden.

Rechnet man beide Bausteine zusammen, wird das Feld dünn. 24,5 Prozent der Websites nutzen mindestens eines der beiden Merkmale, aber nur 3,3 Prozent auf dem Desktop und 3,5 Prozent auf dem Smartphone haben beides zugleich umgesetzt (Web Almanac). Die installierbare Web-App ist trotz jahrelanger Verfügbarkeit die Ausnahme geblieben. In der Spitze sieht es anders aus. Unter den 1.000 meistbesuchten Seiten arbeiten 30,3 Prozent auf dem Desktop und 28,9 Prozent auf dem Smartphone mit einem Service Worker (Web Almanac). Dort, wo der Wettbewerb um mobile Aufmerksamkeit am härtesten ist, gehört die Technik zum Handwerk. Für einen mittelständischen Shop heißt das: Der Abstand zur Spitze lässt sich mit überschaubarem Aufwand verkürzen, denn die Bausteine sind standardisiert und brauchen keine Freigabe. Wie sie sich in eine entkoppelte Frontend-Architektur einfügen, hängt vom bestehenden System ab.

Die Kostenarten einer nativen App

Die erste Kostenart fällt an, bevor irgendetwas entwickelt wurde. Die Teilnahme am Apple Developer Program kostet 99 USD im Jahr, die Enterprise-Variante 299 USD im Jahr (Apple). Bei Google fällt für die Registrierung eines Entwicklerkontos eine einmalige Gebühr von 25 USD an (Google). Das sind überschaubare Beträge, aber sie sind wiederkehrend beziehungsweise dauerhaft an ein Konto gebunden, das jemand pflegen muss: Zertifikate, Schlüssel, Zugriffsrechte, Zwei-Faktor-Verfahren. Fällt diese Pflege aus, steht die Veröffentlichung still, und beim Wechsel einer Agentur ist der Kontenzugang die häufigste Sollbruchstelle. Wer eine App plant, klärt die Kontenhoheit deshalb vor der Beauftragung, mit derselben Sorgfalt, die auch ein tragfähiges Lastenheft für ein Shop-Projekt verlangt.

Die zweite Kostenart trifft nur digitale Umsätze und wird deshalb häufig überschätzt. Wer Waren versendet, zahlt für den Kauf in der App keine Plattformprovision; nach Angaben des Betreibers verteilen 97 Prozent der Entwickler ihre Apps ohne Dienstgebühr (Google). Sobald jedoch digitale Güter, Abonnements oder Guthaben in der App verkauft werden, greift die Beteiligung. Im Kleinunternehmerprogramm liegt sie bei 15 Prozent bis zu einer Million US-Dollar Jahreserlös (Apple). In der EU gilt ab dem 1. Oktober 2026 für Verkäufe über die hauseigene Kaufabwicklung ein Satz von 26 Prozent, im Kleinunternehmerprogramm und für Abonnements ab dem zweiten Jahr sind es 15 Prozent (Apple). Google Play rechnet davon getrennt ab: Für Käufe im Europäischen Wirtschaftsraum gilt dort seit dem 30. Juni 2026 eine eigene Staffel mit 10 Prozent auf Abonnements und auf die erste Million US-Dollar Jahreserlös, 20 Prozent auf weitere Käufe in Neuinstallationen und 25 Prozent in bestehenden Installationen, jeweils zuzüglich 5 Prozent Abrechnungsgebühr; die Stufe von 30 Prozent oberhalb einer Million betrifft nur die übrigen Märkte (Google). Für einen Shop mit Warenversand ist das eine Randbedingung, für einen Shop mit digitalen Zusatzleistungen dagegen eine harte Margenfrage.

Die Kostenarten einer installierbaren Web-App

Eine PWA verschiebt die Kosten von der Plattform in das eigene Haus. Das Manifest selbst ist eine kleine Datei; der Aufwand steckt in dem, was danach verlangt wird. Der Service Worker muss entscheiden, welche Antworten aus dem Zwischenspeicher kommen dürfen und welche frisch geholt werden. Bei Preisen, Beständen und Warenkörben ist die falsche Antwort teurer als eine langsame. Symbole werden in mehreren Auflösungen gebraucht, die Startadresse braucht eine Kennzeichnung, damit sich Installationen später von gewöhnlichen Besuchen unterscheiden lassen, und der Wechsel zwischen Offline- und Onlinezustand braucht eine sichtbare Rückmeldung. Nichts davon dauert Monate, aber alles davon berührt ein bestehendes Frontend an vielen Stellen.

{
  "name": "Beispielshop",
  "short_name": "Beispielshop",
  "start_url": "/?quelle=homescreen",
  "scope": "/",
  "display": "standalone",
  "background_color": "#f0f7f6",
  "theme_color": "#004d43",
  "icons": [
    { "src": "/icons/app-192.png", "sizes": "192x192", "type": "image/png" },
    { "src": "/icons/app-512.png", "sizes": "512x512", "type": "image/png" },
    { "src": "/icons/app-maskable.png", "sizes": "512x512", "type": "image/png", "purpose": "maskable" }
  ]
}

Der eigentliche Preis einer PWA ist jedoch das Tempo. Eine installierbare Web-App, die langsam startet, verliert genau den Vorteil, für den sie gebaut wurde. Wie viel Luft im Markt liegt, zeigt die Verteilung der Core Web Vitals: 48 Prozent der mobilen Websites und 56 Prozent der Desktop-Websites erreichten 2025 gute Werte, nach 44 und 55 Prozent im Jahr davor (Web Almanac). Rund die Hälfte der mobilen Websites erfüllt die Schwellen also nicht, und wer die App-Frage stellt, hat häufig zuerst ein Tempoproblem im Web, das ein zweiter Kanal umgeht statt löst. Die Reihenfolge lautet deshalb meist: erst Core Web Vitals und Reaktionszeit auf Eingaben in Ordnung bringen, dann über Installierbarkeit reden.

Push, Offline und Homebildschirm im Funktionsvergleich

Das häufigste Argument für eine App ist die Benachrichtigung, und es ist schwächer geworden. Seit iOS und iPadOS 16.4 unterstützt auch Safari Web-Push für Web-Apps auf dem Homebildschirm (WebKit); die Funktion setzt allerdings voraus, dass die Nutzerin die Seite vorher dort abgelegt hat. Auf Android steht Web-Push schon länger direkt im Browser zur Verfügung. Die Frage lautet damit nicht mehr, ob eine Website Benachrichtigungen senden kann, sondern unter welcher Bedingung. Die vorherige Ablage auf dem Homebildschirm ist der eigentliche Unterschied zur App und eine Hürde, die im Kaufprozess bewusst platziert werden will. Wie sich Benachrichtigungen im Shop einsetzen lassen, ohne die Erlaubnis zu verbrennen, behandelt der Beitrag zu Web-Push und Kundenbindung.

Die Annahmequote relativiert das Argument weiter. Unter den Sites mit Service Worker setzen lediglich 7 Prozent überhaupt Push-Ereignisse ein, ebenso viele reagieren auf das Anklicken einer Benachrichtigung (Web Almanac). Und dort, wo gefragt wird, fällt die Antwort selten positiv aus: In einer Auswertung von Berechtigungsanfragen aus dem Juni 2022 wurden auf mobilen Geräten 19 Prozent der Anfragen angenommen, 35 Prozent abgelehnt, 34 Prozent ignoriert und 13 Prozent weggewischt (Web Almanac). Eine Ablehnung ist in der Regel endgültig. Wer den Kanal als tragende Säule einer App-Rechnung ansetzt, rechnet mit einer Minderheit einer Minderheit. Das spricht nicht gegen Benachrichtigungen, aber gegen den Satz, eine App lohne sich wegen Push.

Ein Detail entscheidet häufiger über die Offlinefähigkeit, als es die Datenblätter vermuten lassen: Safari löscht die von Skripten beschreibbaren Speicher einer Website nach sieben Tagen Safari-Nutzung ohne Interaktion mit der Seite (WebKit). Eine nur gelegentlich besuchte Website verliert ihren lokalen Bestand also regelmäßig. Für Web-Apps, die auf dem Homebildschirm abgelegt wurden, zählt der Hersteller eigene Nutzungstage und nimmt sie laut Beitrag von dieser Regel aus. Damit wird die Installation vom Komfortmerkmal zur technischen Voraussetzung: Offlinefähigkeit hält verlässlich nur in der installierten Fassung. Wer Offline als Argument führt, muss zuerst die Installationsquote steigern, und die ist keine Frage der Technik, sondern der Ansprache.

Freigabe, Wartung und der Takt der Stores

Eine App wird nicht veröffentlicht, sondern zugelassen. Der Transparenzbericht des Betreibers nennt für das Jahr 2025 insgesamt 2.093.244 abgelehnte Einreichungen (Apple), bezogen auf 9.100.620 geprüfte Einreichungen. Abgelehnt heißt dabei nicht endgültig, denn 387.087 Einreichungen wurden nach einer Ablehnung doch genehmigt (Apple). Für die Planung bedeutet das weniger ein Risiko des Scheiterns als ein Risiko für den Terminplan. Eine Kampagne, deren Start an einer Freigabe hängt, trägt eine Abhängigkeit, die im eigenen Haus nicht auflösbar ist. Im Web entscheidet der eigene Auslieferungsprozess über den Zeitpunkt, was vor allem bei Änderungen mit festem Stichtag zählt.

Auch die Sichtbarkeit im Store ist kein Selbstläufer. Derselbe Bericht weist 2.172.472 Apps im App Store aus (Apple). Eine neue Shop-App tritt damit in einen Markt ein, in dem sie zunächst niemand sucht. Die Installation muss aus den eigenen Kanälen kommen: aus dem Newsletter, aus der Bestellbestätigung, aus der Paketbeilage, aus dem Ladengeschäft. Genau diese Kanäle stehen einer Web-App ebenso offen, mit dem Unterschied, dass der erste Klick dort bereits im Shop landet und nicht in einem Verzeichnis. Wer beide Welten verbindet, denkt die Übergabe zwischen Filiale und Shop ohnehin mit; die Mechanik dazu beschreibt der Beitrag zur Anbindung des Kassensystems.

• Der Anpassungszwang ist jährlich: Neue Apps und Aktualisierungen müssen mindestens Android 16 (API-Level 36) als Ziel angeben, um bei Google Play eingereicht werden zu können; für Wear OS und Automotive gilt API-Level 35, für TV und XR API-Level 34 (Google).
• Größe kostet Installationen: Liegt eine App über 200 MB, zeigt der Store beim Installieren über eine Mobilfunkverbindung einen Hinweis auf die Größe an (Google).
• Zwei Betriebssysteme bedeuten zwei Prüfzyklen und damit zwei Termine, an denen eine Änderung im Feld ankommt, oder eben nicht ankommt.
• Die Wartung läuft ohne neue Funktionen weiter: Signaturen, Zertifikate, Datenschutzangaben und Altersfreigaben wollen gepflegt werden, sonst fällt eine App aus dem Angebot.

Recht: Barrierefreiheit trifft beide Wege

Ein Argument fällt in der Abwägung regelmäßig unter den Tisch: Die Barrierefreiheitspflicht unterscheidet nicht zwischen Kanälen. Das Barrierefreiheitsstärkungsgesetz erfasst Dienstleistungen im elektronischen Geschäftsverkehr, die über Webseiten und über Anwendungen auf Mobilgeräten angeboten werden (BFSG). Wer also eine App baut, verdoppelt nicht nur den Entwicklungsaufwand, sondern auch den Prüfaufwand für Barrierefreiheit, mit einem eigenen Regelwerk je Plattform, eigenen Bedienhilfen und eigenen Testgeräten – der am häufigsten unterschätzte Posten in App-Kalkulationen. Was im Web dafür zu tun ist, ordnet die Seite zur Barrierefreiheit nach BFSG ein; für Medieninhalte gilt zusätzlich, was der Beitrag zu Untertiteln und Transkripten beschreibt.

Die Ordnungswidrigkeit kann in den Fällen des Absatzes 1 Nummer 1, 7, 8, 9 und 10 mit einer Geldbuße bis zu hunderttausend Euro und in den übrigen Fällen mit einer Geldbuße bis zu zehntausend Euro geahndet werden.

Barrierefreiheitsstärkungsgesetz, § 37 Absatz 2

Eine Ausnahme gibt es, und sie ist scharf umrissen: Als Kleinstunternehmen gilt ein Unternehmen, das weniger als zehn Personen beschäftigt und entweder höchstens 2 Millionen Euro Jahresumsatz erzielt oder dessen Jahresbilanzsumme 2 Millionen Euro nicht übersteigt (BFSG). Wer darunter liegt, ist von der Pflicht für Dienstleistungen ausgenommen; wer darüber liegt oder darüber hinauswächst, fällt hinein, und zwar für jeden Kanal, den er betreibt. Es lohnt sich deshalb, die Schwelle vor der App-Entscheidung zu prüfen: Ein heute nicht erfasster Kanal kann im nächsten Geschäftsjahr erfasst sein. Der Nachweis entsteht nicht rückwirkend, sondern durch dokumentierte Prüfungen während der Entwicklung.

Die zweite rechtliche Größe betrifft die Konditionen selbst. Die Bedingungen der großen Plattformen stehen unter europäischer Aufsicht: Der Digital Markets Act sieht Geldbußen von bis zu 10 Prozent des im vorausgegangenen Geschäftsjahr weltweit erzielten Gesamtumsatzes vor, wenn ein Torwächter die Vorgaben nicht einhält (Digital Markets Act). Als Torwächter gilt unter anderem, wer mit einem zentralen Plattformdienst mindestens 45 Millionen monatlich aktive Endnutzer und mindestens 10.000 jährlich aktive gewerbliche Nutzer in der Union erreicht (Digital Markets Act). Für einen Händler ist das keine Pflicht, sondern eine Planungsgröße: Provisionssätze und Kaufabwicklungen in den Stores sind Gegenstand laufender Verfahren und haben sich in den vergangenen Jahren mehrfach geändert. Eine Kalkulation, die auf einem heutigen Prozentsatz beruht, sollte deshalb einen Korridor ansetzen statt eines Punktwerts.

Die Entscheidung in fünf Fragen

Die Entscheidung lässt sich auf wenige Fragen eindampfen, die alle mit Daten aus dem eigenen Haus beantwortbar sind. Keine davon ist technisch. Wer sie beantwortet hat, braucht keine Grundsatzdebatte mehr, sondern eine Reihenfolge. Die Antworten gehören schriftlich festgehalten: Sie begründen später die Budgetverteilung und erlauben es, die Entscheidung nach einem Jahr sachlich zu überprüfen statt neu zu verhandeln.

1. Wie hoch ist der Anteil wiederkehrender Käufer? Eine App zahlt sich über Wiederkäufe aus. Bei überwiegend einmaligen Käufen fehlt die Grundlage, weil die Installation als Hürde vor dem ersten Kauf steht.
2. Verkaufen wir digitale Güter? Sobald Abonnements, Guthaben oder Freischaltungen in der App verkauft werden, greift die Umsatzbeteiligung von 15 Prozent im Kleinunternehmerprogramm (Apple). Bei reinem Warenversand bleibt sie außen vor (Google).
3. Erfüllt der mobile Shop heute die Temposchwellen? Solange die Antwort nein lautet, verlagert eine App das Problem, statt es zu lösen. Bei 48 Prozent guter mobiler Werte im Netz ist das der Regelfall (Web Almanac).
4. Brauchen wir Gerätefunktionen jenseits des Browsers? Dauerhafte Hintergrundverarbeitung, tiefe Sensorik oder Betrieb ohne Netzverbindung sind echte Gründe. Benachrichtigungen allein sind es seit iOS und iPadOS 16.4 kaum noch (WebKit).
5. Wer pflegt den zweiten Kanal in drei Jahren? Der jährliche Anpassungszwang an neue Ziel-APIs (Google) und die doppelte Prüfung auf Barrierefreiheit (BFSG) laufen weiter, auch wenn das Projektbudget längst aufgebraucht ist.

Ein Vorgehen über zwölf Wochen

Wer die Entscheidung nicht am Reißbrett treffen will, kann sie in zwölf Wochen erarbeiten, ohne vorher eine App zu beauftragen. Das Vorgehen kostet Messzeit statt Entwicklungsbudget und liefert Zahlen, die für den eigenen Shop gelten. Jede Stufe behält ihren Wert, auch wenn die Entscheidung am Ende gegen eine App ausfällt.

1. Woche 1 bis 2: Ausgangslage messen. Mobiler Umsatzanteil, Wiederkaufrate, Anteil angemeldeter Kunden und die Ladezeitkennwerte je Seitenvorlage. Ohne diese vier Werte bleibt jede Rechnung eine Meinung.
2. Woche 3 bis 5: Tempo im Web in Ordnung bringen. Bilder, Skripte von Dritten, Serverantwortzeit. Diese Arbeit zahlt auf beide Wege ein und ist die Voraussetzung dafür, dass Installierbarkeit überhaupt einen Nutzen hat.
3. Woche 6 bis 8: Manifest und Service Worker ergänzen. Symbole, Startadresse, Anzeigemodus, eine bewusst gewählte Zwischenspeicherstrategie und eine Kennzeichnung der Startadresse, damit sich Installationen später auswerten lassen.
4. Woche 9 bis 10: Installation aktiv anbieten. Ein Hinweis nach dem ersten Kauf, nicht beim ersten Besuch. Die Quote aus dieser Phase ist die belastbarste Vorhersage für die Annahme einer App.
5. Woche 11 bis 12: Rechnung aufstellen. Installationsquote, Wiederkaufrate der installierten Gruppe und die Kostenarten aus diesem Beitrag gegeneinanderstellen. Erst jetzt ist die App-Frage sachlich entscheidbar.

Was zuerst gemessen gehört

Drei Größen entscheiden die Frage, und keine davon steht in einem Angebot. Erstens der Anteil des mobilen Umsatzes am Gesamtumsatz, denn er begrenzt den Hebel nach oben. Zweitens der Anteil wiederkehrender Käufer, denn er bestimmt, ob eine Installation jemals ausgelastet wird. Drittens die Ladezeit auf dem Smartphone, weil sie die Grundlage für beide Wege bildet und weil rund die Hälfte der mobilen Websites die Schwellen der Core Web Vitals nicht erreicht (Web Almanac). Wer diese drei Werte kennt, kann die Kostenarten dagegenhalten: Eintritt, Beteiligung, Freigabe, Pflege. Erst dann wird aus der Grundsatzfrage eine vorlagefähige Rechnung.

Der zweite Punkt ist die Fristigkeit. Eine Website lässt sich zurückbauen, eine App bleibt üblicherweise mehrere Jahre im Betrieb, mit jährlicher Anpassung an neue Zielversionen (Google) und einer Prüfpflicht für Barrierefreiheit, die für beide Kanäle gilt (BFSG). Der Betrieb ist der größere Teil der Rechnung, nicht die Entwicklung. Wer ihn vorher beziffert, entscheidet tragfähig; wer ihn übergeht, hat in zwei Jahren einen Kanal, den niemand pflegt. Wie sich Anforderungen, Aufwand und Betrieb zu einer Entscheidung zusammenführen lassen, gehört in eine strukturierte Beratung und Konzeption, bevor Entwicklungsbudget gebunden wird. Für die technische Umsetzung im Web gilt danach derselbe Maßstab wie für jede andere Individualentwicklung: messbar, wartbar, dokumentiert.