Native App, Web App oder PWA? So vermeiden Sie eine teure Fehlentscheidung

Stellen Sie sich eine Besprechung vor, in der der Satz „Wir brauchen eine App“ fällt. Wenige Wochen später vergleicht das Unternehmen bereits Angebote für zwei native Apps, obwohl niemand gefragt hat, wie oft Menschen das Produkt öffnen werden und ob sie etwas benötigen, das ein Browser nicht leisten kann.

Die Wahl der Plattform hängt davon ab, wie oft und wo jemand das Produkt nutzt, was das Gerät können muss und was es kostet, mehrere Versionen parallel zu pflegen. Ob am Ende eine native App oder Web App das Rennen macht, sollten deshalb nicht die Vorlieben des Dienstleisters entscheiden.

„Wir brauchen eine App“ ist ein Reflex, keine Anforderung

Der Wunsch nach einer App entsteht oft beim Blick auf den Wettbewerb und benennt eine Lösung, bevor das Problem benannt ist. Sinnvoll ist die umgekehrte Reihenfolge: zuerst das Unternehmen und den Prozess verstehen, überflüssige Schritte streichen, dann die Nutzererfahrung gestalten und erst ganz am Ende die Technologie wählen. Im Schichtenmodell eines Unternehmens gehört die Plattformwahl zur Schicht Experience: Sie bestimmt, wo jemand dem Produkt begegnet und wie viel Aufwand ihn das kostet.

Die Optionen, erklärt für die Geschäftsführung

• Die native App ist Software, die direkt für ein einzelnes Betriebssystem geschrieben wird, separat für iOS und separat für Android. Das bedeutet zwei Codebasen, das heißt zwei unabhängig voneinander gepflegte Bestände an Quellcode.
• Die Cross-Platform-App entsteht durch plattformübergreifende Entwicklung: Aus einer einzigen Codebasis wird die App für iOS und Android erstellt. Ein Beispiel ist Flutter von Google, das laut eigener FAQ (aktualisiert am 14. September 2026) ermöglicht, die Entwickler in einem Team zusammenzuführen und Releases aufeinander abzustimmen; dabei handelt es sich jedoch um eine Herstelleraussage. Flutter ruft nativen Code über sogenannte Platform Channels auf, ganz ohne iOS- und Android-Know-how kommt das Team also nicht aus.
• Die Web App läuft ohne Installation im Browser. Google führt im Kurs Learn PWA (aktualisiert am 20. September 2024) an, dass im Web das Paketieren, eine zusätzliche Inhaltsprüfung und verzögerte Updates entfallen.
• Die PWA, also die Progressive Web App, ist eine Web App, die sich installieren lässt. Nach der Installation hat sie laut demselben Kurs ein Icon auf dem Startbildschirm und ein eigenes Fenster ohne Browseroberfläche. Den Offlinemodus, also das Arbeiten ohne Netzverbindung, übernimmt ein Service Worker: ein Skript, das der Browser bei Bedarf ausführt und das laut der MDN-Dokumentation von Mozilla die Dateien der App in einem lokalen Cache speichern kann.

Kriterien, die vor der Technologiefrage entscheiden

• Nutzungshäufigkeit. Ein Tool, das mehrmals täglich geöffnet wird, verdient ein Icon auf dem Startbildschirm, das bietet aber auch eine PWA. Bei einem Service, den ein Kunde wenige Male im Jahr nutzt, schiebt die Installation lediglich einen zusätzlichen Schritt vor die erste Nutzung.
• Nutzungskontext. Der Techniker im Keller ohne Empfang, der Lagerist mit Handschuhen, der Fahrer im Auto. Beim Offlinemodus muss genau festgelegt werden, was ohne Netzverbindung geschehen soll: Lesen, Schreiben, Synchronisierung und der Umgang mit Konflikten zwischen Änderungen.
• Gerätefunktionen. Kamera, Standort im Hintergrund, Bluetooth, NFC, Benachrichtigungen, Biometrie. Prüfen Sie die Unterstützung der Funktionen, auf die Sie nicht verzichten können, zum Entscheidungszeitpunkt auf den Zielgeräten, denn sie ändert sich. Vorsicht bei der Hintergrundverarbeitung: Laut MDN (13. September 2026) läuft ein Service Worker nicht ununterbrochen, und Chrome etwa beendet ihn voraussichtlich nach 30 Sekunden Inaktivität.
• Distribution. Eine Web App öffnet sich per Link oder QR-Code. Native Apps werden auf Smartphones laut Google vor allem über App-Stores installiert, die festlegen, wer was veröffentlichen darf.
• Updates. Ein natives Update erfordert laut Google erneutes Paketieren, Signieren, eine Freigabe und die Installation. Solange der Nutzer es nicht installiert hat, muss Ihr Server auch mit der älteren Version umgehen können.
• Zielgruppe. Ein Mitarbeiter bekommt das Tool gestellt, ein Kunde muss erst überzeugt werden. Bei Kunden kann deshalb jeder zusätzliche Schritt einen Teil der Conversions kosten.

