Native, PWA oder Cross-Platform — welche App-Art passt?

Worum es geht

Erhalten wir eine Anfrage zu einem digitalen Produkt, ist die erste Aussage von Gründerinnen, KMU-Geschäftsleitungen und Innovations-Verantwortlichen — wenig überraschend — fast immer: "Wir wollen eine App entwickeln." Gemeint ist dabei in 95% der Fälle eine native App aus dem App Store, die User:innen auf ihrem Smartphone installieren.

Bei genauerem Abklären der Bedürfnisse stellt sich aber regelmässig heraus: Eine native App aus dem Store ist gar nicht der einzige — und oft nicht der beste — Lösungsansatz. Es gibt mindestens fünf verschiedene Arten von Apps, und 2026 ist die Entscheidung wichtiger denn je: Wer das Falsche wählt, verbrennt sechs- bis siebenstellige Budgets oder verliert kritisches Time-to-Market. Genau hier setzt unsere Software-Beratung an — bevor eine einzige Zeile Code geschrieben wird.

Dieser Beitrag macht zwei Dinge:

1. Klare Übersicht und Vergleich der App-Typen (Native, Cross-Plattform, Hybrid, Web App, Progressive Web App) — mit Vor- und Nachteilen und konkreten Anwendungsfällen.
2. PWA-Deep-Dive plus AI-MVP-Setup für Startups, KMU und alle, die schnell und kostengünstig eine ansehnliche Web-App lancieren wollen — ohne klassisches Coding-Budget, mit den Tools von 2026.

Form folgt Funktion — auch beim Tech-Stack

"Form folgt Funktion" stammt aus der Architektur des späten 19. Jahrhunderts und meint: Die Form eines Gebäudes soll in erster Linie der beabsichtigten Funktion folgen — nicht umgekehrt. Genau so denken wir die Technologie-Wahl für Apps.

Die Wahl des Tech-Stacks hängt von mehreren Faktoren ab, die sich gegenseitig bedingen: der konkreten Funktionalität und Komplexität des Produkts, dem Anwendungsfall und Kontext (Consumer, B2B, intern), der Zielgruppe und den Zielmärkten, den zeitlichen und finanziellen Ressourcen, der geplanten Einsatzdauer und Lebenszyklus-Erwartung sowie den technischen Anforderungen an Performance, Offline-Fähigkeit und Hardware-Zugriff.

Jede App-Art hat ihre Stärken und Schwächen. Wichtig: technologie-neutral herangehen. "Wir machen alles in Flutter" oder "Wir machen immer native" sind ideologische Aussagen, keine strategischen. In unserer Strategie & Transformation klären wir deshalb immer zuerst das Konzept und den Anwendungsfall, bevor wir über ein Tool oder einen Stack reden.

Die fünf App-Arten im Überblick

1. Native Apps

Was es ist: Ein Software-Programm, das spezifisch für eine Plattform (iOS oder Android) entwickelt wurde — in der jeweiligen nativen Sprache (Swift/SwiftUI für iOS, Kotlin/Jetpack Compose für Android).

Charakteristik:

• Höchste Performance, weil direkter Zugriff auf das Betriebssystem und die Hardware
• Optimales User Experience nach den jeweiligen Plattform-Conventions
• Voller Zugriff auf alle Sensoren, Hardware-Features, Plattform-APIs
• Schnelle Adoption neuer OS-Features (Apple Intelligence, Material You)
• Distribution über App Store / Play Store
• 30%-Provision an die Stores (für In-App-Käufe)

Nachteile:

• Zwei separate Codebases (iOS + Android) — höhere Entwicklungs- und Wartungskosten
• App-Store-Review-Prozesse (kann Releases verzögern)
• Updates müssen User aktiv installieren

Wann sinnvoll:

• Performance-kritische Apps (Spiele, Video-Verarbeitung, AR)
• Apps mit tiefer OS-Integration (z.B. Health-Apps mit HealthKit, AR-Apps mit ARKit)
• Apps mit grosser, langfristiger User-Basis und hohem Anspruch an Plattform-Konformität
• Apps mit kritischer Hardware-Nutzung (Bluetooth, NFC-Payments, Foto-Pipelines)

2. Cross-Plattform Apps

