Native App oder Cross-Platform – was ist das Richtige für dich?

Native App oder Cross-Platform – das ist die erste große Weichenstellung, sobald du eine App entwickeln lassen willst. Sie entscheidet mit über Budget, Geschwindigkeit, Wartung und darüber, wie gut sich deine App am Ende anfühlt. Die ehrliche Kurzantwort: Es gibt keine pauschal richtige Wahl, sondern eine, die zu deinem Vorhaben passt. Schauen wir uns an, wann sich was lohnt.

Native oder Cross-Platform – was ist das Richtige für mich? Fünf Fragen

Kurzantwort: Cross-Platform (z. B. React Native oder Flutter) ist für die große Mehrheit der Business-Apps richtig – überall dort, wo du iOS und Android mit einem Budget bedienen willst und die App vor allem Inhalte, Formulare und Standard-Funktionen abbildet. Nativ (SwiftUI für iOS, Kotlin für Android) ist richtig, wenn nur eine Plattform wirklich zählt oder deine App tief im Betriebssystem sitzt.

Welche der beiden Beschreibungen auf dich passt, klärst du in zwei Minuten mit diesen fünf Fragen:

1. Brauchst du wirklich beide Plattformen? Wenn dein Publikum praktisch komplett auf iOS unterwegs ist oder du eine interne App nur für dienstliche iPhones baust, fällt der größte Vorteil von Cross-Platform weg – dann ist nativ die sauberere Wahl.
2. Was macht die App im Kern? Listen, Formulare, Buchungen, Kundenportal: Cross-Platform. Aufwendige Animationen, Dauerbetrieb von Kamera oder Sensorik, Spiele: nativ.
3. Wie tief sitzt dein wichtigstes Feature im System? Widgets, Live Activities, Sperrbildschirm, Hintergrund-Übertragungen, Systemsuche, Teilen-Menü, Dateien-App – je mehr davon du brauchst, desto eher nativ.
4. Wie schnell musst du live sein? Wenn du ein Marktfenster hast oder eine Idee als MVP testest, ist eine Codebasis auf zwei Stores der schnellere Weg.
5. Wer pflegt die App in drei Jahren – und womit? Zwei native Codebasen heißen zwei Wartungsverträge, zwei Testrunden, zwei Release-Zyklen. Das ist der Posten, der die Entscheidung am häufigsten kippt.

Antwortest du bei drei oder mehr Fragen im Sinne von „beide Plattformen, Standard-Funktionen, schnell live“, brauchst du nicht weiterzulesen: Cross-Platform. Bei allem anderen lohnen sich die Details – die gehen wir jetzt durch.

Was bedeutet native, was bedeutet Cross-Platform?

Native Entwicklung heißt: Du baust die App genau für ein Betriebssystem, mit dessen eigenen Werkzeugen. Für iOS ist das heute meist SwiftUI (Apples modernes Oberflächen-Framework), für Android Kotlin mit Jetpack Compose. Willst du beide Plattformen nativ, baust du im Grunde zwei Apps – mit zwei Codebasen.

Cross-Platform (auch plattformübergreifend) heißt: Du schreibst den Code einmal und lässt ihn auf iOS und Android laufen. Die verbreitetsten Ansätze sind React Native (auf JavaScript/TypeScript-Basis, eng verwandt mit der Web-Welt) und Flutter (Googles Framework auf Basis der Sprache Dart). Eine Codebasis, zwei Stores.

Wichtig zu wissen: Cross-Platform heißt nicht „Web-App im Mantel“. Moderne Frameworks erzeugen echte App-Oberflächen mit nativen Bausteinen. Der Unterschied zu nativ ist heute deutlich kleiner als noch vor einigen Jahren.

Kosten: der offensichtlichste Hebel

Hier ist der Unterschied am greifbarsten. Native iOS und Android bedeutet zwei getrennte Umsetzungen – grob gesagt zahlst du vieles doppelt: zwei Codebasen, oft zwei Spezialisten, zwei Testrunden. Cross-Platform teilt sich den Großteil des Codes und spart damit spürbar.

Rechne es an unserer eigenen Preisliste nach, dann brauchst du keine Prozent-Daumenregel: Ein App-MVP startet bei 7.900 €. Soll dieselbe App auf beiden Plattformen laufen, kommen 3.900 € dazu – zusammen 11.800 €. Zwei getrennt gebaute native Apps sind dagegen zweimal der volle Aufwand. Der Unterschied liegt also grob bei einem Viertel bis einem Drittel, und er wächst mit jeder Folgeversion: Gepflegt wird eine Codebasis statt zweier, die Betreuung läuft einmal ab 149 €/Monat statt doppelt.

