Native oder Cross-Platform? Entscheidungshilfe für Unternehmer

Wenn Sie eine mobile App entwickeln lassen, ist das die erste technische Entscheidung, die auf Sie zukommt: native oder Cross-Platform? Eigentlich müssen nicht Sie diese Entscheidung treffen — das ist Sache des Entwicklers. Aber Sie müssen die Begründung verstehen können, denn die Entscheidung beeinflusst Kosten, Dauer und die Frage, mit wem Sie später arbeiten können. Dieser Beitrag ist kein technischer Vergleich; er wurde geschrieben, damit Unternehmer dieses Gespräch führen können.

Was bedeutet native und Cross-Platform? Eine native App wird für ein einziges Betriebssystem mit den eigenen Werkzeugen dieser Plattform entwickelt: Swift für iOS, Kotlin für Android. Eine Cross-Platform-App (plattformübergreifend) ist dagegen der Ansatz, aus einer einzigen Codebasis sowohl die iOS- als auch die Android-Version zu erzeugen; React Native und Flutter sind die verbreitetsten Werkzeuge dieses Ansatzes. Im Folgenden erklären wir, was dieser Unterschied für Unternehmer bei Kosten, Wartung und Team bedeutet.

Was bedeuten die drei Optionen?

Auf der Cross-Platform-Seite sind die beiden verbreitetsten Technologien React Native und Flutter. Auf der nativen Seite wird Swift für iOS und Kotlin für Android verwendet.

Die praktischen Unterschiede aus Ihrer Sicht

• Kosten: Wenn Sie auf beiden Plattformen gleichzeitig starten, bedeutet native zwei separate Entwicklungen. Bei Cross-Platform wird einmal entwickelt, für Plattformunterschiede fällt aber trotzdem Zusatzarbeit an — erwarten Sie nicht „die halben Kosten“.
• Wartung: Hier ist der Unterschied am stärksten spürbar. Jede Korrektur und jede neue Funktion wird bei native zweimal umgesetzt. Soll Ihre App jahrelang leben, wächst dieser Posten.
• Ein Team finden: Wenn sich Ihre Wege mit dem Dienstleister trennen, sollte es leicht sein, jemanden zu finden, der das Projekt übernimmt. Weit verbreitete Technologien sind in dieser Hinsicht im Vorteil.
• Wechsel zur zweiten Plattform: Wenn Sie mit einer Plattform starten und später zur anderen wechseln möchten, erleichtert Cross-Platform diesen Übergang deutlich.
• Performance: Bei typischen Geschäfts-Apps mit Formularen, Listen, Karten und Zahlungen spürt der Nutzer in der Regel keinen Unterschied. Der Unterschied zeigt sich bei Apps, die intensive Grafik und ständige Bewegung erfordern.

In welchen Fällen ist native nötig?

Das sind konkrete Gründe; „Es wird hochwertiger“ ist kein Grund.

• Apps, die intensive 3D-Grafik oder eine Spiele-Engine erfordern.
• Augmented Reality, fortgeschrittene Kameraverarbeitung, Echtzeit-Bild- oder Tonverarbeitung.
• Spezielle Szenarien, die tiefen Zugriff auf die Gerätehardware erfordern (spezielle Bluetooth-Geräte, fortgeschrittene NFC-Nutzung, dauerhafte Standortverarbeitung im Hintergrund).
• Latenzempfindliche Apps, bei denen Millisekunden zählen.
• Wenn Sie eine neu erschienene Funktion der Plattform vom ersten Tag an nutzen müssen.

Trifft keiner dieser Punkte auf Ihre Situation zu, ist Cross-Platform mit hoher Wahrscheinlichkeit die vernünftige Option. Verlangen Sie aber, dass Ihr Entwickler diese Entscheidung für Ihr Projekt begründet; akzeptieren Sie sie nicht als allgemeine Regel.

React Native oder Flutter?

Diese Frage betrifft Unternehmer weniger, als man denkt. Beides sind ausgereifte, weit verbreitete Technologien, die typische Geschäfts-Apps abdecken. Entscheidend ist in der Regel Folgendes: womit das Entwicklerteam Erfahrung hat und auf welcher Seite die fertigen Komponenten, die Ihr Projekt braucht, besser etabliert sind.