Was es ist: Apps, die in einer einzigen Sprache geschrieben und für beide Plattformen kompiliert werden. Die zwei dominanten Frameworks 2026: Flutter (von Google, Dart-Sprache) und React Native (von Meta, JavaScript/TypeScript). Kotlin Multiplatform Mobile (KMM) als jüngere Alternative gewinnt an Bedeutung.

Charakteristik:

• Ein Code, zwei Plattformen — typisch 70–85% Code-Sharing
• Performance heute (Flutter) sehr nahe an nativ, bei React Native je nach Architektur etwas darunter
• Schnellere Time-to-Market als zwei native Apps
• Tooling und Ökosystem mittlerweile sehr ausgereift

Nachteile:

• Plattform-spezifische Features brauchen oft nativen Code (Bridges) — am Ende hat man dann doch drei Code-Stränge
• Abhängigkeit vom Framework-Anbieter (neues iOS-Feature → Framework muss erst nachziehen)
• Die UI ist nicht zu 100% "echt nativ" (Flutter rendert eigene Widgets, React Native bridged zu nativen Komponenten)

Wann sinnvoll:

• Time-to-Market wichtig, Budget begrenzt
• Funktionalität auf iOS und Android nahezu identisch
• Mittlere Performance-Anforderungen
• Mittlere bis grosse Apps mit langem Lebenszyklus, bei denen Wartungseffizienz zählt

3. Hybride Apps

Was es ist: Apps, die Web-Inhalte innerhalb einer mobilen Hülle (Native-App-Container, sogenannter Wrapper) ausführen. Klassiker: WebView-basierte Apps mit Ionic oder Cordova. In der extremsten Form: eine reine Web-App im nativen Container.

Charakteristik:

• Sehr schnelles Setup, weil 1× Web-Code geschrieben wird
• Distribution über App Stores möglich
• Geringere Performance, weil WebView-Layer dazwischen
• Look & Feel oft nicht ganz "nativ"

Nachteile:

• Performance und User Experience oft unterlegen
• Komplexere Animationen und Geste-Handling können holprig wirken
• Begrenzter Hardware-Zugriff
• 2026 wirkt der Hybrid-Ansatz für viele Use-Cases überholt — entweder native/cross-platform oder PWA

Wann (noch) sinnvoll:

• Wenn aus Compliance-Gründen App-Store-Distribution Pflicht ist, aber das Budget extrem knapp
• Content-getriebene Apps mit minimalen Interaktions-Anforderungen (News, Reader, einfache Kataloge)

Anmerkung: Praktisch jede App ist heute teilweise hybrid (enthält WebViews für AGB, Hilfe, Onboarding-Storys). Der Begriff "Hybrid-App" verliert dadurch teilweise seine Schärfe.

4. Web Apps

Was es ist: Eine im Browser laufende Anwendung. Keine Installation, kein App-Store, keine Plattform-Abhängigkeit. URL aufrufen → läuft.

Charakteristik:

• Maximal niedrige Eintritts-Schwelle für Nutzer:innen
• Sofortige Updates ohne App-Store-Review
• Plattform-unabhängig (läuft auf Desktop, Mobile, Tablet)
• SEO-fähig (im Gegensatz zu nativen Apps)
• Voller Zugriff aufs Web-Ökosystem (Linking, Sharing, Embedding)

Nachteile:

• Keine Installation auf dem Homescreen (klassische Web-App)
• Kein Offline-Modus (klassische Web-App)
• Begrenzter Hardware-Zugriff
• Kein Push-Notification-Support (klassische Web-App)

Wann sinnvoll:

• B2B-Anwendungen (CRM, Admin-Tools, Dashboards)
• E-Commerce mit hohem SEO-Wert
• Content-Plattformen (Media, Blogs, Marketplaces)
• Tools, die Desktop-getrieben sind

5. Progressive Web Apps (PWA) — der hybride Power-Modus

Was es ist: Eine Web-App, die einzelne Merkmale einer nativen App besitzt — installierbar auf dem Homescreen, offline-fähig, mit Push-Notifications, mit App-ähnlichem Verhalten. Technisch: Web-App + Web-App-Manifest + Service Worker.

Charakteristik:

• Ein Codebase, läuft überall (Mobile, Desktop, Tablet)
• Installierbar auf dem Homescreen, läuft wie App (Standalone-Modus, ohne Browser-UI)
• Offline-Fähigkeit über Service Worker
• Push-Notifications (auch auf iOS seit 16.4)
• Hardware-Zugriff erweitert sich laufend (Kamera, Bluetooth, Geolocation, Web-Share, Web-Authn für Biometrie)
• Keine App-Store-Provision
• Sofortige Updates — kein Review-Prozess

Nachteile:

• Auf iOS bis vor Kurzem mit einigen Einschränkungen — 2026 deutlich entspannter, aber noch nicht 100% Feature-Parität
• Discovery: PWAs sind nicht in App Stores listbar (aktuell experimentell auf Android via Play Store via PWA Wrapper, aber nicht Standard)
• User-Edukation: viele Nutzer:innen wissen nicht, wie man eine PWA installiert ("Zum Homescreen hinzufügen")

Genau hier wird's spannend für Startups, KMU und MVPs — Deep-Dive folgt unten.

PWA-Deep-Dive: warum PWAs 2026 oft die optimale Wahl für Startups und Proof-of-Concepts sind

Vor 5 Jahren war PWA noch ein Kompromiss. 2026 ist die PWA für viele Use-Cases die objektiv beste Wahl, gerade für Startups und für KMU, die einen Proof-of-Concept schnell und kosteneffizient testen wollen. Drei Gründe:

1. Time-to-Market: Faktor 5 schneller als native iOS + Android

Eine PWA ist eine Web-App mit zwei zusätzlichen Standard-Komponenten (Manifest + Service Worker). Du baust einmal — und hast iOS, Android, iPad, Desktop, Smart-TV-Browser, Windows, Linux. Kein App-Store-Review (= keine 1–7-Tage-Verzögerung pro Release), kein paralleles Team für zwei Codebases.

Konkret: Ein MVP, der nativ 4–6 Monate dauert, ist als PWA realistisch in 6–10 Wochen machbar. Mit dem AI-Setup unten teilweise sogar in 1–3 Wochen — wie schnelles WebApp-Prototyping heute konkret aussieht, zeige ich dir an zwei realen Projekten.

2. Kosten: Faktor 3–5 günstiger über den Lebenszyklus

• Eine Codebase statt zwei oder drei → Wartung 50–70% günstiger
• Keine App-Store-Provision (30% auf In-App-Käufe) → bei monetarisierten Apps massiv
• Keine separaten Apple/Google Developer Accounts (zusammen ca. 130–140 CHF einmalig) → nice-to-have, nicht entscheidend, aber zählt für Mikrobudgets

3. User-Acquisition: niedrigere Schwelle

• Kein Install-Friction: User können via Link sofort starten, ohne aus dem Flow zu wechseln ("App Store öffnen → installieren → wieder zurückkommen" = 50–80% Drop-off)
• Linkable und teilbar → wachsende organische Reichweite
• SEO-fähig → Google-Traffic möglich, im Gegensatz zu nativen Apps

Wann ist eine PWA nicht die richtige Wahl?

PWAs sind nicht für alles geeignet. Setze auf nativ oder cross-platform, wenn:

• Hochfrequente Hardware-Zugriffe essentiell sind (z.B. AR, intensive Bluetooth-Kommunikation mit speziellen Geräten, NFC-Payments)
• App-Store-Listing Pflicht ist (Enterprise-Vorgaben, B2B-Kund:innen verlangen das)
• Performance-kritische 3D / Video-Editing / Spiele im Fokus stehen
• iOS-spezifische Tiefenintegrationen (HealthKit, HomeKit, Siri Shortcuts) nötig sind

In ca. 70–80% der Startup- und KMU-Anwendungsfälle, die ich in den letzten drei Jahren begutachtet habe, war eine PWA die objektiv beste Wahl — wurde aber initial gar nicht in Betracht gezogen.

Entscheidungs-Matrix — welche App-Art für welches Projekt

Faktoren-Vergleich im Detail

Faustregel:

• MVP/POC → PWA (oder Web App)
• Startup-Wachstumsphase, mittlere Performance → PWA oder Cross-Plattform
• Mature Product mit hohem Performance-Anspruch → Cross-Plattform oder Native
• Spezialisierte Hardware/Performance-App → Native

AI-MVP-Setup 2026: Wie du als Nicht-Coder:in in Tagen eine PWA baust

Jetzt der spannende Teil. 2026 kannst du als Person ohne klassische Programmier-Ausbildung in wenigen Tagen eine ansehnliche, produktive Web-App / PWA online haben — wenn du den richtigen Stack nutzt. Hier mein konkretes Setup, das ich für aheadoftime.ch, purebosnia.com und mehrere andere Projekte nutze.

Der Stack — Übersicht

[Konzept] → Claude oder ChatGPT (Anforderungen, User-Flows, Sitemap)
   ↓
[Design]  → Figma + Figma AI / Lovable / v0 (UI-Mockups, Komponenten)
   ↓
[Code]    → Cursor + Claude Code (oder Windsurf) in VS Code
   ↓
[Repo]    → GitHub (oder GitLab) für Versionierung
   ↓
[Hosting] → Cloudflare Pages (oder Workers / Vercel / Netlify)
   ↓
[Email]   → Resend (transactional + Forms)
   ↓
[Analytics + SEO] → Cloudflare Web Analytics + Plausible (datenschutz-freundlich)

Schritt 1 — Konzept und Anforderungen mit Claude oder ChatGPT

Beschreibe der KI in 3–5 Sätzen, was du bauen willst (Zielgruppe, Hauptzweck, drei wichtigste User-Flows). Frage:

1. "Erstelle mir eine Sitemap und User-Flow-Diagramm."
2. "Liste die 5 Kernfunktionen, die ein MVP haben muss, und 5 nice-to-haves für später."
3. "Wo sind die häufigsten Pitfalls bei Projekten dieser Art?"

Tipp: Lass mehrere Iterationen laufen. Frage zurück. "Was ist die schmerzhafte Wahrheit über meine Idee, die ich vielleicht nicht sehen will?" — bringt erstaunlich oft tiefe Insights (mit Hallucination-Vorbehalt, siehe Denkfallen-Blog Teil 2).

Schritt 2 — Design mit Figma AI, Lovable oder v0 by Vercel

Drei realistische Wege 2026:

• Figma + Figma AI: Klassischer Designer-Workflow, aber mit KI-Hilfe für Wireframes, Variations und Auto-Layout-Vorschläge. Best, wenn du das Design später noch selbst feinjustieren willst.
• Lovable.dev: Beschreibst die App in natürlicher Sprache, bekommst ein laufendes React-Frontend. Eignet sich für Schnellstarts, vor allem für Marketing-Pages und einfache Web-Apps.
• v0 by Vercel: Ähnlich Lovable, aber stärker auf Komponenten-Generierung fokussiert. Output ist Tailwind + shadcn/ui — passt zu modernen Frontend-Stacks.

Mein Workflow: Lovable oder v0 für die ersten 80% der UI in 30 Minuten — dann manuelle Feinarbeit in Cursor.

Schritt 3 — Code mit Cursor und Claude Code

Cursor ist eine VS-Code-Variante mit eingebauter KI-Assistenz. Claude Code ist Anthropics CLI-Tool, das den ganzen Code-Kontext versteht und Multi-File-Änderungen orchestriert.

Konkreter Workflow:

• Cursor öffnet das Repo, Claude Code wird im integrierten Terminal gestartet
• Du beschreibst die Funktion in natürlicher Sprache: "Bau eine Kontakt-Seite mit Formular, das per Resend an info@... versendet, mit Cloudflare Turnstile als Spam-Schutz, und Two-Click-Maps-Embed für die Basel-Adresse."
• Cursor + Claude Code generieren die Files, fragen bei Unklarheiten zurück, machen Commit-Vorschläge

Du musst nicht programmieren können — aber du musst klar formulieren können. Prompting ist die neue Programmiersprache.

Schritt 4 — Repo: GitHub (oder GitLab)

Für Versionierung. Cursor pushed direkt auf den Branch. Pro Feature ein eigener Branch, Merge nach lokalem Test.

