Native oder Cross-Platform-App 2026: welche Variante passt?

Was unterscheidet native von Cross-Platform-Entwicklung?

Native Entwicklung schreibt für jede Plattform eigenen Code: Swift mit SwiftUI für iOS, Kotlin mit Jetpack Compose für Android. Cross-Platform bedient beide Systeme aus einer Codebasis, mit React Native, Flutter oder Kotlin Multiplatform. Welche Variante passt, entscheiden Hardwarezugriff, Budget und Zeitplan. Eine generell bessere Option gibt es nicht.

Die Debatte wird oft geführt, als ginge es um Glaubensfragen. Sie geht aber um Kosten pro Codebasis, um API-Verfügbarkeit und um die Frage, wie nah Ihre App an der Hardware arbeitet. Wir gehen die Kriterien entlang der Zahlen durch, die wir belegen können, und sagen dazu, wo die Zahlen aus eigener Projekterfahrung stammen statt aus einem Labortest.

Was bedeutet native App-Entwicklung 2026?

Nativ heißt: Die App entsteht in der Sprache und mit dem Framework der jeweiligen Plattform. iOS bekommt Swift und SwiftUI, Android bekommt Kotlin und Jetpack Compose. Jede Plattform hat ihre eigene Codebasis, ihr eigenes Team und ihren eigenen Release-Zyklus. Der Zugriff auf neue Betriebssystem-Funktionen ist am ersten Tag verfügbar.

iOS: Swift und SwiftUI

• SwiftUI beschreibt die Oberfläche deklarativ aus dem Zustand heraus statt über imperative Anweisungen
• Direkter Zugriff auf HealthKit, ARKit, CallKit sowie App Intents, ohne Wrapper-Bibliothek dazwischen
• Xcode und Instruments gehören zu den stärksten Profiling-Werkzeugen, die es für mobile Entwicklung gibt
• visionOS-Entwicklung für die Apple Vision Pro läuft ebenfalls über SwiftUI, das Wissen überträgt sich also

Android: Kotlin und Jetpack Compose

• Kotlin bringt Null-Safety, Koroutinen und Erweiterungsfunktionen mit, was den Wartungsaufwand gegenüber altem Java-Code senkt
• Jetpack Compose folgt derselben deklarativen Idee wie SwiftUI und ist der empfohlene Weg für neue Android-Oberflächen
• Vollständiger API-Zugriff auf Kamera, Sensorik, Bluetooth und NFC

Der eigentliche Nachteil des nativen Wegs ist organisatorisch. Zwei Codebasen heißen zwei Backlogs, zwei Releasepläne und zwei Stellen, an denen dieselbe Fachlogik implementiert wird. Abweichungen zwischen iOS- und Android-Version entstehen dabei nicht aus Nachlässigkeit, sondern zwangsläufig, sobald die Teams unterschiedlich schnell arbeiten. Wir haben Projekte gesehen, in denen genau diese Divergenz mehr Aufwand erzeugt hat als die gesamte Framework-Diskussion davor.

Welche Cross-Platform-Frameworks sind 2026 relevant?

Drei Ansätze bestimmen das Feld. React Native rendert echte native Komponenten aus JavaScript oder TypeScript. Flutter bringt eine eigene Rendering-Engine mit und zeichnet die Oberfläche selbst. Kotlin Multiplatform teilt nur die Logik und lässt die Oberfläche nativ. Webview-Wrapper spielen im Geschäftsumfeld praktisch keine Rolle mehr.

React Native

Die New Architecture aus JSI, Fabric und TurboModules hat die alte Bridge abgelöst und ist seit Version 0.82 der einzige unterstützte Modus. Damit fällt die serialisierte Kommunikation zwischen JavaScript und nativer Seite weg, die früher für Ruckler in langen Listen verantwortlich war. Dazu kommt das Expo-Ökosystem mit EAS Build und dateibasiertem Routing.

Flutter

Flutter zeichnet jedes Pixel selbst. Die Impeller-Engine kompiliert Shader vorab, wodurch das früher typische Ruckeln beim ersten Aufruf einer Animation entfällt. Der Preis dafür: Die App sieht auf beiden Plattformen gleich aus, nicht plattformtypisch. Für eine Marke mit striktem Design-System ist das ein Vorteil, für eine App, die sich wie Teil des Betriebssystems anfühlen soll, ein Nachteil.

Kotlin Multiplatform