Eine wichtige Einschränkung: Brauchst du ohnehin nur eine Plattform – etwa eine reine iOS-App für ein Apple-lastiges Publikum –, fällt dieser Kostenvorteil weg. Dann ist nativ oft die saubere Wahl, weil du dir die Abstraktionsschicht des Frameworks sparst.

Wie sich die Kosten im Detail zusammensetzen, haben wir separat aufgeschlüsselt – dieser Artikel bleibt bei der Grundsatzentscheidung Technik.

Performance: zählt sie für dich überhaupt?

Native Apps haben theoretisch die Nase vorn: Sie sprechen direkt mit dem Betriebssystem, ohne Zwischenschicht. Bei sehr grafiklastigen Apps, flüssigen 60-/120-fps-Animationen, aufwendiger Echtzeit-Verarbeitung oder Spielen ist dieser Vorsprung real und spürbar.

Für die meisten Geschäfts-Apps gilt aber: Der Performance-Unterschied ist im Alltag kaum bemerkbar. Eine Buchungs-App, ein Kundenportal, ein Bestell- oder Service-Tool fühlt sich mit React Native oder Flutter genauso flüssig an wie nativ. Hier zahlst du für native Performance einen Aufpreis, den der Nutzer nie merkt.

Die ehrliche Frage lautet also nicht „Was ist schneller?“, sondern „Merkt mein Nutzer den Unterschied?“. Bei klassischen Business-Apps: meistens nicht.

Zugriff auf Gerätefunktionen

Kamera, GPS, Push-Nachrichten, Bluetooth, Face ID, NFC – die meisten Standard-Gerätefunktionen sind in Cross-Platform-Frameworks längst gut abgedeckt, über fertige Module oder Plugins.

Native ist im Vorteil, sobald es um brandneue oder sehr spezielle Funktionen geht:

• Ein neues iOS-Feature, das Apple gerade erst vorgestellt hat, ist nativ sofort verfügbar – im Cross-Platform-Framework manchmal erst Wochen später.
• Tiefe, ungewöhnliche Hardware-Integration (etwa exotische Sensoren oder Spezial-Peripherie).
• Komplexe Hintergrundverarbeitung, die eng am Betriebssystem hängt.

Der gute Mittelweg: Auch in einer Cross-Platform-App lassen sich einzelne, kritische Stellen nativ ergänzen. Du musst dich also nicht zu 100 Prozent festlegen.

Warum unsere eigene App nativ ist – und wann wir es nicht täten

Die ehrlichste Antwort auf „Was ist das Richtige für mich?“ ist keine Tabelle, sondern eine Entscheidung, die jemand selbst getroffen und bezahlt hat. Unsere eigene iOS-App WebDAV Browser ist komplett nativ in SwiftUI gebaut. Der Grund dafür steht in ihrer Funktionsliste – die liest sich nämlich wie eine Liste von System-Integrationen:

• Der Index-Fortschritt läuft als Live Activity auf dem Sperrbildschirm und im Dynamic Island, inklusive Restzeit.
• Uploads laufen im Hintergrund weiter, auch wenn die App geschlossen ist – das ist Betriebssystem-Terrain, kein UI-Thema.
• Die Texterkennung läuft auf dem Gerät, und die Treffer tauchen anschließend in der Spotlight-Suche des iPhones auf.
• Passwörter liegen ausschließlich im iCloud-Keychain, Verbindungen wandern per CloudKit zwischen iPhone und iPad.
• Dazu Share-Extension, Dokumentenscanner, QuickLook-Viewer, iPad-SplitView, Zertifikats-Pinning auf Netzwerkebene.

In einem Cross-Platform-Framework wäre jeder dieser Punkte eine eigene Brücke zu nativem Code. Man schreibt den nativen Teil dann trotzdem – nur zusätzlich zum Framework darüber. Dazu kam der zweite, viel banalere Grund: Eine Android-Version war nicht geplant. Damit fiel der stärkste Vorteil von Cross-Platform weg, bevor die Diskussion überhaupt anfing.

Und wann hätten wir es nicht getan? Wenn dieselbe App auch auf Android laufen müsste und im Kern aus Listen, Formularen und Uploads bestünde, wäre eine gemeinsame Codebasis die vernünftigere Wahl gewesen – auch für uns. Die Entscheidung folgt der Funktionsliste, nicht der Vorliebe.

Time-to-Market: wie schnell musst du live sein?

Wenn Geschwindigkeit zählt – etwa weil du eine Produktidee testen willst oder ein Marktfenster nutzen musst –, spielt Cross-Platform seine größte Stärke aus. Eine Codebasis bedeutet: Du bist auf iOS und Android gleichzeitig live, ohne zwei Entwicklungsstränge synchron halten zu müssen.