Tipp für Nicht-Coder:innen: Lass dir von Claude Code die Git-Workflows erklären, bevor du startest. Das spart später viel Frust.

Schritt 5 — Hosting: Cloudflare Pages

Cloudflare Pages ist mein Default-Hosting für 2026:

• Verbindet sich direkt mit GitHub → jeder Push auf main deployt automatisch
• Free-Tier mit unbegrenzten Requests, 500 Build-Minuten/Monat
• Global CDN, SSL/HTTPS automatisch, DDoS-Schutz inklusive
• Custom Domains in 2 Minuten konfigurierbar
• Cloudflare Workers für Backend-Logik (Serverless), Cloudflare KV für Key-Value-Storage, Cloudflare D1 für SQLite-DB, Cloudflare R2 für File-Storage

Für die meisten MVPs reicht das Free-Tier oder ein Pro-Plan für ca. 18–25 CHF/Monat — kein Server, kein Sysadmin, kein Skalierungsstress.

Schritt 6 — Transactional Email: Resend

Resend (resend.com) für E-Mail-Versand aus Formularen und für Auto-Replies:

• Modernes API, in 10 Minuten integriert
• DKIM/SPF/DMARC einfach konfigurierbar
• Free-Tier: 3'000 Mails/Monat
• Funktioniert wunderbar mit Cloudflare Workers (Serverless Endpoint für Form-Submits)

Schritt 7 — Analytics: Cloudflare Web Analytics + Plausible

• Cloudflare Web Analytics: Datenschutz-freundlich, kein Cookie, gratis
• Plausible: Für tiefere Insights, ca. 10–15 CHF/Monat, ebenfalls cookie-frei und DSGVO-konform

Schritt 8 — Spam-Schutz: Cloudflare Turnstile

Für Kontakt-Formulare als reCAPTCHA-Ersatz — keine Tracking-Implikationen, einfache Integration in <10 Min.

Was du dafür nicht brauchst

• Keine Server-Administration
• Keine DevOps-Erfahrung
• Keine Datenbank-Kenntnisse (Cloudflare D1 / KV sind serverless)
• Keine klassische Programmier-Ausbildung
• Kein Budget über 50 CHF/Monat für einen einfachen MVP

Was du wirklich brauchst

• Klare Vorstellung, was du bauen willst (siehe Schritt 1)
• Disziplin in der Verifikation von KI-Output (siehe Denkfallen-Blog Teil 2, Denkfehler 14 + 15)
• Iterations-Bereitschaft: Der erste Wurf ist nie perfekt — aber das ist beim klassischen Coden auch so
• Etwas Zeit zum Lernen der Tools — 2–4 Stunden onboarding, dann läuft's

AI / GenAI in App-Development 2026

KI verändert die App-Entwicklung auf vier Ebenen:

• Konzept und Anforderungen: ChatGPT, Claude und Gemini sind exzellente Sparring-Partner für Spec-Erstellung, User-Flow-Design, Edge-Case-Identifikation.
• Design: Lovable, v0, Galileo, Uizard und Figma AI generieren UI-Mockups in Minuten. Quality-Niveau: gut bis sehr gut, je nach Komplexität.
• Coding: Cursor, Claude Code, GitHub Copilot, Windsurf, JetBrains AI — produktivitäts-multiplier von 3–10× für erfahrene Entwickler:innen, von 0 → 1 für Nicht-Coder:innen, die früher keine Optionen hatten.
• Testing und Monitoring: AI-Agents überwachen deployments, identifizieren Regressionen, schlagen Bug-Fixes vor (Sentry, Cursor BugBot, etc.)

Wichtig: KI ist kein Ersatz für ein verstehendes Team — sie ist ein Multiplikator für vorhandenes Verständnis. Wer kein Verständnis für sauberes Software-Engineering hat, bekommt mit KI schnell viel Schrott. Wer es hat, baut mit KI das, wofür man 2020 ein 5-köpfiges Team gebraucht hat — alleine. Wenn du noch tiefer einsteigen willst, zeigt dir unser AI-Agent-Setup, wie du KI nicht nur fürs Coden, sondern auch für laufende Automationen im Betrieb nutzt.

Q&A — die häufigsten Fragen zur App-Wahl

