React Native vs PWA 2026: Was brauchst du wirklich?

Du hast eine React-Web-App, und die Leute fragen ständig nach „der App“. Also suchst du nach React Native vs PWA und landest bei Agentur-Artikeln, die mit „kommt darauf an“ enden. Dieser Artikel setzt fünf Prüfpunkte dagegen: Push-Benachrichtigungen, Offline, Installation, Gesten und Store-Präsenz. Jeder hat 2026 eine klare Antwort, und die meisten hängen davon ab, was Safari auf dem iPhone erlaubt. Falls du nach „PWA vs React Native Reddit“ gesucht hast und aus einem dieser Threads kommst, hier die Kurzfassung: Web-Apps auf dem iPhone haben 2023 Push bekommen. Die Lücke ist kleiner als früher, aber es gibt sie noch.

Wir bauen Wingo UI, eine React-Komponentenbibliothek fürs Web, wir sind also nicht neutral: Unsere Komponenten laufen im Browser, keine davon läuft in React Native. Die Plattform-Fakten in diesem Artikel verlinken auf Apple, WebKit, Google, Microsoft und die React-Native-Doku; geprüft haben wir sie am 16. Oktober 2026. Wo React Native die bessere Wahl ist, sagen wir das. Weitere Vergleiche findest du in der Kategorie Vergleiche oder in unserem Guide zu shadcn-Alternativen.

Was ist der eigentliche Unterschied zwischen einer React PWA und React Native?

Eine Progressive Web App ist deine Website plus ein Manifest und meistens ein Service Worker. Der Browser rendert sie, und nach der Installation öffnet sie sich in einem eigenen Fenster ohne Adressleiste. Beim Vergleich React PWA vs React Native ist die PWA-Seite das React DOM, das du ohnehin schreibst: dieselben Komponenten, dieselben Tailwind-Klassen, derselbe Deploy.

React Native rendert echte Plattform-Views. Du schreibst React, aber mit View, Text und Pressable statt div und button, und das Ergebnis landet als iOS- und Android-Binary in den Stores. Seit React Native 0.76 (opens in a new tab) ist die New Architecture der Standard, und 0.82 war das erste Release, das komplett darauf läuft. Die React-Native-Doku empfiehlt den Einstieg über ein Framework (opens in a new tab), und in der Praxis heißt das Expo (npx create-expo-app@latest).

Die nützliche Frage lautet daher: Welche Funktionen deiner App verweigert dir der iPhone-Browser? Die nächsten Abschnitte gehen sie der Reihe nach durch.

Wie schneiden React Native und PWAs 2026 im Vergleich ab?

React Native gewinnt bei Gerätezugriff, Hintergrundaufgaben und App Store; eine PWA gewinnt bei Reichweite, Updates und Kosten. Stand: 16. Oktober 2026. „iPhone“ steht hier für jeden Browser auf iOS, denn alle nutzen WebKit.

Kann eine PWA auf dem iPhone Push-Benachrichtigungen senden?

Ja, unter zwei Bedingungen. WebKit hat in iOS und iPadOS 16.4 Web Push für Web-Apps auf dem Home-Bildschirm (opens in a new tab) eingeführt: Die Seite muss zuerst zum Home-Bildschirm hinzugefügt werden, und die Berechtigungsanfrage muss durch eine direkte Interaktion ausgelöst werden, etwa einen Tipp auf einen Button. Ein Safari-Tab auf dem iPhone kann kein Web Push empfangen. Mit demselben Release kam die Badging API für das App-Icon. Seit iOS 18.4 unterstützt WebKit außerdem Declarative Web Push (opens in a new tab): Damit erscheint eine Benachrichtigung, die im Push-Payload beschrieben ist, ohne dass dafür ein Service Worker laufen muss.

