Native oder Cross-Platform? Eine ehrliche Entscheidungshilfe für 2026

Kaum eine Frage begegnet uns in Erstgesprächen so oft wie diese: „Sollen wir nativ entwickeln oder Cross-Platform?" Und kaum eine Frage wird so oft mit Glaubensbekenntnissen statt mit Argumenten beantwortet. Wir haben in den letzten Jahren beides ausgeliefert: native Apps in Swift und Kotlin ebenso wie Cross-Platform-Projekte mit React Native und Expo. Hier ist die Antwort, die wir auch unseren Kunden geben.

Die kurze Antwort

Es gibt keinen Gewinner. Es gibt nur eine passende Wahl für Ihr Produkt, Ihr Team und Ihr Budget. Wer Ihnen pauschal „immer nativ" oder „immer React Native" empfiehlt, verkauft Ihnen meist das, was er selbst am besten kann, nicht das, was Ihr Projekt braucht.

Wann Cross-Platform gewinnt

React Native mit Expo ist 2026 erwachsen. Die New Architecture ist Standard, Over-the-Air-Updates sind produktionsreif, und der Werkzeugkasten rund um EAS nimmt einem viel Infrastrukturarbeit ab. Cross-Platform ist unsere Empfehlung, wenn:

• Die App im Kern Inhalte, Formulare und Abläufe abbildet. Das trifft auf die meisten Business- und B2B-Apps zu. Listen, Detailansichten, Eingabemasken, Push-Nachrichten: Dafür braucht niemand zwei getrennte Codebasen.
• Time-to-Market zählt. Eine Codebasis, ein Team, ein Release-Prozess. Gerade für MVPs und Produkte, deren Markt noch validiert wird, ist das ein echter Vorteil.
• Das Budget zwei native Teams nicht hergibt. Zwei Plattformen nativ zu pflegen kostet dauerhaft fast das Doppelte: nicht nur bei der Entwicklung, sondern über Jahre der Wartung.
• Web ohnehin geplant ist. Wer React im Haus hat, kann Wissen, Komponenten und teils sogar Code wiederverwenden.

Wann Nativ gewinnt

Swift und Kotlin bleiben die richtige Wahl, wenn die App tief in die Plattform greift:

• Bluetooth, Hintergrundprozesse, Sensorik. Wir haben jahrelang Apps für schlüssellosen Fahrzeugzugang über Bluetooth LE entwickelt. Solche Projekte leben von präziser Kontrolle über das Verhalten im Hintergrund. Jede Abstraktionsschicht dazwischen kostet Verlässlichkeit.
• Höchste Ansprüche an UI und Haptik. Wenn sich die App zu 100 % nach iOS beziehungsweise Android anfühlen soll, inklusive der neuesten Plattformfunktionen am Erscheinungstag, führt kein Weg an SwiftUI und Jetpack Compose vorbei.
• Rechenintensive Aufgaben. Audio-Verarbeitung, Bildanalyse, Echtzeit-Rendering: Hier zählt jede Millisekunde, und nativer Code ist im Vorteil.
• Nur eine Plattform geplant ist. Wer ohnehin nur iOS bedient, verschenkt mit Cross-Platform den Hauptvorteil und bezahlt trotzdem die Abstraktionskosten.

Die Fragen, die wirklich entscheiden

Statt über Frameworks zu diskutieren, stellen wir in Projekten drei Fragen:

1. Welche Plattformfunktionen braucht das Produkt in zwei Jahren? Nicht nur heute. Ein späterer Wechsel des Ansatzes ist teuer.
2. Wer wartet die App langfristig? Ein internes Team mit React-Erfahrung spricht für React Native. Ein iOS-Team spricht für Swift.
3. Was kostet ein Fehler? Bei einer Content-App ist ein UI-Glitch ärgerlich. Bei einer App, die Autos aufschließt, ist Zuverlässigkeit nicht verhandelbar.

Unser Fazit

Für die Mehrheit der Business-Apps, die uns 2026 begegnen, ist React Native mit Expo die wirtschaftlich vernünftige Wahl. Die Technologie ist reif, das Ökosystem stabil, die Einsparung real. Sobald aber Hardware-Nähe, Hintergrund-Zuverlässigkeit oder kompromissloses Plattform-Gefühl gefordert sind, entwickeln wir nativ und haben das noch nie bereut.

Wenn Sie unsicher sind, wo Ihr Projekt steht: Fragen Sie uns. Wir haben beide Wege oft genug zu Ende gegangen, um Ihnen eine ehrliche Einschätzung zu geben, auch wenn sie „es kommt darauf an" lautet. Dann wenigstens mit einer klaren Begründung, worauf genau.