Native oder Cross Platform: Was sollten Sie für Ihre App wählen?

Fast jeder Unternehmer stellt uns die Frage native oder Cross Platform, sobald ein neues App Projekt beginnt. In der Praxis liefern beide Wege eine echte, einsatzfähige App. Konkret zeigt sich der Unterschied bei Leistung, Entwicklungszeit, Kosten und beim Zugriff auf plattformspezifische Funktionen. In diesem Leitfaden erklären wir zunächst beide Ansätze einzeln. Danach vergleichen wir sie mit Tabellen, damit Sie sehen, welcher Weg zu Ihrem Projekt passt.

Wir nennen hier keinen festen Gewinner. Vielmehr hängt die richtige Antwort von Ihrem Projekt, Ihrem Budget und Ihrem Team ab. Sie können direkt zu den Tabellen oder zum kurzen Entscheidungsleitfaden am Ende springen. Allerdings sollten Sie die Abschnitte zu Leistung und Wartung nicht überspringen. Genau daher entstehen die meisten Fehlentscheidungen aus diesen beiden Punkten.

Konkret ist die Logik dahinter einfach. Nativer Code erreicht jede API des Betriebssystems ohne Umweg. Cross Platform Code läuft stattdessen über eine gemeinsame Schicht. Deshalb liegt native bei aufwendiger Grafik und zeitkritischen Funktionen meist vorn. Zum Beispiel bestehen die meisten Geschäftsapps dagegen aus Formularen, Listen, Benachrichtigungen und Zahlungsbildschirmen. Dort läuft Cross Platform schnell genug, sodass Nutzer keinen Unterschied bemerken.

Zudem beeinflusst das Budget diese Entscheidung direkt. Konkret braucht native Entwicklung meist zwei getrennte Teams und zwei Codebasen. Das erhöht die Startkosten spürbar. Cross Platform liefert dagegen eine Codebasis für beide Plattformen gleichzeitig. Somit lässt das kleine Teams eine erste Version schneller veröffentlichen. Berücksichtigen Sie deshalb Teamgröße und Zeitplan gleich mit in dieser Entscheidung.

Was bedeutet native App Entwicklung?

Native Entwicklung bedeutet, dass Sie eine App direkt in der eigenen Sprache und mit den eigenen Werkzeugen der Plattform schreiben. Zum Beispiel heißt diese Sprache auf iOS Swift, auf Android dagegen Kotlin. Apple baut und pflegt Swift für die eigene Plattform, Google macht dasselbe mit Kotlin. Apples eigene Swift Seite beschreibt, wie der LLVM Compiler Swift Code in optimierten Maschinencode übersetzt, um moderne Hardware voll auszunutzen.

Bei diesem Ansatz zeichnen die eigenen Komponenten des Betriebssystems die Oberfläche. Schaltflächen, Listen und Übergangsanimationen passen deshalb exakt zur visuellen Sprache der Plattform. Somit erhalten Nutzer genau das Verhalten, das sie dort bereits erwarten. Allerdings ist der Preis dafür ein eigenes Team und eine eigene Codebasis. Sie schreiben die iOS Version in Swift und die Android Version in Kotlin, beide von Grund auf.

Dafür kaufen Ihnen diese Mehrkosten sofortigen Zugriff auf die neuesten Fähigkeiten jeder Plattform. Sobald Apple oder Google eine neue Systemfunktion veröffentlicht, nutzen native Entwickler sie meist zuerst. Wenn Sie ein kleines Team führen, wägen Sie diesen Vorteil bei jedem Projekt gegen die zusätzlichen Kosten ab.

Was bedeutet Cross Platform App Entwicklung?

Cross Platform Entwicklung liefert eine einzige Codebasis für iOS und Android zugleich. Konkret heißen die zwei verbreitetsten Werkzeuge React Native und Flutter. Wir nennen beide Namen, empfehlen aber keines davon als die einzig richtige Wahl. Stattdessen übersetzen beide Ihren Code und führen ihn direkt auf dem echten Gerät aus. Keines der beiden verpackt nur eine Webseite in eine App Hülle.

Vor allem ist der größte Vorteil hier Tempo. Ihr Team schreibt eine Funktion einmal und bringt sie auf beide Plattformen. Trotzdem braucht manchmal eine Funktion sehr plattformspezifisches Verhalten. Dann benötigen Sie zusätzlich eine kleine Brücke im Code. In der Praxis brauchen die meisten Alltagsfunktionen diese Brücke gar nicht, weil das Plugin Ökosystem dasselbe Problem schon löst.