Für dein Produkt zählt diese Reihenfolge. Auf Android kann jemand Benachrichtigungen schon beim ersten Besuch einschalten. Auf dem iPhone installieren die Leute zuerst, öffnen dann die App vom Home-Bildschirm und tippen erst danach auf deinen Button. Frag in genau dieser Reihenfolge:

"use client"

import { Button } from "@/components/ui/button"
import { useInstallPrompt } from "@/components/ui/install-prompt"

// der öffentliche VAPID-Key kommt base64url-kodiert an; pushManager will Bytes
function toBytes(base64url: string) {
  const base64 = (base64url + "=".repeat((4 - (base64url.length % 4)) % 4)).replace(/-/g, "+").replace(/_/g, "/")
  return Uint8Array.from(atob(base64), (c) => c.charCodeAt(0))
}

export function EnableAlerts({
  vapidKey,
  onSubscribed,
}: {
  vapidKey: string
  onSubscribed: (subscription: PushSubscriptionJSON) => Promise<void>
}) {
  const { platform, isStandalone } = useInstallPrompt()

  // das iPhone liefert Web Push nur an die App auf dem Home-Bildschirm, ein Safari-Tab bekommt stattdessen den Installationshinweis
  if (platform === "ios" && !isStandalone) {
    return <p className="text-sm text-muted-foreground">Füg die App zu deinem Home-Bildschirm hinzu, um Benachrichtigungen zu Bestellungen zu bekommen.</p>
  }

  async function enable() {
    if (!("Notification" in window) || !("serviceWorker" in navigator)) return
    // direkt aus dem Klick aufgerufen, weil iOS das für den Berechtigungsdialog verlangt
    const permission = await Notification.requestPermission()
    if (permission !== "granted") return
    const registration = await navigator.serviceWorker.ready
    const subscription = await registration.pushManager.subscribe({
      userVisibleOnly: true,
      applicationServerKey: toBytes(vapidKey),
    })
    await onSubscribed(subscription.toJSON())
  }

  return <Button onClick={enable}>Benachrichtigungen zu Bestellungen einschalten</Button>
}

useInstallPrompt ist der Hook hinter dem Install Prompt. Er meldet platform ("ios" auf iPhone und iPad, in jedem Browser) und isStandalone (die installierte App). So zeigt dieselbe Komponente im Tab und in der App auf dem Home-Bildschirm jeweils das Richtige. Den Service Worker, der den Push empfängt, schreibst du selbst; ein vollständiges Beispiel steht im PWA-Guide von Next.js (opens in a new tab).

In diesem Punkt gewinnt React Native, wenn Benachrichtigungen der Grund sind, warum es die App überhaupt gibt. Ein Liefer-Tracker, eine Chat-App oder ein Marktplatz, der Leute erreichen muss, die nie etwas von deiner Seite installiert haben, kann sich nicht auf den Umweg über „Zum Home-Bildschirm“ verlassen.

Wie gut funktioniert eine PWA offline?

Gut beim Lesen, schwächer beim Schreiben. Ein Service Worker kann die App-Shell und API-Antworten cachen, und IndexedDB hält die Daten vor, die Leute im Zug brauchen. Was auf dem iPhone nicht geht: einen Schreibvorgang in eine Warteschlange stellen und ihn später vom Browser senden lassen. Die Background Sync API fehlt in Safari und Firefox komplett (caniuse (opens in a new tab)). Deine App muss es erneut versuchen, sobald sie wieder offen ist.

Gespeicherte Daten bleiben länger erhalten, sobald die App installiert ist. WebKits Blogbeitrag zum Speicher von 2020 (opens in a new tab) begrenzt per Skript beschreibbaren Speicher auf sieben Tage Safari-Nutzung ohne Interaktion mit der Seite. Web-Apps auf dem Home-Bildschirm haben laut demselben Beitrag einen eigenen Tageszähler, der sich bei echter Nutzung zurücksetzt. Ein Grund mehr, Leute zur Installation zu führen.