Kosten, die im ersten Angebot nicht auftauchen

• Entwicklung und Codebasen. Zwei native Apps und eine Webversion bedeuten drei Codebasen. Jede Funktion wird dreimal programmiert, getestet und veröffentlicht, die Versionen driften mit der Zeit auseinander, und Fehleranfälligkeit wie Supportkosten steigen.
• Die App-Store-Prüfung ist das Verfahren, in dem Apple jede App und jedes Update vor der Veröffentlichung begutachtet. Apple selbst gibt an, dass durchschnittlich 90 % der Einreichungen in weniger als 24 Stunden geprüft werden. Wichtiger als die Wartezeit ist, dass nicht Sie über die Veröffentlichung entscheiden: Nach Abschnitt 2.1 der App Review Guidelines (aktualisiert am 8. Juni 2026) lehnt Apple unvollständige und abstürzende Apps ab.
• Store-Gebühren. Provisionen betreffen den Verkauf digitaler Inhalte und digitaler Dienste und gehen direkt von der Marge ab. Abschnitt 3.1.1 dieser Richtlinien schreibt für das Freischalten von Funktionen, Inhalten oder Abonnements den Kauf innerhalb der App (In-App Purchase) vor, mit regionalen Ausnahmen. Physische Waren und Dienstleistungen, die außerhalb der App in Anspruch genommen werden, müssen dagegen auf anderem Weg bezahlt werden. Für in der EU vertriebene Apps nennt Apple in den ab dem 1. Oktober 2026 geltenden Bedingungen eine Provision von 26 % auf Verkäufe über In-App Purchase, für Mitglieder des App Store Small Business Program 15 %. Google gibt an, dass 97 % der Entwickler ihre Apps bei Google Play gebührenfrei vertreiben, und berechnet bei Transaktionen im EWR ab dem 30. Juni 2026 auf die ersten 1 Mio. USD an Jahreseinnahmen 10 % zuzüglich 5 % Gebühr für das eigene Zahlungssystem.
• Betriebssystem-Updates. Jede größere Änderung an iOS oder Android ist ein Anlass, die App zu testen und oft neu zu veröffentlichen, bei zwei nativen Apps zweimal. Tests bei neuen System- und Browserversionen bezeichnet Google auch bei PWAs als Pflicht.

PWAs in der Praxis: Was sie heute können und was nicht, vor allem auf iOS