Zudem passt vielleicht eine leichtere, webbasierte Lösung sogar besser zu Ihrem Projekt als eine App. Lesen Sie dazu unseren Beitrag Mobile App oder Progressive Web App, was wählen. Diese Frage kommt meist schon vor der Entscheidung native oder Cross Platform.

Wie funktioniert React Native?

React Native ist die Oberflächenbibliothek von Meta, und Sie schreiben sie in JavaScript. Laut reactnative.dev nimmt die Bibliothek Ihren Code und bildet ihn direkt auf die nativen Bausteine der jeweiligen Plattform ab. Komponenten wie View, Text und Image entsprechen zum Beispiel direkt den nativen Oberflächenelementen. Der Bildschirm nutzt also wirklich die eigenen Komponenten der Plattform. Also täuscht er kein Aussehen nur vor.

Konkret listet die offizielle Seite von React Native tausende Produktionsapps, die die Bibliothek nutzen. Dazu zählen zum Beispiel Facebook, Microsoft Teams, Amazon Shopping und Shopify. Community Projekte erweitern dieselbe Codebasis zudem auf Desktop und Web. Rund um dieses Ökosystem gibt es zudem zusätzliche Werkzeuge mit Routing und Modulunterstützung für neue Projekte, und das verkürzt den Einstieg.

Wie funktioniert Flutter?

Flutter ist das Oberflächenframework von Google, und Sie schreiben es in Dart. Der Architekturüberblick auf docs.flutter.dev erklärt den Aufbau. Flutter bildet seine Oberfläche nie auf die eigenen Widgets des Betriebssystems ab. Stattdessen trägt jedes Steuerelement eine eigene Dart Implementierung. Es gibt zum Beispiel eine reine Dart Version des iOS Schalters. Ebenso gibt es eine getrennte reine Dart Version des Android Schalters.

Zunächst läuft Flutter während der Entwicklung in einer virtuellen Maschine. Dabei bleibt der Zustand also über ein Hot Reload erhalten. Danach übersetzt der Compiler Ihren Code beim Release direkt in ARM oder x64 Maschinencode. Für das Web Ziel kompiliert Ihr Code stattdessen zu JavaScript oder WebAssembly. Die Dokumentation beschreibt zudem, wie Flutter die ganze Szene in einem Schritt zusammensetzt. Folglich wechselt die Engine nie zwischen App Code und Plattform Code hin und her.

Dieselbe Dokumentation fasst das Designprinzip von Flutter in drei Worten zusammen: einfach ist schnell. Konkret sollen Build Methoden schnell laufen und frei von Nebeneffekten bleiben, so die Dokumentation. Lassen Sie deshalb aufwendige Berechnungen asynchron laufen. Speichern Sie das Ergebnis im Zustand, statt es direkt in die Oberflächenschicht zu schreiben.

Warum bleiben Swift und Kotlin der native Standard?

Swift und Kotlin bleiben der Standard für native Arbeit, selbst nachdem Cross Platform Werkzeuge zum Mainstream wurden. Konkret baut Apple Swift gemeinsam mit dem eigenen Betriebssystem, und Google baut Kotlin genauso. Somit gibt das jeder Sprache sofortigen Zugriff auf neue Systemfunktionen. Apples Swift Seite nennt die Sprache leistungsstark und intuitiv für alle Apple Plattformen. Googles eigene Android Entwicklerseite positioniert Kotlin als vollständig unterstützte Sprache für die Android Entwicklung.

Googles eigene Seite macht zwei konkrete Aussagen. Erstens nutzen mehr als 60 Prozent der professionellen Android Entwickler demnach Kotlin. Zweitens ergänzt dieselbe Seite, dass Apps mit Kotlin um 20 Prozent seltener abstürzen. Also stammen diese Zahlen von Google selbst. Wir haben sie nicht unabhängig geprüft, dennoch zeigen sie das Gewicht von Kotlin auf Android.

Macht das Cross Platform überflüssig? Keineswegs. Konkret können sowohl React Native als auch Flutter eine Brücke zu nativen Modulen bauen. Ihr Team schreibt diese Module bei Bedarf in Swift oder Kotlin. Mit anderen Worten: Sie schreiben neunzig Prozent der App in Cross Platform Code. Nur den kritischsten Teil verschieben Sie dann in nativen Code.