Das Einzige, worauf Sie achten müssen, ist, ob die Wahl begründet wird. „Wir machen das immer so“ ist keine ausreichende Antwort; „Ihr Projekt hat diese und jene Anforderungen, deshalb wählen wir das“ ist eine ausreichende Antwort.

Noch eine Option: gar nicht in den Store

Wenn Push-Benachrichtigungen, Offline-Betrieb, Kamera oder Standortverfolgung nicht zwingend sind, kann eine mobil optimierte Web-App die Aufgabe erfüllen. Dieser Weg beseitigt Store-Konten, den Store-Prüfprozess und die Download-Hürde vollständig; der Nutzer klickt auf den Link und benutzt die App.

Besonders bei internen Werkzeugen und bei Tests einer ersten Version wird diese Option oft weniger besprochen, als sie verdient. Die Logik, mit engem Umfang zu starten, haben wir in unserem Beitrag zur Ideenvalidierung mit einem MVP erklärt.

Fragen, die Sie dem Entwickler stellen sollten

• Welchen Ansatz empfehlen Sie für dieses Projekt und warum? Können Sie die Begründung projektspezifisch erläutern?
• Wie viele Personen in diesem Team können mit der gewählten Technologie arbeiten?
• Schränkt diese Wahl ein, was ich später hinzufügen möchte?
• Wie viel Anpassungsarbeit ist nötig, wenn die jährlichen Betriebssystem-Updates kommen, und wie wird das abgerechnet?
• Wenn ich die Zusammenarbeit mit Ihnen beende, wie schwer ist es, jemanden mit dieser Technologie zu finden, der das Projekt übernimmt?
• Wie ist das Eigentum an Code und Konten im Vertrag geregelt?

Die letzten beiden Fragen sollten unabhängig von der Technologiewahl in jedem Projekt gestellt werden. Alle Fragen für die Wahl eines Dienstleisters haben wir in unserem Beitrag zur Auswahl eines Softwareunternehmens zusammengestellt.

Häufig gestellte Fragen

Ist eine Cross-Platform-App von geringerer Qualität?

Die Qualität hängt weniger von der Technologie als davon ab, wie die Arbeit gemacht wird. Bei typischen Geschäfts-Apps merkt der Nutzer in der Regel keinen Unterschied; eine schlecht gemachte native App bietet ein schlechteres Erlebnis als eine gut gemachte Cross-Platform-App.

Kann ich später zu native wechseln?

Das können Sie, aber es bedeutet, dass die App neu geschrieben wird. Es ist günstiger, diese Möglichkeit von Anfang an zu besprechen und zu entscheiden, ob sie wirklich nötig ist.

Ist es sinnvoll, mit einer Plattform zu starten?

Wenn Sie die Geräteverteilung Ihrer Zielgruppe kennen, ja. Die Wahl von Cross-Platform erleichtert die Arbeit, wenn Sie zur zweiten Plattform wechseln möchten.

Wie stark verändert die Technologiewahl die Kosten?

Wenn Sie auf einer Plattform starten, wird der Unterschied kleiner; wenn Sie auf zwei Plattformen starten und die App jahrelang gewartet wird, wird der Unterschied größer. Die Posten, die die Kosten bestimmen, haben wir in unserem Beitrag zu den Kosten einer mobilen App behandelt.

Was passiert, wenn der Support für die gewählte Technologie endet?

Eine berechtigte Sorge. Der Weg, das Risiko zu verringern, ist, weit verbreitete Technologien mit einer großen Community dahinter zu bevorzugen und das Eigentum am Code vertraglich bei Ihnen festzuschreiben.

Lassen Sie uns gemeinsam prüfen, was zu Ihrem Projekt passt

Teilen Sie uns mit, was Ihre App tun soll, welche Geräte Ihre Zielgruppe nutzt und was in der ersten Version nötig ist; dann erläutern wir Ihnen die Technologiewahl mit ihrer Begründung. Sie können sich unsere Leistung App-Entwicklung ansehen und uns kontaktieren — wir kommunizieren auf Englisch oder Türkisch.