Wann ist eine native App zwingend? Wenn du tiefen, kontinuierlichen Hardware-Zugriff brauchst (Bluetooth zu spezialisierten Geräten, AR/VR, kritische Push-Latenz), wenn App-Store-Listing aus Compliance-Gründen Pflicht ist, oder wenn du in 5+ Jahren noch konkurrenzfähig auf einer Plattform sein willst.

Kann eine PWA wirklich mit nativen Apps mithalten? In 70–80% der Use-Cases: ja, oft sogar besser (Time-to-Market, Update-Geschwindigkeit). In 20–30% der Fälle (Performance-kritisch, tiefe Hardware-Integration): nein.

Wie viel kostet ein einfacher PWA-MVP mit AI-Tooling? Realistisch: 50–300 CHF Tooling-Kosten pro Monat (Cloudflare, Resend, Plausible, Cursor-Subscription, ChatGPT/Claude-Subscription) + deine eigene Zeit. Ohne Tooling-Kosten ist sogar ein 0-CHF-Setup möglich (alles auf Free-Tier).

Brauche ich für AI-MVP-Development trotzdem einen Entwickler? Hängt von deinem Anspruch ab. Für einen funktionalen MVP mit moderater Komplexität: nein. Für ein Produkt, das skaliert und langfristig wartbar bleibt: in der Regel ja, aber nicht zu Beginn — sondern wenn der MVP traction zeigt und du auf Stabilität setzen musst.

Welche Tools nutzt du persönlich, Michael? Cursor + Claude Code als IDE-Combo, Lovable / v0 für UI-Sprints, Cloudflare Pages + Workers + D1 als Hosting-/Backend-Layer, Resend für Mails, Plausible + Cloudflare Web Analytics für Tracking, GitHub für Repos. Mit ChatGPT-5 und Claude Sonnet 4.6 als Daily-Driver für Konzept-Sparring.

Was, wenn ich gar nicht selbst bauen will? Dann bist du in der klassischen Agentur-Welt zuhause — und wir helfen gerne in einem AHEAD-OF-TIME-Mandat. Wie ein begleitetes Startup-Software-Projekt von der Idee bis zur lauffähigen Plattform aussieht, kannst du in unseren Cases nachlesen. Aber ich empfehle jedem Gründer, jedem Innovations-Team und jeder Marketing-Verantwortlichen, das Setup einmal selbst aufzusetzen. Du verstehst plötzlich, wo Komplexität wirklich sitzt — und triffst bessere Entscheidungen.

Praxis-Empfehlung für KMU und Startups 2026

1. Definier den Use-Case ehrlich: Brauchst du wirklich eine native App? Oder reicht eine PWA für 90% der User-Bedürfnisse?
2. Starte mit einer PWA, wenn du in den ersten 12–18 Monaten Product-Market-Fit findest. Native ist immer noch eine Option, wenn der Markt es verlangt.
3. Nutze AI-Tools für Konzept, Design, Code — sie sind 2026 ausgereift genug für produktive Workflows.
4. Vergiss Cloudflare nicht. Pages + Workers + D1 + R2 sind 2026 ein unfassbar produktiver, günstiger Stack für 80% aller KMU-Web-Anwendungen.

Workshop / Bootcamp: ich helfe deinem Team beim Setup

Genau dieses Setup — von Konzept über Design bis Deployment einer ersten produktiven PWA — vermittle ich in 2- bis 5-tägigen Workshops und Bootcamps, on-site beim Kunden oder remote. Output: dein Team hat am Ende eine eigene, laufende Web-App online und das Verständnis, sie selbständig weiterzuentwickeln. Dieselbe Praxisnähe prägt seit Jahren mein FHNW-Digital-Lehrauftrag — Wissensvermittlung, die nicht im Hörsaal stehen bleibt.

Für Unternehmen, die ihre Innovations-, Marketing- oder Produkt-Teams eigenständig digital handlungsfähig machen wollen — nicht abhängig von externen Agenturen für jedes neue Projekt. Unsere KMU-Bootcamps sind genau dafür gemacht: praxisnah, hands-on und auf dein Team zugeschnitten.

Interesse? Schreib mir eine Nachricht über das Kontaktformular — wir besprechen euer Setup im 30-Min-Call.