Beide native Sprachen bringen inzwischen zudem ein eigenes deklaratives Oberflächenwerkzeug mit. Konkret hat Apple SwiftUI, Android dagegen Jetpack Compose. Somit ähneln diese Werkzeuge vom Schreibstil her dem Widget Modell von Flutter. Deshalb ist der Unterschied in der täglichen Entwicklererfahrung zwischen native und Cross Platform in den letzten Jahren deutlich kleiner geworden.

Woher kommt der Leistungsunterschied zwischen native oder Cross Platform?

Der Leistungsunterschied zwischen native oder Cross Platform entsteht dadurch, wie jeder Ansatz die Oberfläche zeichnet. Das Betriebssystem zeichnet die Oberfläche einer nativen App mit seiner eigenen Engine. Konkret liegt dazwischen keine zusätzliche Brückenschicht. Flutter dagegen bringt die eigene Render Engine namens Impeller direkt in der App mit, also zunächst ausgeliefert. Folglich hängt die Renderleistung nie von einem Update des Betriebssystems ab.

React Native schickt Nachrichten stattdessen über eine native Brücke. Dadurch kostet dieser Umweg etwas Zeit. Die Flutter Dokumentation sagt, dass Aufrufe über FFI deutlich schneller laufen können als über Plattformkanäle, weil FFI ganz ohne Serialisierung arbeitet. In der Praxis zeigen die meisten Alltagsbildschirme diesen technischen Unterschied gar nicht. Erst bei Spielen oder komplexen Animationen mit sechzig Bildern pro Sekunde wird er sichtbar.

Zum Beispiel gibt es bei einfachen Formularen und Listen praktisch keine spürbare Lücke. Nutzer bemerken dort zwischen native und Cross Platform keinen Unterschied. Aufwendige Grafik, Kameraverarbeitung in Echtzeit und komplexe räumliche Darstellung sind dagegen eine andere Geschichte. Dort bietet der direkte Zugriff von native dagegen einen messbaren Vorteil.

Warum verändert der Zugriff auf plattformspezifische Funktionen Ihre Entscheidung?

Jede neue Version des Betriebssystems bringt Funktionen, die zuerst native Entwickler erreichen. Widgets, Live Activities, Gesundheitsdaten, biometrische Anmeldung und AR Frameworks wie ARKit gehören zu dieser Gruppe. Cross Platform Werkzeuge holen bei diesen Funktionen meist kurz danach über ein Plugin auf. Manche Funktionen bekommen allerdings nie ein Plugin.

Trotzdem stört diese Verzögerung nicht jedes Projekt. Eine App zur Sendungsverfolgung kann einen neuen Widget Typ zum Beispiel eine Woche lang auslassen und trotzdem ihre Aufgabe vollständig erfüllen. Sitzt eine plattformspezifische Fähigkeit dagegen im Kern Ihres Produkts, etwa bei Gesundheitsdaten, Zahlungen oder Identitätsprüfung, wird dieselbe Verzögerung sofort zur echten Produktverzögerung.

• Braucht Ihre App die neueste Systemfunktion schon am ersten Tag nach dem Start?
• Steht die gewünschte Funktion, etwa ein Widget oder eine Live Activity, im Zentrum der Nutzung, oder ist sie nur ein nettes Extra?
• Kann Ihr Team ohne passendes Plugin selbst ein kleines natives Modul schreiben?

Ein Ja bei diesen Fragen, zusammen mit einer zentralen plattformspezifischen Funktion, spricht für native. Lautet die Antwort meist Nein, besteht Ihre App vermutlich aus Standardbildschirmen. Dann verändert dieses Risiko Ihre Entscheidung kaum.

Welcher Ansatz kostet weniger Zeit und Budget?

Zunächst ist die Entwicklungszeit bei Cross Platform meist kürzer. Ihr Team schreibt die Logik einer Funktion einmal und bringt sie auf beide Plattformen. Native braucht dagegen zwei getrennte Teams, oder ein Team, das zwei Sprachen gleichzeitig lernt. Folglich dehnt das sowohl den Zeitplan als auch das Budget. Dieser Unterschied ändert sich trotzdem von Projekt zu Projekt. Zum Beispiel kann der Brückencode bei einer sehr plattformspezifischen App die gewonnene Zeit wieder aufzehren.

Generell gehen die Kostentreiber weit über die reine Technikwahl hinaus. Teamerfahrung, Designkomplexität und die Anzahl der Integrationen spielen ebenso eine Rolle. Wir behandeln diese Variablen ausführlich in unserem Beitrag was die Kosten der App Entwicklung bestimmt. Statt einer festen Zahl zeigt dieser Beitrag, was die Kosten nach oben und unten treibt.

