Die Frage „Web-App oder native App?" wird meist mit Technologieargumenten beantwortet und sollte mit Vertriebsargumenten beantwortet werden. Vier Kriterien entscheiden — in dieser Reihenfolge.
Die drei Optionen
| Web-App | PWA | Native App | |
|---|---|---|---|
| Verteilung | URL | URL + Installation | App Store |
| Gerätezugriff | minimal | mittel | vollständig |
| Offline | nein | begrenzt | vollständig |
| Aktualisierung | sofort | sofort | Store-Prüfung |
| Relative Kosten | 1× | 1,2× | 2–3× |
| Auffindbarkeit | Store + Google |
Kriterium 1: Welchen Gerätezugriff brauchen Sie?
Das ist der einzige Punkt, der eine Option hart ausschließt.
Nur nativ möglich: dauerhafte Hintergrundverarbeitung, Bluetooth-Geräte, Health-Daten, präzise Standortverfolgung im Hintergrund, Widgets, Live Activities, systemweite Freigabe-Dialoge, verlässliche Push-Nachrichten auf iOS.
Im Browser ausreichend: Kamera für Fotos, Standort bei aktiver Nutzung, Datei-Upload, einfache Benachrichtigungen auf Android.
Wenn Ihre Kernfunktion in der ersten Liste steht, ist die Entscheidung gefallen — alles Weitere ist dann nur noch die Frage, ob nativ oder cross-platform. Die steht in Was kostet App-Entwicklung 2026?.
Kriterium 2: Wie finden Nutzer Sie?
Hier wird es interessant, weil beide Antworten Nachteile haben.
Über den Store: Sie gewinnen einen eigenen Entdeckungskanal und das Symbol auf dem Startbildschirm — den wertvollsten Platz, den es gibt. Sie verlieren Kontrolle: Jede Aktualisierung braucht eine Prüfung, digitale Verkäufe kosten 15–30 % Provision, und die Regeln ändern sich ohne Ihr Zutun.
Über eine URL: Sie aktualisieren sofort, zahlen keine Provision und werden über Suchmaschinen gefunden. Sie verlieren den Store als Entdeckungsweg — und die Installation auf dem Startbildschirm passiert nur, wenn Sie den Nutzer aktiv dazu bringen.
Faustregel: Nutzen Sie den Store, wenn Wiederkehr die Kernmechanik ist. Bleiben Sie im Web, wenn der Zugang so reibungslos wie möglich sein muss — etwa bei einem Werkzeug, das ein Kunde einmal im Quartal aufruft.
Kriterium 3: Was passiert offline?
- Gar nichts nötig → Web-App reicht
- Lesen ja, schreiben nein → PWA reicht
- Vollständig arbeiten, später synchronisieren → nativ
Der dritte Fall wird regelmäßig unterschätzt. Offline-First heißt nicht „Daten zwischenspeichern", sondern Konfliktauflösung: Was passiert, wenn zwei Geräte denselben Datensatz offline ändern? Diese Logik ist der teuerste Teil und im Browser kaum verlässlich zu bauen.
Kriterium 4: Budget und Team
Eine Web-App ist eine Codebasis, ein Deployment, kein Store-Prozess. Eine native App für beide Plattformen ist zwei Zielsysteme, zwei Freigabeprozesse und zwei Sätze Systemregeln — auch wenn der Code geteilt ist.
Was Sie mit der Web-App aufgeben: Sie bauen später möglicherweise doch nativ und haben dann zwei Clients zu pflegen. Das ist beherrschbar, wenn das Backend von Anfang an ein eigenes API hat — und ein Problem, wenn die Logik im Frontend steckt.
Die iOS-Einschränkung, die den Ausschlag gibt
PWAs sind auf Android nahezu gleichwertig. Auf iOS nicht:
- viele Sensoren und Bluetooth bleiben unzugänglich
- Hintergrundverarbeitung ist stark limitiert
- lokaler Speicher kann vom System geräumt werden, wenn die App länger ungenutzt bleibt
- Push funktioniert nur bei zum Startbildschirm hinzugefügten PWAs — ein Schritt, den die meisten Nutzer nie machen
Wenn ein relevanter Teil Ihrer Zielgruppe auf iOS ist und Sie auf Benachrichtigungen angewiesen sind, ist die PWA praktisch keine Option.
Drei Fälle aus der Praxis
Ein Werkzeug für Außendienstmitarbeiter. Erste Vermutung: native App, weil „die Leute sind unterwegs". Tatsächlich entscheidend war, dass Aufträge im Funkloch bearbeitet und später übertragen werden mussten — Offline-Schreiben mit Konfliktauflösung. Das ist der eine Fall, in dem nativ ohne Alternative ist. Die Entscheidung fiel nicht wegen der Mobilität, sondern wegen des Netzes.
Ein Buchungsportal für Endkunden. Nutzung: zwei- bis dreimal im Jahr. Eine native App hätte bedeutet, dass jeder Kunde vor der Buchung eine Installation akzeptiert — bei dieser Frequenz ein Abbruchgrund. Web-App, gefunden über Suchmaschinen. Der Store hätte hier nichts hinzugefügt, außer Reibung.
Eine interne Auswertungsoberfläche. Web-App, ohne Diskussion. Kein Gerätezugriff, kein Offline-Bedarf, tägliche Aktualisierungen erwünscht. Nativ wäre hier reine Verschwendung gewesen — inklusive eines Freigabeprozesses für jede Änderung an einer Tabelle.
Das Muster: In allen drei Fällen war die Entscheidung nicht technisch, sondern eine Aussage über Nutzungsfrequenz und Netzsituation.
Der Weg, den wir am häufigsten empfehlen
Web-App zuerst, native App später — mit sauberem Backend von Anfang an.
Die Web-App validiert das Produkt schnell und günstig. Wenn sich Nutzung und Wiederkehr zeigen, kommt die native App als zweiter Client desselben APIs dazu. Voraussetzung ist, dass die Geschäftslogik im Backend liegt und nicht im Frontend — siehe API-Integration.
Wann dieser Weg falsch ist: wenn die Kernfunktion nativen Zugriff braucht. Dann bauen Sie die Web-App und werfen sie weg.
Was die Entscheidung für SEO bedeutet
Ein Punkt, der in dieser Abwägung fast immer fehlt: Eine native App ist für Suchmaschinen unsichtbar. Ihre Inhalte tauchen nicht in Suchergebnissen auf, und sie lassen sich nicht verlinken — jeder Zugang läuft über den Store oder über Werbung.
Bei einem Produkt, dessen Nutzer über eine Suche einsteigen (Vergleichen, Nachschlagen, Recherchieren), ist das ein struktureller Nachteil, der sich mit Budget nur teuer ausgleichen lässt. Bei einem Produkt, das nach der ersten Installation täglich geöffnet wird, spielt es keine Rolle.
Der übliche Ausweg ist beides: Inhalte im Web, Nutzung in der App — mit Verweisen aus dem Web in die App. Das kostet zusätzlich, ist aber die einzige Konstruktion, die beide Kanäle bedient. Wie die Web-Seite dafür technisch aufgestellt sein muss, steht in unserer technischen SEO-Checkliste.
Einordnung in einer Minute
- Braucht die Kernfunktion nativen Gerätezugriff? → nativ
- Ist es ein internes Werkzeug ohne Offline-Anspruch? → Web-App
- Endkundenprodukt, tägliche Nutzung, iOS relevant? → nativ
- Endkundenprodukt, gelegentliche Nutzung, reibungsloser Zugang wichtig? → PWA
- Unsicher und Budget begrenzt? → Web-App mit eigenem Backend, nativ nachrüsten
Wie wir Web-Plattformen aufsetzen, steht auf unserer Seite zur Webentwicklung; den mobilen Teil beschreibt Mobile-App-Entwicklung.
Wenn Sie zwischen zwei dieser Optionen stehen: Schildern Sie uns den Anwendungsfall — Sie bekommen innerhalb von 48 Stunden eine Einordnung mit Begründung, auch wenn sie gegen das größere Projekt ausfällt.