Next.js 16 hat außerdem einen experimentellen Hook useOffline (opens in a new tab), importiert aus next/offline und aktiviert mit experimental.useOffline. Er hält fehlgeschlagene Navigationen und Server Actions in der Schwebe und wiederholt sie, wenn die Verbindung zurück ist, und der Hook sagt dir, wann du ein Offline-Banner zeigen solltest. Einen kompletten Reload macht er aber nicht offlinefähig; dafür brauchst du weiterhin einen Service Worker.

Ist deine App ein Werkzeug für den Außendienst, das stundenlang ohne Netz Daten sammelt und im Hintergrund synchronisieren muss, nimm React Native. Oder behalte die PWA und akzeptiere, dass die Leute die App zum Synchronisieren öffnen.

Wie installieren Leute eine PWA im Vergleich zu einer Store-App?

Auf Android und Desktop mit wenigen Schritten: Chrome, Edge und Samsung Internet lösen beforeinstallprompt aus, und dein Button kann den Installationsdialog des Browsers öffnen. Auf dem iPhone löst kein Browser dieses Event aus. Der einzige Weg ist Teilen, dann „Zum Home-Bildschirm“, und deine App muss den Leuten zeigen, wo das ist. Seit iOS 26 öffnet sich laut WebKit jede Website, die zum Home-Bildschirm hinzugefügt wird (opens in a new tab), standardmäßig als Web-App, auch ohne Manifest.

Eine Store-App ist für alle, die schon im Store sind, nur einen Tipp entfernt. Eine PWA braucht für Leute, die über einen Link kommen, gar keine Installation. Traffic aus der Suche, aus E-Mails und aus geteilten Links spricht also für sie.

Gib dem Manifest einen Namen, Icons und den Anzeigemodus standalone, und bau dann einen einzigen Prompt ins Root-Layout ein:

// app/manifest.ts
import type { MetadataRoute } from "next"

export default function manifest(): MetadataRoute.Manifest {
  return {
    name: "Northwind Orders",
    short_name: "Orders",
    start_url: "/",
    display: "standalone",
    background_color: "#ffffff",
    theme_color: "#ffffff",
    icons: [
      { src: "/icon-192.png", sizes: "192x192", type: "image/png" },
      { src: "/icon-512.png", sizes: "512x512", type: "image/png" },
    ],
  }
}

// app/layout.tsx
import type { ReactNode } from "react"
import { InstallPrompt } from "@/components/ui/install-prompt"

export default function RootLayout({ children }: { children: ReactNode }) {
  return (
    <html lang="de">
      <body>
        {children}
        <InstallPrompt
          appName="Northwind Orders"
          appIcon="/icon-192.png"
          description="Öffne die App vom Home-Bildschirm und erhalte Benachrichtigungen zu Bestellungen."
        />
      </body>
    </html>
  )
}

Der Install Prompt öffnet in Chromium den Dialog des Browsers und zeigt auf dem iPhone die drei Schritte zu „Zum Home-Bildschirm“. Er wartet delay Millisekunden (standardmäßig 3000), sobald eine Installation möglich ist, merkt sich „Not now“ für dismissDays Tage (standardmäßig 14) und rendert nichts in der installierten App oder in einem In-App-Browser wie dem von Instagram.

Die komplette Anleitung, auch dazu, wann du besser nicht fragst, steht in unserem Tutorial zum React PWA Install Prompt.

Kann sich eine PWA mit Gesten und Tab-Leisten nativ anfühlen?

Ja, wenn du die Gesten selbst baust. Eine installierte PWA hat keine Browserleiste, also gibt es keinen Zurück-Button, und auf das Pull to Refresh des Browsers kannst du dich nicht verlassen. Alles, was sich wie eine App verhalten soll, schreibst du in JavaScript: eine Tab-Leiste in Daumennähe, Sheets, die sich ziehen lassen, eine Liste, die du zum Neuladen herunterziehst.