Konkret hilft eine praktische Faustregel hier weiter. Hat Ihr Team bereits Erfahrung mit Swift oder Kotlin und startet die App zuerst auf einer Plattform, liegen die echten Kosten von native oft niedriger als auf dem Papier. Ist Ihr Team klein und müssen beide Plattformen gleichzeitig starten, hält Cross Platform Ihr Budget deutlich planbarer.

Ebenso folgt der Zeitplan dieser Logik. Zum Beispiel kostet die Suche nach zwei externen nativen Spezialisten schon für sich genommen Zeit. Somit kann allein dieser Einstellungsprozess den Start um Wochen verschieben. Cross Platform braucht demgegenüber nur ein Team. Einstellung und Abstimmung dauern dadurch kürzer, und diese Ersparnis wirkt sich direkt auf Ihren Zeitplan aus.

Native oder Cross Platform: Vergleich nach Kriterien

Die folgende Tabelle stellt beide Ansätze nebeneinander. Wir nutzen dafür die Kriterien, die wir in der Praxis am häufigsten vergleichen. Trotzdem hat keine Zeile einen klaren Sieger. Vielmehr zählt jede Zeile je nach Ihrem Projekt unterschiedlich stark.

Denken Sie beim Lesen dieser Tabelle an einen Punkt. Native oder Cross Platform ist oft eigentlich eine Frage des Zeithorizonts. Brauchen Sie heute also einen schnellen Start, gewinnt die rechte Spalte. Brauchen Sie dagegen langfristige plattformspezifische Tiefe, sollten Sie die linke Spalte schon jetzt einplanen.

Welche Apptypen brauchen wirklich native Entwicklung?

Konkret wird native bei manchen Apptypen vom Vorzug zur echten Notwendigkeit. Der Kernwert der App hängt dann von tiefem Zugriff auf das Betriebssystem ab. Konkret empfehlen wir native vorrangig für die folgenden Apptypen.

• Spiele mit hoher Bildrate und Apps mit Echtzeitgrafik.
• Apps für erweiterte Realität oder Bilderkennung, die das Kamerabild sofort verarbeiten.
• Apps mit enger Anbindung an Gesundheits, Fitness oder Wearable Daten.
• Sicherheits und Logistikapps, die Standort oder Sensoren dauerhaft im Hintergrund verfolgen.

Zwar bleibt Cross Platform für jeden dieser Apptypen technisch weiterhin möglich. Allerdings zehrt der zusätzliche Brückencode die gewonnene Entwicklungsgeschwindigkeit oft wieder auf. Planen Sie diesen Aufwand deshalb schon vorab ein.

Welche Apptypen passen gut zu Cross Platform?

Die meisten Geschäftsapps brauchen stattdessen vor allem Tempo und Konsistenz, keine plattformspezifische Tiefe. Somit ist Cross Platform für die folgenden Apptypen meist der klügere Einstieg.

• Standardapps mit Formularen, Listen, Benachrichtigungen und Zahlungsbildschirmen.
• Content, E-Commerce oder Buchungsapps.
• MVPs, die einen Markt schnell prüfen müssen.
• Startups mit kleinem Team, die beide Plattformen gleichzeitig starten wollen.

Konkret bemerken Nutzer bei diesen Apptypen fast nie eine Leistungslücke. Entwicklungsgeschwindigkeit und Budgetvorteil treiben die Entscheidung dann stattdessen. Vielmehr liegt Ihr eigentlicher Wettbewerbsvorteil meist ohnehin in Inhalt, Preis oder Kundenerlebnis, nicht in der reinen Renderleistung. Stecken Sie Ihr Budget deshalb lieber dort hinein als in die Oberflächenperformance.

Was ist der richtige Einstieg für kleine Unternehmen?

Konkret beschäftigen kleine Unternehmen meist nur ein oder zwei Entwickler. Folglich sprengt es dieses Budget schnell, zwei getrennte native Teams aufzubauen. Deshalb empfehlen wir kleinen Unternehmen, zuerst eine erste Version in Cross Platform zu veröffentlichen. Prüfen Sie zunächst den Markt. Verschieben Sie kritische Teile erst danach zu native, und nur, wenn Sie das wirklich brauchen.