KMP von JetBrains geht den umgekehrten Weg: Netzwerkschicht, Persistenz und Zustandsverwaltung liegen im gemeinsamen Kotlin-Modul, die Oberfläche bleibt SwiftUI beziehungsweise Jetpack Compose. Google unterstützt KMP offiziell. Der große praktische Vorteil ist die schrittweise Einführung: Sie können ein bestehendes natives Projekt Modul für Modul umstellen, ohne es neu zu schreiben.

Wie schneiden beide Ansätze im Vergleich ab?

Nativ gewinnt bei Rohleistung, API-Aktualität und Binärgröße. Cross-Platform gewinnt bei Entwicklungsdauer, Wartungsaufwand und Verfügbarkeit von Entwicklern. Alle übrigen Kriterien hängen vom konkreten Projekt ab und lassen sich nicht allgemein entscheiden. Die folgende Tabelle fasst zusammen, worin sich die beiden Wege in einem typischen Geschäftsprojekt tatsächlich unterscheiden.

Was sagen die Performance-Zahlen?

Die folgenden Größenordnungen stammen aus unseren eigenen Messungen an Geschäftsanwendungen auf Mittelklasse-Geräten, nicht aus einem standardisierten Benchmark. Wir veröffentlichen sie als Orientierung und nicht als Laborwerte, weil es für diese Frage keinen allgemein anerkannten öffentlichen Testaufbau gibt.

Eine tiefere Gegenüberstellung der beiden großen Frameworks finden Sie im Beitrag React Native oder Flutter.

Was kostet der Unterschied in Euro?

Eine geteilte Codebasis senkt die Erstentwicklungskosten nach unserer Erfahrung um 30 bis 50 Prozent. Der Effekt entsteht nicht durch das Framework, sondern durch die Halbierung von Codebasis, Testmatrix und Wartungsstrang. Die folgenden Spannen sind unsere veröffentlichten Projektpreise für mobile Anwendungen.

Die Ersparnis verteilt sich nicht gleichmäßig. Beim Backend ändert sich nichts, weil es ohnehin geteilt wird. Beim Design fällt der Vorteil klein aus, weil ein Screen einmal entworfen und dann für zwei Plattformen angepasst wird. Der Löwenanteil entsteht in der Implementierung der Fachlogik und im Testen. Deshalb sinkt der Effekt bei Apps mit vielen plattformeigenen Funktionen deutlich: Was Sie zweimal schreiben müssen, sparen Sie auch nicht einmal.

Das Stundenniveau erklärt, warum die Entscheidung in Deutschland schwerer wiegt als in einem Niedrigpreismarkt. Jede zusätzliche Codebasis kostet Stunden, und eine Entwicklerstunde liegt hier im Freelancer-Median bei 90 EUR in der Softwareentwicklung. Als Agenturpreis taugt diese Zahl nicht, als Größenordnung für den Eigenaufwand schon. Die vollständige Aufschlüsselung nach Posten steht im Beitrag Was kostet eine App 2026 und in unserer Preisübersicht.

Wann ist native Entwicklung die richtige Wahl?

Nativ lohnt sich, wenn die App tief in die Hardware greift, wenn jede Millisekunde zählt oder wenn Sie ohnehin nur eine Plattform bedienen. In diesen Fällen verschwindet der Kostenvorteil der geteilten Codebasis, weil Sie den plattformspezifischen Teil trotzdem schreiben müssen.

Hardwarenahe Anwendungen

Intensive Nutzung von Kamera, Sensorik, Bluetooth Low Energy, NFC oder ARKit und ARCore spricht klar für nativ. Typische Beispiele sind AR-Vermessung, Gesundheitsanwendungen mit HealthKit oder Health Connect sowie IoT-Bedienoberflächen.

Spiele und aufwendige Animationen

Metal unter iOS und Vulkan unter Android liefern Zugriffe, die kein Abstraktionslayer vollständig nachbildet. Flutter hat hier stark aufgeholt, gewinnt aber bei grafikintensiven Titeln nicht. Für ein Spiel mit eigener Physik oder aufwendigen Partikeleffekten führt der Weg ohnehin eher über eine Engine wie Unity oder Unreal als über eine App-Framework-Entscheidung.

Plattformgebundene Erlebnisse

