Web-App, Mobile-App oder PWA: was passt zu deinem Produkt?

Web-App, Mobile-App oder PWA: drei Wege, ein Produkt

Wenn du ein digitales Produkt baust, steht früh eine Frage im Raum, die später teuer wird, wenn man sie falsch beantwortet: Läuft das Ding im Browser, im App-Store oder irgendwo dazwischen? Die drei Optionen heissen Web-App, native Mobile-App und Progressive Web App, kurz PWA. Sie klingen ähnlich, verhalten sich aber im Betrieb sehr verschieden. Bevor wir vergleichen, definieren wir sie sauber, denn die Begriffe werden im Alltag wild durcheinandergeworfen.

Eine Web-App ist eine Anwendung, die in jedem Browser läuft. Du tippst eine Adresse ein oder klickst einen Link, und schon bist du drin, ohne Installation. Gmail, Notion im Browser, dein Online-Banking: alles Web-Apps. Eine native Mobile-App lädst du aus dem App-Store von Apple oder Google herunter, sie wird auf dem Telefon installiert und ist für iOS oder Android in der jeweiligen Plattformsprache gebaut. Eine PWA schliesslich ist technisch eine Web-App, die sich wie eine installierte App benimmt: Sie bekommt ein Icon auf dem Homescreen, kann eingeschränkt offline arbeiten und in vielen Fällen Push-Nachrichten schicken. Sie ist die Brücke zwischen den beiden Welten.

Wie und wo deine Nutzer das Produkt wirklich verwenden

Die nützlichste Ausgangsfrage ist nicht technisch, sondern situativ: In welchem Moment greift jemand zu deinem Produkt? Ein Werkzeug, das im Büro am grossen Bildschirm bedient wird, lange Tabellen, viele Felder, Tastatur und Maus, ist im Browser zu Hause. Eine App, die jemand zwischen zwei Terminen am Telefon antippt, schnell, einhändig, mit dem Daumen, lebt auf dem Mobilgerät.

Ein Beispiel aus unserer eigenen Werkstatt: Wortfreunde, unsere Lern-App, wird typischerweise unterwegs benutzt, in kurzen Einheiten, oft ohne stabiles Netz im Zug. Da zählt der schnelle Zugriff vom Homescreen und das Gefühl einer richtigen App. Reazon dagegen, unser CMS, ist ein Arbeitswerkzeug für konzentriertes Schreiben und Strukturieren am Schreibtisch. Browser, grosser Screen, fertig. Zwei Produkte aus demselben Haus, zwei verschiedene Antworten, weil die Nutzungssituation verschieden ist. Frag also zuerst nach dem Moment der Nutzung, nicht nach der Technik.

Reichweite: wer dich findet und wie schnell

Reichweite entscheidet sich an der Hürde zwischen Interesse und Nutzung. Im Web ist diese Hürde minimal. Ein Link in einer E-Mail, ein Suchergebnis bei Google, ein QR-Code auf einem Plakat: ein Klick, und die Person ist im Produkt. Nichts wird installiert, nichts blockiert. Genau deshalb sind Web-Apps so stark für alles, was über Suche und Inhalte gefunden werden soll. Eine Mobile-App taucht in einer Google-Suche nach deinem Thema schlicht nicht auf.

Die native App verlangt einen bewussten Entschluss: in den Store gehen, suchen, herunterladen, Berechtigungen bestätigen. Jeder dieser Schritte kostet Leute. Dafür belohnt der installierte Zustand mit Bindung. Das Icon liegt auf dem Homescreen, es ist präsent, es wird wieder geöffnet. Web gewinnt bei der ersten Begegnung, native gewinnt bei der Wiederkehr. Die PWA versucht beides: über den Browser gefunden, dann mit einem Tipp installiert, ohne Umweg über den Store. Das funktioniert auf Android sehr gut, auf iOS mit Einschränkungen, weil Apple PWAs weniger Spielraum gibt.

Offline und Push: die zwei Gründe, die wirklich zählen