Für ein MVP (die schlanke erste Version, die echtes Nutzerfeedback bringt) ist das oft der entscheidende Faktor. Du willst herausfinden, ob die Idee trägt – nicht das letzte Quäntchen Performance herauskitzeln. Geht die App durch die Decke, kannst du später immer noch gezielt einzelne Teile nativ nachschärfen.

Wartung: der Posten, den viele vergessen

Eine App ist nie „fertig“. Apple und Google bringen jedes Jahr neue Betriebssystem-Versionen, neue Geräte, neue Store-Anforderungen. Jede dieser Änderungen will gepflegt sein.

Und genau hier wird die Rechnung interessant: Zwei native Codebasen heißen auch doppelte Wartung. Jedes Update, jeder Bugfix, jede neue Funktion muss zweimal gebaut und getestet werden. Cross-Platform pflegst du an einer Stelle – das senkt die laufenden Kosten über die gesamte Lebensdauer der App spürbar, oft stärker als die Ersparnis bei der Erstentwicklung.

Rechne es einmal nach, statt es zu glauben: Unsere App-Betreuung startet bei 149 €/Monat, das sind 1.788 € im Jahr. Über vier Jahre summiert sich allein die Pflege auf eine Größenordnung, die dem Preis eines MVP nahekommt – und bei zwei getrennten nativen Codebasen fällt sie in Teilen doppelt an. Wer die Wartung von Anfang an einrechnet, entscheidet sich häufiger für Cross-Platform, aus rein wirtschaftlichen Gründen.

Native vs. Cross-Platform im direkten Vergleich

Das Backend nicht vergessen

Eine Sache nimmt dir die Entscheidung zwischen nativ und Cross-Platform nicht ab: Sobald Nutzer sich anmelden, Daten zwischen Geräten synchronisiert oder Push-Nachrichten verschickt werden, braucht es ein Backend. Und dessen Aufwand ist in beiden Welten identisch – der Server merkt nicht, ob die Anfrage aus SwiftUI oder aus React Native kommt.

Praktisch heißt das zweierlei. Erstens: Vergleiche Angebote nie über die App-Technik allein, wenn im einen das Backend steckt und im anderen nicht. Zweitens: Wenn die Schnittstelle sauber definiert ist, bleibt die Frontend-Entscheidung revidierbar. Genau deshalb schneiden wir die API bewusst frontend-neutral – ein Backend überlebt in der Regel die erste App-Generation, und niemand will das Fundament neu bauen, nur weil sich die Technik davor ändert. Wie so eine Schnittstelle aussieht, haben wir hier ausführlicher beschrieben: API-Schnittstellen: Systeme verbinden.

Unsere ehrliche Empfehlung je Szenario

• Du willst iOS und Android, klassische Business-App, begrenztes Budget: Cross-Platform (React Native oder Flutter). Bestes Verhältnis aus Kosten, Tempo und Qualität.
• Du testest eine Idee, willst schnell ein MVP: Cross-Platform. Schnell live, später gezielt nachschärfbar.
• Nur eine Plattform ist wirklich wichtig (z. B. iOS): Nativ mit SwiftUI ist oft die saubere, wartungsarme Wahl – der Cross-Platform-Vorteil greift hier nicht.
• Performance, Animationen, Spiele, tiefe Hardware-Integration: Nativ. Hier zahlt sich der Aufwand spürbar aus.
• Du bist unsicher: Dann hilft ein Konzept-Gespräch mehr als jede Faustregel. Die Antwort hängt an deinen konkreten Funktionen und deinem Ziel – nicht an einer Mode. Wie wir dabei gemeinsam vorgehen, kannst du dir vorab ansehen.

Du merkst: Wir verkaufen dir hier keine Lieblingstechnik. Unsere eigene App ist nativ – und für eine klassische Business-App auf beiden Plattformen würden wir dir trotzdem zu einer gemeinsamen Codebasis raten. Es entscheidet die Funktionsliste, nicht die Gewohnheit.

Genau darüber reden wir am liebsten, bevor der erste Euro fließt: Schick uns deine Must-have-Funktionen, und wir sagen dir in einem kostenlosen Erstgespräch, welcher Weg in deinem Fall der günstigere ist – inklusive der unbequemen Variante „dafür braucht ihr eigentlich gar keine App“. Wenn du dir vorher noch eine Zahl dazuholen willst, findest du sie in unserem Kostenüberblick: App entwickeln lassen – Kosten.

Häufige Fragen