Sie wollen eine mobile App, wissen aber nicht, ob es sich lohnt, Monate in die Entwicklung für iOS und Android zu investieren, oder ob eine Progressive Web App ausreicht. Das ist eine Frage, vor der jedes Unternehmen und jeder Solodeveloper steht.
Spoiler: Für viele Projekte ist eine PWA schneller, günstiger und völlig ausreichend, aber es gibt Szenarien, in denen man ohne eine native App nicht auskommt.
⚡ Kurz gefasst
- ✅ PWA ist eine Website mit App-Funktionen: Startbildschirm-Installation, Offline-Modus, Push-Benachrichtigungen, ganz ohne Store-Zwang.
- ✅ Native App bedeutet maximale Performance: Voller Gerätezugriff, AR, Bluetooth, Biometrie.
- ✅ PWA-Entwicklungskosten sind meist um ein Vielfaches niedriger: Ein Code statt zwei oder drei.
- ⚠️ Der Hauptnachteil von PWA sind iOS und Auffindbarkeit: Keine automatische Installation, und Nutzer finden das Produkt über Suche und Links statt über Stores. Wie Sie das lösen, lesen Sie im Artikel So bewerben Sie eine PWA: SEO, Indexierung und Installation.
- 🎯 Was Sie erwartet: Eine Vergleichstabelle, Entscheidungsszenarien, ein Überblick über iOS-Einschränkungen, Wege in die Stores, Kosten sowie ein echter Case von Kazki AI.
📚 Inhaltsverzeichnis
🎯 Abschnitt 1. Was sind PWA und native Apps: Kurz gefasst
Das sind zwei Ansätze für eine mobile App. Eine PWA ist eine Website, die sich wie eine App verhält, während eine native App separat für iOS oder Android mit vollem Gerätezugriff geschrieben wird.
Eine PWA ist, wenn eine Website zur App wird. Native ist, wenn eine App ab der ersten Codezeile eine App ist.
Progressive Web App (PWA)
Eine PWA basiert auf Standard-Webtechnologien: HTML, CSS, JavaScript. Dank Service Worker und Web App Manifest erhält sie Funktionen, die früher nur nativen Apps vorbehalten waren: Installation auf dem Startbildschirm, Offline-Modus und Push-Benachrichtigungen. Nach der Installation öffnet sich die PWA im Vollbildmodus, ohne Adressleiste und mit eigenem Icon. Technologie, Architektur und die Schritt-für-Schritt-Erstellung habe ich im Artikel Progressive Web Apps (PWA): Der komplette Leitfaden für Business und Entwickler behandelt.
Native App
Eine native App wird für jede Plattform separat erstellt: Swift oder SwiftUI für iOS, Kotlin oder Jetpack Compose für Android. Sie wird aus dem App Store oder Google Play heruntergeladen und hat vollen Zugriff auf Kamera, GPS, Bluetooth, Biometrie und das Dateisystem. Es gibt auch plattformübergreifende Lösungen (Flutter, React Native), die jedoch trotzdem einen separaten Build und eine Veröffentlichung in Stores erfordern.
🎯 Abschnitt 2. PWA vs. Native: Vergleich anhand von 12 Kriterien
PWA gewinnt bei Kosten, Launch-Geschwindigkeit, Updates und Zugänglichkeit. Native gewinnt bei Performance, Gerätezugriff und Store-Präsenz. Die Wahl hängt nicht davon ab, welche Technologie „besser“ ist, sondern von den Anforderungen des Produkts.
| Kriterium | PWA | Native App |
|---|
| Entwicklungskosten | Gering: Ein Code für alle Plattformen. Wenn bereits eine Website existiert, lässt sich eine PWA mit minimalem Budget ergänzen | Hoch: Separater Code für iOS und Android oder Cross-Platform mit eigenen Einschränkungen |
| MVP-Entwicklungszeit | Von wenigen Tagen (bei bestehender Website) bis zu wenigen Wochen | Normalerweise Monate, selbst mit Cross-Platform |
| Installation | Über den Browser, ohne Store. Unter Android gibt es eine Installationsaufforderung, unter iOS nur manuell über „Teilen → Zum Home-Bildschirm“ | Über App Store oder Google Play: Account, Moderation, Richtlinienkonformität |
| Updates | Beim nächsten Öffnen, ohne Benutzeraktion | Über den Store: Moderation und Benutzer-Update oder automatisches Update |
| Offline-Modus | Ja, über Service Worker. Der Speicher unter iOS kann gelöscht werden, daher sollten kritische Daten auf dem Server gehalten werden | Ja, volle Kontrolle über lokale Datenbanken |
| Push-Benachrichtigungen | Android: Volle Unterstützung. iOS: Seit 16.4, nur für PWAs auf dem Startbildschirm | Volle Unterstützung auf beiden Plattformen über APNs und FCM |
| Performance | Ausreichend für Content, E-Commerce, SaaS, Medien | Maximal: Direkter GPU-Zugriff, kritisch für Spiele, Video, AR |
| Gerätezugriff | Kamera, Mikrofon, GPS, Vibration. Kein NFC, ARKit, HealthKit; Bluetooth nur in Chromium | Vollständig: Bluetooth, NFC, AR, Biometrie, HealthKit, Siri |
| SEO und Auffindbarkeit | Öffentliche Seiten werden von Google indexiert, jedoch nur bei korrektem Rendering und URLs. Details im Artikel SEO für PWAs: Wie Nutzer Ihre App finden | Store-Suche (ASO), Google indexiert App-Store-Seiten nicht wie eine Website |
| Größe | Shell-Cache im Bereich weniger Megabyte, der Rest wird bei Bedarf nachgeladen | Dutzende bis Hunderte Megabyte |
| Plattformprovision | 0 % Store-Gebühr: Zahlungen über Ihr eigenes Gateway (Stripe, LiqPay, Mono) | 15–30 % bei In-App-Käufen je nach Bedingungen |
| Zielgruppe und Erreichbarkeit | Jeder mit einem Browser: Ein Link und der Nutzer ist in der App | Nur diejenigen, die die App im Store finden, herunterladen und öffnen |
Diese Tabelle ist eine Orientierungshilfe, kein Urteil. Für das eine Projekt ist das Fehlen der 30%-Provision ausschlaggebend, für ein anderes ist der Bluetooth-Zugriff wichtiger als jede Einsparung.
🎯 Abschnitt 3. Wann eine PWA die richtige Wahl ist
Ich empfehle Kunden, PWAs für Content-, Service- und kommerzielle Projekte in Betracht zu ziehen, bei denen die Hauptinteraktion über Text, Bilder und Audio stattfindet. Dieser Ansatz kann im Vergleich zur Entwicklung separater nativer Apps Zeit und Kosten beim Launch einsparen und gleichzeitig den Browserzugriff sowie die Möglichkeit der Installation auf dem Gerät beibehalten.
Wenn ein Benutzer alle erforderlichen Aktionen über den Browser ausführen kann, empfehle ich, zuerst eine PWA zu evaluieren – bevor man in separate native Apps investiert.
Szenario 1. Startup oder Solodeveloper mit begrenztem Budget
Die klassische Startup-Falle: Ein halbes Jahr in native Apps für zwei Plattformen investieren, nur um festzustellen, dass die Idee nicht funktioniert. Eine PWA liefert ein mobiles Erlebnis in Tagen und Wochen und gibt Ihnen Zeit, die Idee zu validieren. Hinzu kommen Einsparungen: Kein Mac für den iOS-Build und keine separate CI/CD für mobile Plattformen erforderlich, und ein Entwicklerkonto wird nur dann benötigt, wenn Sie in die Stores gehen.
Szenario 2. Content-Apps (Nachrichten, Blog, Medien, Audio)
Jeder Artikel oder jede Episode hat eine eigene URL, die Google in den Suchergebnissen anzeigen kann, und der Service Worker bietet schnellen Zugriff sowie Offline-Lesbarkeit. Dies ist ein einzigartiger Vorteil gegenüber nativem Code, allerdings unter einer Bedingung: Die Seiten müssen als fertiges HTML ausgeliefert und nicht nur per Skript auf dem Client gerendert werden. Wie das geht, habe ich im Artikel So bewerben Sie eine PWA: SEO, Indexierung und Installation beschrieben.
Szenario 3. E-Commerce, Kataloge und Marktplätze
Hier beseitigt eine PWA die Hürde „Herunterladen → Registrieren → erst dann Produkte ansehen“: Der Nutzer kommt über Werbung oder Social Media und sieht sofort den Katalog. Zahlungen erfolgen direkt ohne Store-Provision, was für margenschwache Unternehmen ausschlaggebend sein kann.
Szenario 4. Interterne Unternehmens-Tools
CRMs, Dashboards und Task-Tracker benötigen keinen App Store. Eine einzige App läuft auf Smartphones, Tablets und Desktops, aktualisiert sich für alle sofort und erfordert keine IT-Verwaltung für die Installation auf jedem einzelnen Gerät.
🎯 Abschnitt 4. Wann eine native App die einzige Option ist
Nativ wird benötigt, wenn ein Produkt von Hardware, komplexer Grafik, zuverlässiger Hintergrundverarbeitung oder strengen Sicherheitsanforderungen abhängt.
Wenn eine App ohne AR-Kamera, Bluetooth-Sensoren oder 60-FPS-Grafik nicht funktionieren kann, ist das natives Terrain.
Szenario 1. Spiele und schwere Echtzeitgrafik
3D-Spiele, AR und Videobearbeitungsprogramme erfordern direkten GPU-Zugriff (Metal, Vulkan) und ein feines Speichermanagement. WebGPU schließt diese Lücke, aber für Produktionsspiele mit schwerer Grafik bleibt nativ die Hauptoption.
Szenario 2. IoT, Bluetooth und externe Geräte
Fitness-Tracker, medizinische Geräte und Smart Home funktionieren über BLE, NFC oder USB. Web Bluetooth funktioniert nur in Chromium und fehlt unter iOS. Die Integration mit HealthKit und Health Connect ist ausschließlich über native APIs möglich.
Szenario 3. Hintergrundprozesse und tiefe BS-Integration
GPS-Navigation im Hintergrund, Musikplayer mit Sperrbildschirm-Steuerung, VoIP und Messenger mit zuverlässiger Zustellung. Service Worker sind nicht für langfristige Hintergrundaufgaben ausgelegt, und das Betriebssystem kann eine PWA nach dem Minimieren beenden.
Szenario 4. Sicherheit und Compliance
Bank- und Zahlungs-Apps, medizinische und staatliche Anwendungen profitieren von Keychain und Keystore, Biometrie mit vollständiger API, Screenshot-Schutz und Certificate Pinning. Für Audits wie PCI DSS oder HIPAA ist eine native App in der Regel leichter zu rechtfertigen.
Die Präsenz im Store als strategische Geschäftsanforderung (Vertrauen, Bewertungen, eine Zielgruppe, die ausschließlich in Stores sucht) wird in Abschnitt 6 behandelt.
🎯 Abschnitt 5. PWA-Einschränkungen unter iOS im Jahr 2026
iOS bleibt die größte Schwachstelle von PWAs. Es gibt keine automatische Installationsaufforderung, Push ist nur für PWAs auf dem Startbildschirm verfügbar, und Apple verspricht keine vollständige Parität mit Android.
Android behandelt PWAs wie vollwertige Bürger, iOS wie Gäste mit eingeschränkten Rechten.
Dies ist der wichtigste Entscheidungsfaktor, wenn sich Ihre Zielgruppe überwiegend auf dem iPhone befindet. Die aktuelle Situation:
- Keine automatische Installationsaufforderung. Unter Android schlägt Chrome die PWA-Installation von sich aus vor, während der Nutzer unter iOS von „Teilen → Zum Home-Bildschirm“ wissen muss. Daher ist ein eigener UI-Hinweis erforderlich.
- Push funktioniert ab iOS 16.4, aber nur für installierte PWAs. Die Berechtigung wird nach einer Benutzeraktion (Schaltfläche) und nicht beim Laden der Seite angefragt. Schritt-für-Schritt-Code und typische Fehler werden im Artikel PWA-Push-Benachrichtigungen unter iOS im Jahr 2026: Was wirklich funktioniert analysiert.
- Speicher kann gelöscht werden. Safari verfügt über Richtlinien zum Löschen von Site-Daten, wenn ein Nutzer eine Site längere Zeit nicht geöffnet hat. Bewahren Sie kritische Daten auf dem Server auf und betrachten Sie den Cache als temporär.
- Engine. In den meisten Regionen laufen alle Browser auf dem iPhone auf WebKit, sodass die Einschränkungen von Safari auch für Chrome und Firefox gelten. In der EU sieht die Situation durch den Digital Markets Act anders aus.
- EU. Apple hatte zunächst angekündigt, Home-Screen-Web-Apps in der EU mit iOS 17.4 zu entfernen, diese Entscheidung dann jedoch rückgängig gemacht und sie beibehalten. Für ein europäisches Publikum sollten Sie den aktuellen Status auf der Apple-Seite prüfen, anstatt sich auf alte Nachrichten zu verlassen.
iOS-Einschränkungen sind nur ein Teil der Herausforderungen. Typische Integrationsfehler (Caching, Analytics, Updates) mitsamt Code habe ich im Artikel 8 kritische Fehler bei der PWA-Integration behandelt.
🎯 Abschnitt 6. Hybridansatz und Distribution: PWA, TWA, Wrapper, Suche
Ich empfehle Kunden die Strategie „Launch → Validierung → Skalierung“. Starten Sie zuerst eine PWA, prüfen Sie Nachfrage und Nutzerverhalten und entscheiden Sie erst danach, ob separate native Apps im App Store und Google Play erforderlich sind. Berücksichtigen Sie dabei jedoch, dass eine PWA keine automatische Sichtbarkeit über ein Store-Schaufenster besitzt, weshalb die Akquisekanäle im Voraus geplant werden müssen.
Ich rate davon ab, Monate in die Entwicklung einer nativen App zu investieren, solange Sie die Nachfrage nach dem Produkt selbst nicht validiert haben.
In der ersten Phase erstellen Sie eine Web-App mit PWA-Funktionen und sammeln Feedback sowie Analytics. Sobald das Produkt seinen Wert unter Beweis gestellt hat, verfügen Sie über Daten für die Entscheidung: Werden Funktionen benötigt, die eine PWA nicht bietet, fordern Nutzer eine Store-Präsenz oder ist das Budget für mehrere Codebasen vorhanden?
Wie eine PWA in die Stores gelangt
| Weg | Wie es funktioniert | Worauf zu achten ist |
|---|
| Nur Web | Nutzer finden sie über Suche, Links, Kataloge, QR | SEO und durchdachte Installation erforderlich (siehe unten) |
| Google Play via TWA | PWA in einer Chrome-Hülle, ohne nativen Code. Wird über Bubblewrap oder PWABuilder erstellt | Domänenverknüpfung erforderlich; prüfen Sie die aktuellen Play-Console-Anforderungen für neue Konten |
| App Store via Wrapper | Ein WebView-Wrapper wie Capacitor | Gemäß Leitlinie 4.2 kann Apple Apps ohne echten nativen Mehrwert über die Website hinaus ablehnen; native Funktionen sind erforderlich |
| Microsoft Store | Verpackung über PWABuilder | Einfacher als andere, aber das Publikum ist kleiner |
Warum „im Store sein“ nicht dasselbe ist wie „gefunden werden“
Bei einer nativen App fungiert der Store als Suchmaschine, Schaufenster und Installationskanal. Eine PWA hat diesen Trichter nicht: Sie wird über Google, Links, Kataloge und soziale Netzwerke gefunden, und die Installation führt der Nutzer selbst durch. Daher werden eine öffentliche Produktseite, korrektes Rendering, namensbasierte Suche, Kataloge, Installationshinweise und Push-Nachricht zur Nutzerbindung zu einem Teil der Strategie und sind kein „Zusatz“. All dies habe ich Schritt für Schritt mit Code und Checkliste im Artikel So bewerben Sie eine PWA: SEO, Indexierung und Installation beschrieben.
Die Veröffentlichung im Store fügt einen Kanal und Vertrauen hinzu, bringt jedoch Provisionen, Moderation und ein separates Support-Paket mit sich. Wenn die Zielgruppe über Google zu einem bestimmten Zweck kommt, ist der Store möglicherweise überflüssig. Einige Zielgruppen (vor allem iOS-Nutzer in den USA und Europa) suchen Apps ausschließlich im App Store, und für sie bedeutet das Fehlen dort, dass das Produkt nicht existiert.
🎯 Abschnitt 7. Echter Case: Was PWA für Kazki AI gebracht hat
Für Kazki AI habe ich mich für eine PWA entschieden, wodurch ein Launch innerhalb weniger Wochen mit einer einzigen Codebasis möglich war. Die Hauptvorteile waren Iterationsgeschwindigkeit und SEO, der Hauptnachteil war iOS.
Wenn man allein ist, zählt jede Entwicklungswoche. Die PWA hat mir eine App ohne App-Kosten beschert.
Kazki AI ist ein personalisierter Audio-Märchen-Service für Kinder: Das Kind wird zum Helden eines Märchens, KI generiert einen Text mit seinem Namen und vertont ihn auf Ukrainisch. Tech-Stack: Spring Boot, Thymeleaf, Tailwind CSS, PostgreSQL, Redis, ElevenLabs für die Sprachausgabe. Das Projekt wurde eingestellt, aber die Erfahrung bleibt wertvoll.
Als Nutzer nach einer mobilen App fragten, schätzte ich den Arbeitsaufwand für die native Entwicklung ab. Selbst mit einem plattformübergreifenden Ansatz sind das mindestens 2–3 Monate Arbeit, und für ein vollwertiges Projekt werden möglicherweise Entwickler, Tester und separate Ressourcen für die Unterstützung von iOS und Android benötigt. Zusätzlich müssen ein Apple Developer Account, ein Mac für den iOS-App-Build und das Bestehen der Store-Moderation berücksichtigt werden, was eine Veröffentlichung beim ersten Versuch nicht garantiert.
Stattdessen fügte ich die PWA-Unterstützung innerhalb von 4–6 Tagen hinzu: Ich erstellte eine manifest.json mit App-Beschreibung, konfigurierte sw.js für das Caching statischer Assets und registrierte den Service Worker in Templates. Unter Android konnten Nutzer die Website zum Startbildschirm hinzufügen, und nach dem Start öffnete sich die PWA in einem Fenster ohne die übliche Adressleiste. Das Caching half zudem dabei, bereits auf dem Gerät gespeicherte Ressourcen schneller zu laden.
Was die Entscheidung zugunsten von PWA besiegelt hat
- Inhaltstyp. Text und Audio, ohne Bluetooth, AR oder komplexe Grafik. Der Browser gibt Audio hervorragend wieder, native Funktionen hätten hier keinen Mehrwert gebracht.
- SEO. Ein erheblicher Teil der neuen Nutzer kam über Google, insbesondere auf Seiten mit Kindernamen („ein Märchen für Sofia“). Eine native App hätte diesen Kanal nicht geboten.
- Iterationsgeschwindigkeit. Ich habe Updates mehrmals pro Woche deployed, und die Nutzer erhielten die neue Version sofort.
- Kosten. Ohne Entwicklerkonto, Mac und separate mobile CI/CD.
Was nicht optimal funktioniert hat
iOS. Auf dem iPhone gibt es keine automatische Installationsaufforderung, also habe ich einen eigenen Hinweis hinzugefügt: „Tippen Sie auf Teilen → Zum Home-Bildschirm“. Das ist nicht perfekt, hat aber funktioniert.
🎯 Section 8. Cost and Timeline: Specific Figures
A PWA is typically several times cheaper than native development, but the cost depends on complexity. Below are estimated ranges, not a fixed price list.
The question is not "how much does an app cost," but "how much does every month of launch delay cost."
| Parameter | PWA | Native (Cross-Platform) | Native (Separate iOS + Android) |
|---|
| MVP Development Time | Days (if a website exists) to a few weeks | 2–4 months | 4–8 months |
| Development Cost | $0 — $5K | $15K — $50K | $30K — $150K+ |
| Developer Accounts | Not required (unless publishing to stores) | Apple $99/year + Google $25 one-time | Apple $99/year + Google $25 one-time |
| Maintenance (per month) | $0 — $500 | $1K — $5K | $2K — $10K |
| Store Commission | 0% | 15–30% | 15–30% |
| Mac Required | No | Yes (for iOS) | Yes (for iOS) |
Hidden PWA Costs
A PWA is not free "out of the box." Allocate time for rendering public pages (SSG, SSR, or prerendering), configuring push notifications, and supporting iOS. Skipping these tasks will result in a lack of search traffic and installation issues that wipe out any savings. What belongs to the promotion strategy is detailed in the article How to Promote a PWA.
❓ Section 9. Frequently Asked Questions (FAQ)
Can a PWA completely replace a native app?
For many applications, yes: content, service, e-commerce, and SaaS. For games, IoT, AR, and complex graphics, no—native is required.
Can you publish a PWA on Google Play and the App Store?
On Google Play, yes, via Trusted Web Activity. In the App Store, technically yes via a WebView wrapper, but Apple may reject an app that does not provide native value beyond the website. Details are in Section 6 and the article How to Promote a PWA.
Will users find my PWA?
Through Google, yes, if public pages are crawlable and served as ready HTML. In the App Store, no, unless you published it there. Search, catalogs, links, and installation are covered in detail in the article How to Promote a PWA: SEO, Indexing, and Installation.
What is better for the Ukrainian market?
It depends on the audience. Android traditionally dominates in Ukraine, so most users will get a full PWA experience with an install prompt. Check the current platform share in your own analytics.
Does a PWA work on iPhones in the EU?
Yes: Apple initially planned to remove Home Screen web apps in the EU, but reversed that decision and kept them. Before publishing, check current status on Apple's DMA page, as EU rules change.
Is a PWA secure?
A PWA operates exclusively over HTTPS, and Service Workers lack DOM access and run in an isolated thread. A PWA does not gain extra permissions upon installation. However, for regulated industries (banking, healthcare), native apps offer more protective tooling.
✅ Section 10. Conclusions and Selection Formula
For many projects, a PWA is not a compromise but a deliberate choice, especially for a solo developer or small team. However, technology is only half the decision: the other half is distribution and discoverability.
Technology should serve the product, not the other way around.
Selection Formula: 6 Questions
| Question | If "Yes" | If "No" |
|---|
| Is primary interaction text, images, audio, or video? | PWA | Consider native |
| Do you need Bluetooth, NFC, AR, HealthKit, or reliable background tasks? | Native | PWA |
| Can your audience arrive from search or a link? | PWA | Consider stores |
| Are there strict compliance requirements (PCI DSS, HIPAA)? | Native | PWA |
| Is store presence critical for trust? | PWA + TWA/wrapper or native | PWA |
| Are budget and launch time limited? | PWA | Choose based on other criteria |
If most answers point to a PWA, start with it: it takes days, not months. If in six months you find that native is needed, you will already have a working product, an audience, and an understanding of what exactly to build. And if your product is a game, IoT controller, or AR app, go straight to native development.
After choosing your technology, the next question is how people will discover your PWA and install it. This is broken down in the article How to Promote a PWA: SEO, Indexing, and Installation.
🔗 Further Reading
📖 Sources and Useful Links