• Installation. Laut MDN (7. September 2026) bietet der Browser die Installation nur für Websites mit Manifest, also einer Datei, die die App beschreibt, und mit gesicherter HTTPS-Verbindung an. Ein Service Worker ist keine Voraussetzung, der Offlinemodus muss also bewusst konzipiert werden. Auf Android installieren nur Chrome auf Geräten mit Google Mobile Services und Samsung Internet auf Samsung-Geräten eine PWA als vollwertige App. Andere Browser legen lediglich eine Verknüpfung an, die die Website im Browser öffnet.
• iPhone und iPad. Unter iOS 16.4 und neuer wird eine PWA laut MDN über das Teilen-Menü installiert. Einen eigenen Installationsbutton auf der Website unterstützt iOS nicht, Nutzer müssen also angeleitet werden. Unter iOS 26 und iPadOS 26 öffnet sich laut WebKit-Blog (15. September 2025) jede zum Home-Bildschirm hinzugefügte Website standardmäßig als Web App, auch ohne Manifest.
• Push-Benachrichtigungen sind Nachrichten vom Server, die das Gerät auch dann anzeigt, wenn die App nicht läuft. Apple hat am 16. Februar 2023 im WebKit-Blog angekündigt, dass iOS und iPadOS 16.4 Web Push für Web Apps bringen, die zum Home-Bildschirm hinzugefügt wurden. Push ist laut dieser Ankündigung also an diesen Schritt gebunden. Die Berechtigung darf demnach nur nach einer direkten Aktion des Nutzers angefragt werden.
• Hintergrundverarbeitung. Background Sync versucht, eine Aufgabe nach Wiederherstellung der Verbindung abzuschließen, sofern der Browser die Funktion unterstützt. Laut MDN (13. September 2026) lässt sich die Aufgabe jedoch nur bei geöffneter App registrieren, und Browser begrenzen Anzahl und Dauer der Versuche. Einen Silent Push ohne sichtbare Benachrichtigung unterstützt laut derselben Quelle kein Browser.
• App-Stores. Laut MDN lässt sich eine PWA auch für Google Play oder den App Store verpacken, Abschnitt 4.2 der Apple-Richtlinien verlangt jedoch mehr als eine neu verpackte Website.
• Regulatorisches Risiko. Laut TechCrunch (1. März 2024) hatte Apple PWAs in der EU in der Betaversion von iOS 17.4 unter Verweis auf das Gesetz über digitale Märkte (DMA) auf einfache Verknüpfungen reduziert und den Schritt nach Kritik wieder zurückgenommen. Eine Arbeitsunterlage der Dienststellen der Europäischen Kommission vom 28. April 2026 hält fest, dass Apple die Unterstützung von Web Apps auf dem Home-Bildschirm fortgeführt hat.

Unsere Einordnung: Auf iOS ist die PWA eine brauchbare Option, ihre Grenzen setzt jedoch Apple, so wie bei nativen Apps die Store-Regeln die Grenzen bestimmen. Ein Plattformrisiko trägt jede Variante.

Interne Tools versus Kunden-Apps

Anders als Kunden finden Mitarbeiter über den Prozess zum internen Tool: per Link im Intranet, über das Firmen-Login, per Lesezeichen im Browser. Das Argument, eine App müsse im Store sein, damit Menschen sie finden, entfällt hier.

Interne Tools bilden häufig Formulare, Freigaben und Übersichten ab, ohne besondere Anforderungen an die Hardware. Ausnahmen sind Lager, Außendienst oder Produktion, wo das Gerät selbst zum Arbeitsmittel wird. Eine Änderung im Web erreicht die Nutzer zudem, ohne dass ein Update installiert werden muss. Keine Plattform rettet jedoch ein Tool, das den Menschen die Arbeit erschwert, wie wir im Artikel Das teuerste System ist das, das Ihre Mitarbeiter nicht nutzen beschrieben haben.

Beispielszenarien

Die folgenden Szenarien sind hypothetisch und dienen nur dazu, die Überlegungen zu veranschaulichen.

Techniker im Außendienst

Die Techniker eines Serviceunternehmens erfassen Aufträge auch ohne Empfang. Reichen Offline-Erfassung und Synchronisierung nach Rückkehr der Verbindung aus, ist eine PWA ein sinnvoller Pilot, und Tests auf den Smartphones der Techniker zeigen, ob die Synchronisierung zuverlässig funktioniert. Benötigt das Unternehmen den Standort fortlaufend während der gesamten Schicht oder eine Bluetooth-Verbindung zu einem Messgerät, ist eine Cross-Platform-App oder native App die sicherere Wahl.

Onlineshop

Der Kunde kauft wenige Male im Jahr ein und kommt über eine Suchmaschine oder den Newsletter. Eine App würde Installation und Anmeldung vor den Kauf schieben. Mehr bringt eine Investition in die Verständlichkeit der Website, denn ein unklares Angebot löst auch eine App nicht, wie wir im Artikel Wenn Kunden Ihre Website nicht verstehen, bezahlen Sie für Traffic, den Sie nicht nutzen ausführen.

B2B-Bestellungen

Die Abnehmer eines Großhändlers bestellen regelmäßig lange Artikellisten. Entscheidend sind das schnelle Wiederholen einer Bestellung, der Import aus einer Tabelle und die Anbindung an das ERP-System, also die zentrale Unternehmenssoftware. Das leistet eine Web App, prüfen Sie aber zuerst, ob nicht das B2B-Modul des Onlineshops oder das ERP-System ausreicht, das bereits im Unternehmen vorhanden ist.

Treueprogramm