React Native startet hier mit Vorsprung. Seine Navigationsbibliotheken liefern native Stacks mit der plattformtypischen Wischgeste vom Rand für „Zurück“, und Gesten laufen im nativen Gestensystem. Im Web kommst du mit sorgfältigem Touch-Handling nah heran: touch-action auf ziehbaren Flächen, Springs, die dem Finger folgen, Safe Area Insets und Touch-Ziele von 44px. Unser Guide, wie sich eine Web-App nativ anfühlt, geht diese Details einzeln durch.

Zwei Bausteine, die als Erstes fehlen, sind die Tab-Leiste und Pull to Refresh. Hier sind beide zusammen in einem Screen, mit der Liste als Scroll-Container und der Leiste im normalen Fluss darunter. Der Stolperstein ist der Scroll-Container. Pull To Refresh findet den nächsten scrollenden Vorfahren selbst, aber die Bottom Tab Bar beobachtet das Fenster, solange sie nicht in einem ScrollContainerProvider sitzt. Scrollt die Liste also in einem eigenen Element, gib dieses Element als scrollTarget mit. Ohne das scrollt ein Tipp auf den aktiven Tab ein Fenster, das sich nicht bewegt:

"use client"

import { useRef, useState } from "react"
import { House, Inbox, Search, UserRound } from "lucide-react"
import { BottomTabBar, type BottomTabBarItem } from "@/components/ui/bottom-tab-bar"
import { PullToRefresh } from "@/components/ui/pull-to-refresh"

const tabs: BottomTabBarItem[] = [
  { label: "Bestellungen", href: "/", icon: <House />, activeIcon: <House className="fill-current" /> },
  { label: "Suche", href: "/search", icon: <Search /> },
  { label: "Posteingang", href: "/inbox", icon: <Inbox />, badge: 3 },
  { label: "Profil", href: "/profile", icon: <UserRound />, activeIcon: <UserRound className="fill-current" /> },
]

type Order = { id: string; customer: string; total: string }

export function OrdersScreen({ initial, load }: { initial: Order[]; load: () => Promise<Order[]> }) {
  const [orders, setOrders] = useState(initial)
  // die Liste scrollt, nicht das Fenster, also muss die Tab-Leiste wissen, welches Element sie nach oben scrollt
  const listRef = useRef<HTMLDivElement>(null)

  return (
    <div className="flex h-dvh flex-col">
      <div ref={listRef} className="min-h-0 flex-1 overflow-y-auto">
        <PullToRefresh variant="ios" onRefresh={async () => setOrders(await load())}>
          <ul className="divide-y divide-foreground/10">
            {orders.map((order) => (
              <li key={order.id} className="flex justify-between px-4 py-3">
                <span className="font-medium">{order.customer}</span>
                <span className="text-muted-foreground tabular-nums">{order.total}</span>
              </li>
            ))}
          </ul>
        </PullToRefresh>
      </div>
      <BottomTabBar className="md:hidden" items={tabs} position="static" scrollTarget={listRef} />
    </div>
  )
}

Pull To Refresh bringt einen Gummiband-Widerstand mit, dreht seinen Spinner, bis das Promise von onRefresh abgeschlossen ist (mindestens 500ms, damit nichts aufblitzt), und zeichnet mit variant="ios" die Speichen, während du ziehst. Außerdem setzt die Komponente overscroll-behavior-y: contain auf den Scroll-Container, damit Chrome auf Android die Seite nicht neu lädt. Probier es mit dem Finger aus oder mit dem Trackpad, indem du oben angekommen weiter nach oben scrollst:

Die Bottom Tab Bar nimmt 3 bis 5 Tabs, hält über die Safe Area Abstand zum Home-Indikator und bewegt ihre Pill mit einer Spring zwischen den Tabs. Ein Tipp auf den aktiven Tab scrollt seine Seite zurück nach oben, so wie bei einer Tab-Leiste in iOS:

Die ehrliche Grenze: Das sind gute Web-Komponenten, und es bleiben Web-Komponenten. Lebt deine App von Gesten, etwa als Foto-Editor, Karte mit gezeichneten Routen oder Kamera-Flow, ist die Gesten- und Render-Pipeline von React Native die sicherere Wahl.

Welche PWA-Einschränkungen gibt es 2026 auf iOS?

Diese sechs Einschränkungen einer PWA auf iOS entscheiden im Oktober 2026 noch immer über Projekte:

• Kein Installationsdialog. Kein Browser auf dem iPhone feuert beforeinstallprompt, also führst du die Leute durch das Teilen-Menü.
• Push erst nach der Installation. Web Push funktioniert ab iOS 16.4 in der App auf dem Home-Bildschirm, nie in einem Safari-Tab.
• Kein Background Sync. Background Sync fehlt in Safari auf iOS, Schreibvorgänge in der Warteschlange warten also, bis die App offen ist.
• Kein Bluetooth, kein NFC. Web Bluetooth und Web NFC gibt es in Safari nicht. Hardware-Kopplung, NFC-Tags und BLE-Geräte brauchen nativen Code.
• Keine Vibration. Safari hat keine Vibration API, haptisches Feedback in einer Web-App gibt es also nur auf Android; gib zu jedem Vibrationsfeedback auch eine sichtbare Rückmeldung, wie unser Guide zur Vibration API erklärt.
• Eine Engine. Chrome, Edge und Firefox nutzen auf dem iPhone ebenfalls WebKit, daher ändert ein anderer Browser nichts an den Punkten oben.

Ist einer dieser Punkte der Kern deines Produkts, ist die Frage damit beantwortet.

Kannst du eine PWA im App Store oder bei Google Play veröffentlichen?

Google Play und der Microsoft Store nehmen eine verpackte PWA an; der App Store in der Praxis nicht. Das zählt, wenn der Store-Eintrag selbst Pflicht ist, unabhängig von den Funktionen: Manche Kunden verlangen ihn, und manche Zielgruppen suchen Apps nur im Store.

Auf Android schafft es eine PWA in den Store: Eine Trusted Web Activity (opens in a new tab) öffnet deine PWA im Vollbild in einer Android-App, verifiziert über Digital Asset Links, und die Bubblewrap CLI erzeugt das Projekt. Für Windows dokumentiert Microsoft, wie du mit PWABuilder eine PWA im Microsoft Store veröffentlichst (opens in a new tab), und Änderungen am Frontend erreichen die Leute ohne neues Paket.

Der App Store ist der schwierige Fall. Richtlinie 4.2 (opens in a new tab) verlangt Funktionen, Inhalte und eine UI, die über eine neu verpackte Website hinausgehen, eine WebView um deine PWA wird also wahrscheinlich abgelehnt. Ist ein Store-Eintrag fürs iPhone Pflicht, kalkulier mit React Native oder mit einer nativen Hülle, die echte native Funktionen mitbringt.

Wo steht Flutter neben React Native und einer PWA?

Flutter steht auf der nativen Seite der Tabelle, mit einer anderen Sprache. Es kompiliert eine Dart-Codebasis für iOS und Android und zeichnet seine eigenen Widgets, statt die Views der Plattform zu nutzen. Für ein React-Team ist die Wahl Flutter vs React Native vs PWA vor allem eine Frage der Sprache: Mit Flutter lernst du Dart und ein neues Widget-System, mit React Native bleibst du bei React und TypeScript, und mit einer PWA behältst du den Code, den du schon auslieferst. In der Tabelle schneidet Flutter Zeile für Zeile ab wie React Native; nimm es, wenn dein Team Dart schon kann.

Solltest du eine PWA oder eine React-Native-App bauen?

Bau eine PWA, es sei denn, eine deiner Pflichtfunktionen steht in der React-Native-Spalte der Tabelle. Nach Anwendungsfall:

• SaaS-Dashboards, CRMs, interne Tools, Buchungs- und Admin-Apps: eine PWA. Die meiste Arbeit sind Screens, Formulare und Tabellen, die Leute melden sich über einen Link an, und Push kann warten, bis sie installieren.
• Inhalte, Commerce und Produkte, die über Marketing wachsen: zuerst eine PWA. Jede Seite ist indexierbar und teilbar, und ein Link ist der schnellste Weg zur ersten Sitzung.
• Messaging, Lieferdienste, Ride-Sharing, alles, bei dem Push das Produkt ist: React Native. Du brauchst Benachrichtigungen, bevor jemand irgendetwas aus Safari installiert.
• Hardware, Standort im Hintergrund, Außendienst offline: React Native. Bluetooth, NFC und Background Sync stehen einer Web-App auf dem iPhone nicht zur Verfügung.
• Du musst im App Store sein: React Native (oder Flutter).
• Noch unsicher: Bring die PWA raus, miss, wie viele Leute sie installieren und Benachrichtigungen erlauben, und bau dann React Native für die Funktionen, die der Browser blockiert. API, Typen und Geschäftslogik lassen sich übernehmen; die UI nicht.

Was solltest du als Nächstes tun?

Wenn die PWA deine App abdeckt, fang mit dem Installationsweg an: Auf dem iPhone schaltet erst die Installation Push und das längere Speicherfenster frei. Installier den Prompt mit npx wingo-ui@latest add install-prompt und ergänze dann die Bottom Tab Bar und Pull To Refresh für die Screens, die Leute auf dem Smartphone nutzen. Alle drei sind Pro-Komponenten; auf der Preisseite findest du die Pläne, und Button, Drawer, Badge und Spinner, auf denen sie aufbauen, sind kostenlos.

Häufige Fragen

Ist eine PWA besser als React Native?

Keine der beiden Optionen ist grundsätzlich besser. Eine PWA ist eine Codebasis, die mit jedem Deploy live geht und sich über einen Link öffnet; React Native bringt dir Store-Einträge, Hintergrundaufgaben und Geräte-APIs, die der iPhone-Browser nicht anbietet. Entscheide nach den Funktionen, ohne die deine App nicht an den Start gehen kann.

Kann eine PWA auf dem iPhone Push-Benachrichtigungen senden?

Ja, seit iOS und iPadOS 16.4, aber erst, wenn die Web-App zum Home-Bildschirm hinzugefügt wurde, und die Berechtigungsanfrage muss durch einen Tipp ausgelöst werden. Ein Safari-Tab kann auf dem iPhone kein Web Push empfangen. Bitte also zuerst um die Installation und erst in der installierten App um Benachrichtigungen.

Kann ich eine PWA in den App Store bringen?

Nicht als einfache Hülle. Richtlinie 4.2 des App Stores verlangt eine App, die mehr ist als eine neu verpackte Website, deshalb wird eine WebView um deine Seite wahrscheinlich abgelehnt. Google Play nimmt eine PWA als Trusted Web Activity an, der Microsoft Store eine mit PWABuilder verpackte PWA.

Kann ich meinen React-Code zwischen PWA und React Native wiederverwenden?

Logik, Typen, API-Clients und State lassen sich übernehmen; die UI meist nicht, denn React Native rendert View und Text statt DOM-Elementen und nutzt keine Tailwind-Klassen. Expo kann eine React-Native-App außerdem über React Native for Web ins Web exportieren; das ist der umgekehrte Weg.

Was sind 2026 die wichtigsten PWA-Einschränkungen auf iOS?

Kein Installationsdialog, den eine Seite öffnen kann, Web Push erst nach „Zum Home-Bildschirm“, kein Background Sync, kein Web Bluetooth oder Web NFC und keine Vibration API. Jeder Browser auf dem iPhone nutzt WebKit, ein Wechsel zu Chrome oder Edge auf iOS ändert also nichts davon.