Zwei Architekturen im Vergleich
Was das praktisch bedeutet
- Bediengefühl: React-Native-Apps nutzen die Original-Bedienelemente von iOS und Android – Scrollen, Übergänge und Gesten fühlen sich automatisch „richtig“ an. Bei Capacitor muss dieses Gefühl im Web-Code nachgebaut werden; gut gemacht fällt der Unterschied kaum auf, schlecht gemacht sofort.
- Performance: Für Formulare, Listen und typische Business-Oberflächen sind beide schnell genug. Bei langen Listen, aufwendigen Animationen oder älteren Geräten hat React Native Reserven, wo die WebView an Grenzen stößt.
- Code-Wiederverwendung: Capacitor glänzt, wenn bereits eine Web-App existiert – sie läuft mit überschaubarem Aufwand als App weiter. React Native teilt Logik und Know-how mit dem Web (React), aber die Oberfläche wird eigens gebaut.
- Gerätefunktionen: Kamera, GPS, Push, Biometrie – beide Ökosysteme bieten dafür fertige Anbindungen. Bei sehr speziellen Anforderungen führt in beiden Welten der Weg über native Module.
Wann welcher Ansatz?
✓ Capacitor passt, wenn …
… eine gepflegte Web-App bereits existiert und schnell in die Stores soll · das Budget klein ist · die App vor allem Inhalte und Formulare zeigt · Web und App wirklich identisch sein sollen.
✓ React Native passt, wenn …
… die App ein eigenständiges Produkt mit nativem Bediengefühl sein soll · Performance und flüssige Interaktion wichtig sind · die App langfristig wachsen wird · das Team ohnehin mit React arbeitet.
Und was ist mit Ionic und Cordova?
Ionic ist eine UI-Bibliothek, die meist auf Capacitor aufsetzt (früher auf dem Vorgänger Cordova) – viele bestehende Business-Apps sind so gebaut, auch etliche unserer früheren Projekte. Diese Apps laufen weiter und lassen sich pflegen. Wenn allerdings ein größerer Umbau ansteht oder die WebView-Grenzen spürbar werden, ist das ein natürlicher Zeitpunkt, die Portierung auf React Native zu prüfen: Die Geschäftslogik lässt sich dabei oft übernehmen, die Oberfläche entsteht neu – mit echtem nativem Verhalten.
Beispiele aus der Praxis
Mitglieder-App aus bestehendem Portal → Capacitor
Das responsive Web-Portal existiert und wird laufend gepflegt. Als App verpackt, mit Push-Nachrichten ergänzt – nach wenigen Wochen in den Stores.
Lern-App mit Offline-Modus → React Native
Tausende Übungsaufgaben, flüssiges Blättern, Offline-Synchronisation, lange Nutzungssitzungen – hier zahlt sich die native Oberfläche jeden Tag aus.
Alternde Ionic-App → schrittweise Portierung
Eine gewachsene Cordova/Ionic-App stößt an Performance-Grenzen. Die Logik wird übernommen, die Oberfläche in React Native neu aufgebaut – App-Store-Historie und Nutzer bleiben erhalten.
Häufige Fragen zu Capacitor vs. React Native
Merkt der Nutzer den Unterschied wirklich?
Bei einfachen Apps: kaum. Je interaktiver die App (lange Listen, Gesten, Animationen), desto eher spürt man die WebView – als minimal verzögertes, leicht „webbiges“ Verhalten. Für Apps, die täglich und lange genutzt werden, summiert sich dieser Qualitätsunterschied.
Akzeptiert Apple WebView-Apps im App Store?
Ja – solange die App echten Mehrwert gegenüber einer reinen Website bietet (z. B. Push, Offline-Funktionen, Gerätezugriffe). Reine „Website im Rahmen“-Apps ohne Zusatznutzen werden gelegentlich abgelehnt; das betrifft aber lieblose Verpackungen, keine ordentlich gebauten Capacitor-Apps.
Was ist mit Flutter?
Flutter (von Google) ist der dritte große Cross-Platform-Ansatz: Er zeichnet die Oberfläche komplett selbst und ist technisch stark. Er nutzt allerdings die Sprache Dart – das Web-Know-how (JavaScript/React) lässt sich nicht wiederverwenden. Für Teams mit React-Hintergrund ist React Native meist der konsequentere Weg.
Kann man von Capacitor zu React Native wechseln?
Ja – als Portierung: Geschäftslogik, API-Anbindung und Datenmodelle lassen sich oft übernehmen, die Oberfläche wird neu gebaut. Der App-Store-Eintrag bleibt dabei erhalten, Nutzer bekommen die neue Version als normales Update.
