Die Entscheidung zwischen nativer und Cross-Platform-Entwicklung gehört zu den ersten in jedem Mobile-Projekt. Sie prägt Budget, Teamaufbau, Release-Tempo und das, was die App leisten kann, auf Jahre hinaus. Eine allgemein richtige Antwort gibt es nicht. Der passende Ansatz hängt davon ab, was Ihre App auf dem Gerät können muss, wer sie pflegen wird und wie schnell Sie sowohl iOS als auch Android erreichen müssen. Dieser Leitfaden zeigt, wie Sie auf Grundlage von Fakten entscheiden statt nach Vorliebe.
Was bedeuten „nativ“ und „Cross-Platform“ eigentlich?
Eine native App wird für jede Plattform getrennt entwickelt, mit den Werkzeugen des jeweiligen Plattformanbieters: Swift und SwiftUI für iOS, Kotlin und Jetpack Compose für Android. Am Ende haben Sie zwei Codebasen, jede mit vollem und unmittelbarem Zugriff auf alles, was das Betriebssystem bietet.
Eine Cross-Platform-App wird einmal in einem Framework wie Flutter oder React Native geschrieben und zu echten Apps für beide Stores kompiliert. Der überwiegende Teil des Codes wird geteilt; plattformspezifisch sind nur kleine Teile, wo es nötig ist. Kotlin Multiplatform liegt dazwischen: Die Geschäftslogik wird geteilt, die Oberfläche bleibt auf beiden Seiten nativ.
Keines von beiden ist eine Website in einer Hülle. Beide Wege führen zu installierbaren Apps, die die Store-Prüfung bestehen, Push-Benachrichtigungen senden und offline funktionieren, wenn sie dafür ausgelegt sind.
Nativ oder Cross-Platform: So entscheiden Sie für Ihre App
Gehen Sie vom Produkt aus, nicht von der Technologie. Beantworten Sie diese Fragen ehrlich, bevor jemand ein Framework vorschlägt:
- Was macht die App auf dem Gerät? Formulare, Listen, Inhalte, Buchungen und Zahlungen lassen sich mit beiden Ansätzen gut umsetzen. Intensive Kameranutzung, Augmented Reality, komplexe Bluetooth-Geräte oder Hintergrundverarbeitung sprechen eher für nativ.
- Brauchen Sie vom ersten Tag an beide Plattformen? Verteilt sich Ihre Zielgruppe auf iOS und Android, bringt Sie eine gemeinsame Codebasis mit einem einzigen Team auf beide.
- Wer wird die App pflegen? Das Team, das die App über Jahre betreut, ist wichtiger als das Team, das sie auf den Markt bringt.
- Wie oft wird sie sich ändern? Produkte mit häufigen Updates profitieren davon, jede Funktion nur einmal zu entwickeln.
- Was gibt es bereits? Eine bestehende native App, ein Web-Team, das React sicher beherrscht, oder ein Backend mit einer bestimmten Architektur: All das beeinflusst die Entscheidung.
Wann ist eine native App die bessere Wahl?
Nativ ist den Mehraufwand wert, wenn die App vom Gerät selbst abhängt. Dazu gehören anspruchsvolle Grafik und Animation, Audio- oder Videoverarbeitung in Echtzeit, eine tiefe Integration mit Wearables, Widgets, Fahrzeugsystemen oder Gesundheitsdaten und alles, was neue Funktionen des Betriebssystems vom Tag ihrer Veröffentlichung an nutzen muss.
Nativ ist auch dann der vernünftige Weg, wenn Sie nur eine Plattform brauchen, etwa für ein internes Tool, dessen Nutzer alle dasselbe Gerät verwenden. Und es passt zu Organisationen, die bereits iOS- und Android-Entwickler beschäftigen: Dort käme mit einem neuen Framework ein drittes Kompetenzfeld hinzu, statt eines zu ersetzen.
Der Preis dafür ist klar: Zwei Codebasen bedeuten, dass jede Funktion zweimal konzipiert, entwickelt, getestet und veröffentlicht wird, und es braucht Disziplin, damit beide Apps im Gleichschritt bleiben.
Wann ist Cross-Platform sinnvoller?
Bei den meisten Business-Apps bestehen die Screens aus einer Kombination von Inhalten, Formularen, Konten, Suche, Kartenansichten, Zahlungen und Benachrichtigungen. Cross-Platform-Frameworks bewältigen das gut, und wenn die App sorgfältig gebaut ist, merken Nutzer nicht, wie sie entstanden ist.
Die wichtigsten Vorteile sind praktischer Natur:
- Ein Team und eine Codebasis, sodass neue Funktionen beide Plattformen gleichzeitig erreichen.
- Einheitliches Verhalten und Design auf iOS und Android.
- Weniger doppelte Tests und weniger Stellen, an denen sich derselbe Fehler verstecken kann.
- Eine einfachere Wartung nach dem Launch.
Auch die Grenzen sind real. Sie sind darauf angewiesen, dass das Framework und die Pakete von Drittanbietern mit den Änderungen der Betriebssysteme Schritt halten. Für ungewöhnliche Hardware-Funktionen können native Module nötig sein, die für jede Plattform eigens geschrieben werden, und damit kehrt ein Teil des doppelten Aufwands zurück. Ein Team, das Cross-Platform als Abkürzung versteht und die Konventionen der Plattformen ignoriert, liefert eine App, die sich auf beiden falsch anfühlt.
Was bestimmt Kosten und Zeitplan bei beiden Ansätzen?
Das Framework ist selten der wichtigste Faktor. Budget und Zeitplan hängen vor allem an diesen Punkten:
- Umfang: die Zahl der Screens, Nutzerrollen und Sonderfälle.
- Backend-Arbeit: Konten, Daten, Anbindung an Zahlungs-, Buchungs- oder interne Systeme. Sie fällt bei beiden Ansätzen gleich aus.
- Gestalterischer Anspruch: Eigene Animationen und individuelle Komponenten brauchen länger als Standardmuster.
- Gerätefunktionen: Jede Funktion, die plattformspezifischen Code braucht, schmälert die Ersparnis durch geteilten Code.
- Offline-Verhalten: Daten zuverlässig zu synchronisieren, ist in jeder Technologie anspruchsvoll.
- Tests und Compliance: die Bandbreite der unterstützten Geräte, Barrierefreiheit und eventuelle regulatorische Anforderungen.
Cross-Platform senkt den Aufwand für Entwicklung und Wartung in der Regel, weil Funktionen nur einmal geschrieben werden, halbiert ihn aber nicht. Design, Backend, Tests auf echten Geräten und die Einreichung in den Stores fallen weiterhin für beide Plattformen an. Verlangen Sie Schätzungen, die diese Teile getrennt ausweisen, damit Sie sehen, wo die Ersparnis tatsächlich liegt.
Welche Fehler sollten Sie vor der Entscheidung vermeiden?
Der häufigste Fehler ist, nach Mode zu entscheiden oder nach der Vorliebe derer, die gerade verfügbar sind. Dicht dahinter folgt: sich festzulegen, bevor die Funktionsliste klar ist, und dann festzustellen, dass sich eine zentrale Funktion mit dem gewählten Framework nicht verträgt.
Bevor Sie sich festlegen: Listen Sie die Gerätefunktionen auf, die die App in ihren ersten zwei Jahren braucht, nicht nur zum Launch. Bitten Sie das Entwicklungsteam, zuerst für die riskanteste davon einen Prototyp zu bauen. Stellen Sie sicher, dass Code, Store-Konten und Signaturschlüssel auf den Namen Ihrer Organisation laufen. Und planen Sie die Wartung von Anfang an ein: Beide Betriebssysteme bringen jedes Jahr eine neue Hauptversion heraus, und eine App, die nicht aktualisiert wird, funktioniert nach und nach nicht mehr richtig.
Häufige Fragen
Merken Nutzer, ob eine App nativ oder Cross-Platform ist?
Nicht, wenn sie gut gebaut ist. Nutzer bemerken langsame Screens, umständliche Navigation und ein Verhalten, das die Konventionen ihres Smartphones missachtet. Solche Probleme entstehen durch die Qualität der Arbeit, und sie kommen auch in nativen Apps vor.
Können wir mit Cross-Platform starten und später auf nativ umsteigen?
Ja, und für ein neues Produkt ist das ein vernünftiger Weg. Das Backend, das Design und alles, was Sie von echten Nutzern gelernt haben, bleiben erhalten. Der App-Code selbst würde neu geschrieben. Planen Sie das also nur ein, wenn die Richtung des Produkts es wirklich verlangt.
Ist eine Progressive Web App (PWA) eine günstigere Alternative?
Manchmal. Eine Progressive Web App läuft im Browser und lässt sich auf dem Startbildschirm installieren. Das passt zu Inhalten und einfachen Tools. Ihr Zugriff auf Gerätefunktionen ist eingeschränkter, und in den App-Stores ist sie nicht ohne Weiteres vertreten. Ein gleichwertiger Ersatz ist sie also nicht.
Fällt mit Cross-Platform die plattformspezifische Arbeit ganz weg?
Nein. Store-Einträge, Berechtigungen, die Einrichtung von Push-Benachrichtigungen, In-App-Käufe und manche Details der Oberfläche unterscheiden sich zwischen iOS und Android. Ein gutes Team plant diese Arbeit ein, statt sie spät zu entdecken.
Wenn Sie eine Empfehlung wünschen, die auf Ihrer Funktionsliste beruht und nicht auf einem Lieblings-Framework: Unser Team für App-Entwicklung bewertet Ihr Produkt und erläutert die Abwägungen, bevor eine Zeile Code geschrieben ist.