Ebenso nutzen wir diesen Ansatz, wenn ein Kunde entscheiden muss, was in die erste Version gehört. Unser Beitrag was ein Mobile App MVP ist und welche Funktionen zuerst behandelt diese Entscheidung ausführlich. Wir wiederholen ihn hier nicht. Stattdessen zeigen wir nur, wie er mit der Technikwahl zusammenhängt.

Diese Regel gilt trotzdem nicht starr. Hängt das einzige Kernmerkmal Ihrer App schon von einer plattformspezifischen Fähigkeit ab, etwa einer Bildverarbeitung, die nur auf einer Plattform gut läuft, starten Sie besser direkt mit native, auch als kleines Team.

Wie verändert die Teamgröße Ihre Budgetentscheidung?

Folglich schrumpft mit wachsender Teamgröße der Nachteil von native. Zwei Plattformteams parallel zu führen wird dann endlich praktikabel. Große Unternehmen wählen deshalb oft native. Konkret zahlt sich tiefes Fachwissen auf jeder Plattform bei ihnen langfristig aus.

Beim Budget sollten Sie die Anfangsinvestition getrennt von den langfristigen Gesamtkosten betrachten. Zunächst senkt Cross Platform die Startkosten. Ein plattformspezifischer Bedarf kann aber später trotzdem auftauchen. Dann kommt der zusätzliche Brückencode als ungeplante Kostenposition zurück. Also legen Sie dafür eine kleine Reserve zur Seite.

Betrachten Sie die Budgetentscheidung deshalb als einen Wartungsplan über drei bis fünf Jahre, nicht als einmalige Rechnung. Konkret übertragen Sie die Posten aus unserem Beitrag zu den Kostentreibern auf Ihr eigenes Projekt. So sehen Sie also das vollständige Bild, nicht nur den Preis am Starttag.

Langfristige Wartungs und Updatekosten im Vergleich

Die echten langfristigen Kosten zeigen sich über einen dreijährigen Wartungszyklus, nicht schon beim ersten Release. Konkret fasst die folgende Tabelle die Posten zusammen, die uns in diesem Zyklus am häufigsten begegnen.

Diese Tabelle ist keine feste Regel. Eine schlanke Cross Platform App mit wenig Plugins bleibt oft leichter zu pflegen, als diese Tabelle vermuten lässt. Umgekehrt kann eine Cross Platform App mit vielen Brücken schwerer zu pflegen werden als native.

Welcher Ansatz passt besser in die MVP Phase?

In der MVP Phase zählt schnelle Validierung, nicht makellose Leistung. Deshalb ist Cross Platform hier meist der klügere Einstieg. Konkret liefert eine einzige Codebasis Feedback von iOS und Android Nutzern zugleich. Somit investieren Sie nicht in zwei native Teams, bevor der Markt überhaupt geprüft ist.

Hängt das einzige Kernmerkmal Ihres MVP schon von einer plattformspezifischen Fähigkeit ab, etwa einer Hardware Integration, die nur auf einer Plattform funktioniert, lockern Sie diese Regel. In diesem engen Fall führt native auf einer Plattform schneller zum Ergebnis als unnötiger Brückencode in Cross Platform.

Wie wir entscheiden, welche Funktionen wirklich in ein MVP gehören, beschreiben wir in einem eigenen Beitrag. Wir wiederholen ihn hier nicht. Wir verweisen Sie direkt auf diesen Beitrag.

Zudem lohnt sich ein weiterer Punkt hier. Trotzdem legt die Technikwahl Ihres MVP die endgültige Architektur nicht fest. Ihr Team lernt aus echten Nutzungsdaten, welche Bildschirme viel Verkehr tragen. Ebenso sehen Sie, welche Bildschirme Leistungsbeschwerden auslösen. Ohne diese Daten wird die Entscheidung für einen späteren Wechsel zu native meist zu einer teuren Vermutung.

Können Sie später zu native wechseln?

Ja, und Teams gehen diesen Weg in der Praxis häufig. Ein Team startet zunächst mit Cross Platform und prüft damit den Markt. Danach schreibt es meist nur den einen leistungskritischen Bildschirm als natives Modul neu. Ansonsten bleibt der Rest der App, wie er ist. Ebenso unterstützen sowohl React Native als auch Flutter diese Art der teilweisen nativen Integration.

Somit kostet dieser Wechsel weniger als von Anfang an native zu schreiben. Ihr Team weiß dann bereits aus echten Nutzerdaten, welcher Bildschirm wirklich zählt. Die Alternative wäre stattdessen, die ganze App ohne Daten auf Verdacht in native zu schreiben. Stattdessen nutzt es Ihre Ressourcen deutlich besser, nur den einen geprüften Abschnitt zu verschieben.