Wenn jemand auf einer nativen App besteht, stecken meist zwei konkrete Anforderungen dahinter: Offline-Fähigkeit und Push-Benachrichtigungen. Lohnt sich, diese genau anzuschauen, statt sie als Pauschalargument zu schlucken.

Offline heisst, dass dein Produkt ohne Netz weiterläuft. Native Apps können das umfassend, Daten lokal speichern, später synchronisieren. Eine PWA kann einen guten Teil davon auch, über sogenannte Service Worker, kleine Skripte im Browser, die Inhalte zwischenspeichern. Für viele Fälle, etwa eine Lese-App oder ein Formular, das auch ohne Verbindung funktionieren soll, reicht das. Echte, komplexe Offline-Logik mit grossen lokalen Datenbeständen bleibt die Domäne nativer Apps.

Push sind die Mitteilungen, die auf dem Sperrbildschirm aufpoppen. Native Apps beherrschen sie auf beiden Plattformen zuverlässig. PWAs können Push auf Android, und seit einigen iOS-Versionen eingeschränkt auch dort, sofern die PWA installiert ist. Wenn Push der Kern deines Geschäftsmodells ist, eine Messaging-App, ein zeitkritischer Alarmdienst, ist native ein starkes Argument. Wenn Push nur nett wäre, ist es kein Grund, den ganzen Aufwand einer nativen App zu rechtfertigen. Diese Unterscheidung zwischen Muss und Nett-zu-haben spart oft ein halbes Projekt.

App-Store: Tor und Türsteher zugleich

Der App-Store ist Schaufenster und Hürde in einem. Auf der Habenseite: Sichtbarkeit in einem Laden, den Millionen täglich öffnen, plus ein Vertrauensvorschuss durch die Plattform. Auf der Sollseite steht ein Apparat, der Pflege verlangt. Jede Veröffentlichung läuft durch ein Review, das Tage dauern kann und gelegentlich abgelehnt wird. Apple und Google nehmen bei In-App-Käufen eine Provision. Du bindest dich an Plattformregeln, die sich ändern, ohne dich zu fragen.

Für die meisten B2B- und KMU-Produkte ist der Store weder nötig noch hilfreich. Eine interne Anwendung, ein Branchenwerkzeug, ein Kundenportal, das alles braucht keinen Store-Eintrag, sondern einen Link. Wer dagegen ein Konsumentenprodukt baut, das über App-Store-Discovery wachsen soll, kommt an den Stores schwer vorbei. Die Frage lautet also: Ist der Store dein Vertriebskanal oder nur ein zusätzlicher Wartungsposten? Wie du den ersten Produktkern überhaupt zuschneidest, behandeln wir in Welche Funktion gehört in den Produktkern.

Kosten und Wartung: warum native doppelt rechnet

Kosten lassen sich ohne erfundene Beträge erklären, wenn man die Treiber benennt. Der grösste Treiber bei nativen Apps ist die Vervielfachung: iOS und Android sind zwei getrennte Plattformen mit eigenen Sprachen, Werkzeugen und Eigenheiten. Im klassischen Fall baust und pflegst du dein Produkt zweimal, plus oft noch ein Web-Backend dazu. Cross-Platform-Frameworks lindern das, lösen es aber nicht vollständig, weil Plattformbesonderheiten durchschlagen.

Eine Web-App baust du einmal, und sie läuft überall, wo ein Browser ist. Das ist der Kern des Kostenvorteils. Eine PWA erbt diesen Vorteil und legt eine dünne Schicht für Installierbarkeit und Offline obendrauf. Bei native zahlst du nicht nur den Bau doppelt, sondern auch die Wartung dauerhaft. Betriebssystem-Updates von Apple und Google zwingen dich regelmässig zu Anpassungen, sonst fliegt deine App irgendwann aus dem Store. Diese laufenden Kosten unterschätzen viele am Anfang gründlich. Was Software nach dem Start kostet, dröseln wir in Warum Software nach dem Launch teuer wird auf.