Eine Apple-Watch-Begleit-App, eine CarPlay-Integration oder eine Android-Automotive-Anwendung sind an das jeweilige Ökosystem gebunden. Hier ist nativ nicht die bessere, sondern die einzige sinnvolle Option.

Nur eine Zielplattform

Ein internes iPad-Werkzeug für den Außendienst braucht keine Android-Version. Ohne zweite Plattform gibt es nichts zu teilen, und der Hauptvorteil von Cross-Platform entfällt.

Wann ist Cross-Platform die bessere Entscheidung?

Cross-Platform passt, wenn die App vor allem Daten darstellt, Formulare verarbeitet und mit Backend-Systemen spricht. Das trifft auf den größten Teil der Geschäftsanwendungen zu. Je weiter Ihre App von der Hardware entfernt arbeitet, desto geringer wird der Preis, den Sie für die geteilte Codebasis zahlen.

Geschäftsanwendungen

CRM-Clients, ERP-Oberflächen, Shops und interne Kommunikationstools brauchen keine native Rohleistung. Sie brauchen verlässliche Synchronisierung, saubere Rechteverwaltung und schnelle Änderungen. Der Engpass liegt in diesen Projekten fast nie im Rendering, sondern in der Anbindung an das führende System dahinter. Wer hier native Performance als Auswahlkriterium setzt, optimiert die falsche Stelle.

MVP und Marktvalidierung

Wenn Sie prüfen wollen, ob ein Produkt Nachfrage findet, ist die Geschwindigkeit wichtiger als das letzte Prozent Bildrate. Ein MVP liegt bei uns bei sechs bis zehn Wochen für beide Plattformen. Zwei native Teams brauchen für denselben Umfang typischerweise das Doppelte.

Begrenztes Budget

Die Ersparnis wirkt zweimal: einmal beim Bau, dann jedes Jahr erneut bei der Wartung. Deshalb bauen wir die Mehrheit unserer mobilen Anwendungen auf einer geteilten Codebasis.

Schnelle Iteration über Over-the-Air-Updates

Mit React Native und Expo EAS Update liefern Sie JavaScript-Änderungen an installierte Apps aus, ohne auf eine erneute Store-Prüfung zu warten. Für Logik, die sich häufig ändert, ist das der stärkste operative Vorteil des Ansatzes. Native Module bleiben davon ausgenommen.

Wie entscheiden Sie in fünf Fragen?

Fünf Fragen führen in den meisten Fällen zu einer belastbaren Vorauswahl zwischen nativer und geteilter Codebasis. Sie ersetzen kein Architekturgespräch, grenzen den Möglichkeitsraum aber innerhalb weniger Minuten ein. Beantworten Sie die Fragen in der angegebenen Reihenfolge, denn die erste Bejahung beendet die Kette und legt die Antwort bereits fest.

1. Braucht die App intensiven Hardwarezugriff? Ja: nativ. Nein: weiter.
2. Ist Rohleistung kritisch, etwa bei Spielen, AR oder Echtzeitverarbeitung? Ja: nativ. Nein: weiter.
3. Zielen Sie nur auf eine Plattform? Ja: nativ, weil es nichts zu teilen gibt. Nein: weiter.
4. Muss die Oberfläche plattformtypisch wirken? Ja: React Native oder KMP. Nein: Flutter ist eine gute Wahl.
5. Schnelles MVP oder langlebiges Produkt? MVP: React Native mit Expo. Langlebig: KMP oder Flutter.

Ehrlich gesagt landen die meisten Anfragen, die uns aus dem deutschen Mittelstand erreichen, schon nach Frage zwei bei Cross-Platform. Das liegt nicht an einer Vorliebe, sondern an der Art der Projekte: interne Werkzeuge, Kundenportale, Auftrags- und Serviceanwendungen. Wo die Antwort anders ausfällt, ist sie meist eindeutig, etwa bei einer App zur Steuerung eigener Geräte über Bluetooth.

Welche Annahmen über Cross-Platform stimmen nicht mehr?

Drei Einwände gegen geteilte Codebasen hören wir in Vorgesprächen fast immer. Alle drei hatten um 2018 herum ihre Berechtigung, und alle drei sind heute entweder technisch überholt oder falsch zugeordnet. Wir gehen sie einzeln durch, weil sie in internen Entscheidungsvorlagen bis heute unverändert auftauchen.

Lohnt sich ein hybrider Ansatz?