Eine Café-Kette sollte zunächst prüfen, ob ihr Kassensystem nicht bereits eine Treuefunktion bietet. Ein Mittelweg ist eine PWA mit Push-Benachrichtigungen, auf dem iPhone allerdings erst nach dem Hinzufügen zum Home-Bildschirm. Eine native App ist sinnvoll, wenn der Pilot zeigt, dass die Gäste das Programm häufig nutzen und gerade dieser Schritt sie ausbremst.

Internes Freigabe-Tool

Ein Unternehmen gibt Rechnungen und Urlaubsanträge per E-Mail frei. Zuerst gilt es, Freigabeschritte zu streichen, die nichts kontrollieren, und zu prüfen, ob ein bereits bezahltes Buchhaltungs- oder Personalsystem den Prozess abdeckt. Falls nicht, genügt eine Web App mit Firmen-Login oder gegebenenfalls eine PWA. Zwei native Apps würden hier zusätzliche Kosten für Entwicklung und Veröffentlichung verursachen, ohne dass ein Nutzen sie aufwiegt.

Der schrittweise Weg: Web, Messung, erst dann die native App

Für ein Produkt ohne klare native Anforderung empfehlen wir ein Vorgehen in Schritten:

1. Erste Version im Web oder als PWA: eine Codebasis, sofortige Updates und eine schnelle Antwort auf die Frage, ob Menschen das Produkt überhaupt wollen.
2. Messung: wie oft Nutzer zurückkehren, mit welchen Geräten, wie viele die PWA installiert haben und welche Einschränkungen sich wiederholen.
3. Vorab festgelegte Schwelle: Die Geschäftsführung definiert, welches Ergebnis eine native App rechtfertigt. Ohne diese Schwelle kehrt die Entscheidung zum Reflex zurück.
4. Native App dort, wo die Daten sie rechtfertigen, oft nur für die aktivste Nutzergruppe.

Gängige Praxis ist es, den serverseitigen Teil mit Daten und Logik abzutrennen und über eine API bereitzustellen, also eine definierte Schnittstelle für den Datenaustausch zwischen Programmen. Eine native App greift dann auf dieselben Daten und Regeln zu, und die Website bleibt ein vollwertiger Kanal, wie wir im Artikel Eine Premium-Website ist keine Frage der Ästhetik. Sie ist Vertriebsinfrastruktur erläutern. Wissen Sie jedoch von Anfang an, dass das Produkt auf einer Funktion beruht, die das Web nicht abdeckt, ist der schrittweise Weg ein unnötiger Umweg.

Wann eine native App die richtige Wahl ist

• Das Produkt beruht auf dauerhafter Hintergrundverarbeitung, etwa auf der Standortverfolgung während der gesamten Schicht. Ein Service Worker läuft laut MDN nicht ununterbrochen, deshalb reicht das Web dafür unserer Einschätzung nach nicht aus.
• Die App arbeitet tiefgehend mit Bluetooth, USB, Dateien oder Kontakten, also mit Bereichen, die Google zu den Stärken nativer Apps zählt.
• Die App ist selbst das Produkt, das Menschen täglich nutzen, und die Performance ist Teil ihres Werts.

Auch dann sollten Sie zuerst eine Cross-Platform-Entwicklung mit einer einzigen Codebasis in Betracht ziehen. Die Frage „native App oder Web App“ selbst sollten Sie erst stellen, wenn Problem, Nutzer und Umfeld präzise benannt sind.

Was Sie mitnehmen

• Ersetzen Sie den Satz „Wir brauchen eine App“ durch Fragen: Wer nutzt das Produkt, wie oft, wo und was muss das Gerät können?
• Rechnen Sie die Kosten über den gesamten Lebenszyklus: Jede native Plattform bringt eine weitere Codebasis, einen Freigabeprozess und Tests mit sich, beim Verkauf digitaler Inhalte zusätzlich die Store-Provision.
• Lassen Sie sich Aussagen zu den Fähigkeiten von PWAs mit einer datierten Quelle belegen, vor allem bei iOS, wo sich die Bedingungen seit 2023 mehrfach geändert haben.
• Starten Sie bei internen Tools mit einer Weblösung und ziehen Sie eine native App erst für Außendienst, Lager oder die Arbeit mit Hardware in Betracht.
• Vereinbaren Sie vor der ersten Version eine messbare Schwelle, die eine native App rechtfertigt.