Und weil wir nicht nur bauen, sondern unsere Produkte auch selbst betreiben, wissen wir aus eigener Erfahrung: Der teure Teil kommt nach dem Launch, nicht davor. Jede zusätzliche Plattform ist eine zusätzliche Front, die du auf Dauer offen hältst.

Warum der Start im Web meistens die ruhigste Wahl ist

Für einen grossen Teil der Produkte, die wir sehen, ist Web-zuerst der vernünftige Weg, und das aus mehreren ineinandergreifenden Gründen. Du erreichst alle Geräte mit einer Codebasis. Du hast keine Store-Hürde zwischen dir und dem ersten Nutzer. Du kannst täglich ausliefern, ohne auf ein Review zu warten, was beim Lernen am frühen Produkt Gold wert ist. Und du hältst die laufenden Kosten niedrig, solange du noch nicht weisst, was wirklich gebraucht wird.

Der elegante Zwischenschritt heisst PWA. Du baust deine Web-App so, dass sie sich installieren lässt, ein Homescreen-Icon bekommt und das Nötigste offline kann. Damit deckst du einen grossen Teil der App-Erwartung ab, ohne in zwei native Codebasen einzusteigen. Wenn dann echte Nutzung zeigt, dass dir genau eine Plattformfähigkeit fehlt, die nur nativ geht, baust du gezielt nach. Diese Reihenfolge, erst Web, dann bei Bedarf nativ, ist die gleiche Logik, die hinter einem schlanken Start steht. Wenn dich diese Denkweise interessiert, lies Was kostet ein MVP.

Wer von Anfang an Klarheit über die richtige Architektur braucht und das Produkt nicht nur bauen, sondern auch betreiben lassen will, findet in unserer SaaS-Produktentwicklung den passenden Rahmen.

Wann Web-zuerst die falsche Antwort ist

Damit das kein einseitiges Plädoyer wird: Es gibt klare Fälle, in denen du direkt nativ bauen solltest, und an denen würde dich ein Web-Start nur Zeit kosten.

Wenn dein Produkt tief in die Hardware greift, dauerhafte Hintergrundprozesse braucht, präzisen Zugriff auf Sensoren, Kamera in Spezialmodi, Bluetooth-Geräte oder rechenintensive Verarbeitung direkt auf dem Gerät, dann stösst das Web an Grenzen. Eine Fitness-App, die rund um die Uhr Bewegung trackt, ein Spiel mit hohen Grafikanforderungen, ein Werkzeug, das eng mit Spezialhardware spricht: dafür ist nativ gebaut. Auch wenn dein gesamtes Geschäftsmodell auf zuverlässigem Push und tiefer Geräteintegration steht, passt der native Weg von Anfang an besser zu deinen Anforderungen.

Und wenn deine Zielgruppe Apps ausschliesslich über den App-Store sucht und installiert, etwa bei reinen Endkundenprodukten in bestimmten Segmenten, dann ist der Store kein Wartungsposten, sondern dein Marktplatz. In dem Fall führt der Umweg über Web nur dazu, dass du am eigentlichen Vertriebskanal vorbeiarbeitest. Der naheliegende Einwand lautet hier: Verbrenne ich nicht Zeit, wenn ich erst Web baue und später doch nativ muss? Die Antwort hängt an der Wahrscheinlichkeit. Ist nativ sicher und absehbar nötig, bau es direkt. Ist es nur möglich, gewinnst du mit Web-zuerst Geschwindigkeit und Lernen, und das verlorene Stück Arbeit ist klein gegen die Erkenntnis, die du dir damit kaufst.

Die Entscheidung in einem Satz

Wähle nach Nutzungssituation, Reichweite und den zwei harten Kriterien Offline und Push, nicht nach dem Bauchgefühl, dass eine richtige App sich seriöser anfühlt. Für die meisten Produkte heisst die belastbare Reihenfolge: Web-App bauen, als PWA installierbar machen, nativ nur dort nachlegen, wo eine konkrete Plattformfähigkeit es zwingend verlangt. So hältst du die Kosten klein, lernst schnell und behältst dir alle Türen offen, statt am ersten Tag eine teure zuzuschlagen.