Umgekehrt kommt der Weg von native zu Cross Platform viel seltener vor. Zwei getrennte Codebasen in eine zusammenzuführen kostet fast so viel Aufwand wie ein kompletter Neuanfang. Sind Sie sich noch unsicher, halten Sie sich deshalb mit Cross Platform alle Optionen offen.

Welche Fehler sehen wir bei dieser Entscheidung am häufigsten?

Konkret sehen wir bei App Projekten immer wieder dieselben Fehler. Sie alle haben eine gemeinsame Ursache: Die Technikwahl entsteht ohne Bezug zum eigentlichen Geschäftsziel.

• Zwei getrennte native Teams aufbauen, bevor der Markt überhaupt geprüft ist, und so das Budget früh verbrennen.
• Ebenso die ganze App in native schreiben, nur wegen einer einzigen plattformspezifischen Funktion.
• Die Pluginanzahl in Cross Platform unkontrolliert wachsen lassen und so die Wartung langfristig schwerer machen.
• Die Entscheidung allein nach Entwicklungstempo treffen, ohne den Bedarf an plattformspezifischen Funktionen einzurechnen.
• Zudem das vorhandene Können des Teams (Swift, Kotlin, React, Dart) ignorieren und eine völlig neue Sprache von Grund auf einüben wollen.
• Schließlich einen dreijährigen Wartungsplan ganz auslassen und nur nach den Kosten des ersten Release entscheiden.

Keiner dieser Fehler entsteht aus fehlendem Wissen. Stattdessen entsteht er meist aus Eile. Die Lösung ist deshalb kein neues Werkzeug, sondern eine schriftlich festgelegte Entscheidungsregel.

Zudem kommt ein weiterer Fehler oft vor. Konkret landet die Technikwahl allein bei einer Person, meist beim zuletzt eingestellten Entwickler. Diese Entscheidung sollte zuerst Budget, Zeitplan und plattformspezifischen Bedarf widerspiegeln. Stattdessen sollte sie nicht allein die persönliche Vorliebe eines Entwicklers widerspiegeln. Vielmehr sollte der Unternehmer die endgültige Entscheidung treffen. Das technische Team sollte die echten Kompromisse nur klar vorlegen.

Kurzer Entscheidungsleitfaden: Welche fünf Fragen sollten Sie stellen?

In einem Gespräch stellen wir genau diese fünf Fragen, um die Technikentscheidung zu klären. Zunächst schreiben Sie Ihre eigenen Antworten auf. So bauen Sie den Großteil der Entscheidung selbst auf.

1. Hängt der Kernwert Ihrer App von einer plattformspezifischen Fähigkeit ab, etwa Kamera, Sensor oder Hardware? Dann tendieren Sie zu native.
2. Haben Sie den Markt schon geprüft? Falls nicht, veröffentlichen Sie zuerst ein schnelles MVP in Cross Platform.
3. Hat Ihr Team bereits Erfahrung mit Swift oder Kotlin? Wenn ja, und Sie starten zuerst auf einer Plattform, liegen die echten Kosten von native vielleicht niedriger als gedacht.
4. Müssen Sie beide Plattformen gleichzeitig mit knappem Budget starten? Dann hält Cross Platform Ihr Budget deutlich planbarer.
5. Wer übernimmt Ihren dreijährigen Wartungsplan, ein Team oder zwei getrennte Teams? So verbindet die Antwort die heutige Entscheidung mit der langen Frist.

Am Ende ist die Antwort auf native oder Cross Platform keine Technikvorliebe, sondern eine Geschäftsentscheidung: zuerst das Ziel, dann das Budget, zuletzt das Werkzeug. In unserem Leistungsbereich App Entwicklung klären wir diese Wahl gemeinsam mit Ihnen, passend zu Ihrem konkreten Projekt.

Noch ein letzter Hinweis. Noch einmal: die Kriterien in diesem Leitfaden sind ein Startpunkt, keine feste Regel. Vielleicht braucht es gar keine neue App, sondern nur ein besseres mobiles Erlebnis auf Ihrer bestehenden Website. Prüfen Sie das zuerst mit unserem Mobile Friendly Test. Möchten Sie diese Entscheidung gemeinsam mit uns durchgehen, können Sie uns gerne schreiben.