Für komplexere Produkte oft ja. Der hybride Weg teilt die Geschäftslogik über KMP oder ein React-Native-Modul und baut die Oberfläche nativ mit SwiftUI beziehungsweise Jetpack Compose. Hardwarenahe Funktionen bekommen eigene Plattformmodule. Sie behalten native UI-Qualität und teilen trotzdem einen erheblichen Teil des Codes.

Der Preis dieses Modells ist organisatorisch, nicht technisch: Sie brauchen Entwickler, die beide Welten kennen, und eine klare Regel, was in die gemeinsame Schicht darf. Wo diese Regel fehlt, entsteht genau die Vermischung, die geteilte Codebasen in Verruf gebracht hat.

Für einfache, inhaltsgetriebene Anwendungen ist außerdem eine Progressive Web App eine ernsthafte Option. Die Abgrenzung haben wir im Beitrag PWA oder native App aufgeschrieben.

Worauf achten deutsche Einkäufer über die Technik hinaus?

Im Beschaffungsprozess ist die Framework-Wahl selten der Knackpunkt. Entscheidend sind der Auftragsverarbeitungsvertrag, der Ort der Datenverarbeitung, die Übergabe des Quellcodes samt Signaturschlüsseln und die Vertragsform. Wer diese vier Punkte im Angebot offen lässt, verliert regelmäßig gegen den Anbieter, der sie schriftlich beantwortet.

Datenverarbeitung und SDK-Ketten

Die Technologiewahl berührt den Datenschutz an einer Stelle, die in Angeboten fast immer fehlt: bei den Drittanbieter-SDKs. Ein Expo-Projekt bringt Build-, Update- und Absturzberichtsdienste mit, ein Flutter-Projekt eigene Analytics-Pakete. Jedes dieser SDKs ist ein möglicher Datenempfänger und gehört in das Verzeichnis von Verarbeitungstätigkeiten. Wir listen deshalb im Angebot auf, welche Dienste eine App im Betrieb tatsächlich kontaktiert, damit Ihre Datenschutzabteilung nicht raten muss. Der Auftragsverarbeitungsvertrag nach Art. 28 DSGVO gehört bei uns zum Standardpaket und nicht zu den Zusatzposten.

Quellcode und Vertragsform

Der Quellcode liegt nach Projektende in einem Repository unter Ihrer Kontrolle, samt Build-Pipeline und Signaturschlüsseln. Bei einer geteilten Codebasis ist diese Übergabe leichter zu prüfen als bei zwei getrennten nativen Projekten, weil es weniger bewegliche Teile gibt: ein Repository, eine Pipeline, ein Abhängigkeitsbaum. Bei der Vertragsform arbeiten wir mit einem Werkvertrag für klar abgegrenzte Bauabschnitte und mit einem Dienstvertrag für die laufende Weiterentwicklung. Ein Produkt, das sich über Monate verändert, lässt sich schwer als geschlossenes Werk beschreiben, und so zu tun, als ginge das, erzeugt später Streit über Nachträge.

Warum die Codebasis-Frage in Deutschland teurer wiegt

Der Medianstundensatz für Softwareentwicklung im DACH-Raum liegt laut Freelancer-Kompass 2026 bei 90 EUR, über alle IT-Bereiche hinweg bei 95 EUR. Deutsche Marktübersichten beziffern die Ersparnis durch Nearshoring konsistent mit 30 bis 50 Prozent. Beide Effekte multiplizieren sich: Eine zweite Codebasis kostet Stunden, und jede Stunde ist im deutschen Markt teuer. Wir arbeiten aus Budapest, also in Ihrer Zeitzone und im selben Rechtsraum, was die Abstimmung über eine geteilte Codebasis praktikabel hält.

Was bleibt als Entscheidungsgrundlage?

Zwei Fragen tragen die Entscheidung: Wie tief greift die App in die Hardware, und wie viele Plattformen bedienen Sie wirklich? Fällt die Antwort auf beides unauffällig aus, gewinnt die geteilte Codebasis über die Wartungskosten. Bleibt eine der beiden Antworten anspruchsvoll, rechnet sich nativ trotz höherem Erstaufwand.

Wenn Sie unsicher sind, welcher Weg zu Ihrem Vorhaben passt: Schicken Sie uns die Anforderungen über das Angebotsformular. Wir antworten innerhalb von 24 Stunden mit einer Empfehlung samt Begründung, und wir sagen auch dann, wenn native Entwicklung die richtige Antwort ist.