Wer schon mal eine App für Android und iOS entwickeln wollte, kennt das Dilemma: Native Entwicklung bedeutet viel Aufwand – eine Codebasis für Android, eine für iOS. Genau hier setzen Cross-Platform-Frameworks an. Sie versprechen: einmal entwickeln, überall beide Plattformen bedienen.
Aber: Wie gut sind diese Frameworks wirklich, wenn es um Leistung geht? Cross-Platform-Entwicklung verspricht Effizienz, Flexibilität und geringere Kosten. Doch kann sie auch bei der Performance mit nativen Apps mithalten? In meiner Bachelorarbeit bin ich genau dieser Frage nachgegangen – und habe vier Apps entwickelt und mit Benchmarks auf ihre Leistung getestet. In diesem Beitrag stelle ich die Methodik, Tools, Herausforderungen sowie die daraus resultierenden Erkenntnisse dar.
Ein kurzer Reminder, warum wir über App-Performance sprechen: Nutzer*innen erwarten heute flüssige Interfaces, kurze Ladezeiten und ein reibungsloses App-Erlebnis. Ruckelnde Animationen, überhitzte Geräte oder abstürzende Apps können schnell zu schlechten Bewertungen oder sogar Deinstallation führen. Gerade die Metrik der Bilder pro Sekunde (engl. Frames per Second, im Folgenden kurz: FPS) wirkt sich auf die Wahrnehmung der User aus.
Zunächst habe ich eine Auswahl von Cross-Platform-Frameworks getroffen, die ich mit der nativen Variante vergleiche:
Flutter, React Native und Kotlin Multiplatform
Um die Leistungsfähigkeit zu evaluieren, habe ich drei Metriken verwendet:
Um eben diese Metriken zu erheben, habe ich zwei Benchmarks entwickelt:
Benchmark 1: Scrollbare Liste mit 500 Einträgen
Das Scrollen durch Listen ist eine der häufigsten Interaktionen in mobilen Apps – egal ob Newsfeed, Chatverlauf oder Produktsuche. Gleichzeitig ist es eine typische Schwachstelle in der Performance, weil bei jeder Scrollbewegung UI-Elemente aktualisiert, Text gerendert und ggf. Bilder nachgeladen werden müssen.
Benchmark 2: Abspielen einer Animation
Moderne Apps setzen stark auf Animationen – für Ladeanzeigen, Transitions, Feedback etc. Sie sind nicht nur kosmetisch, sondern verbessern auch das Nutzungserlebnis. Gleichzeitig sind sie performance-intensiv: Jeder Frame muss sauber gerendert werden.
Um subjektive Einflüsse auszuschließen, wurde die Testausführung vollständig automatisiert:
Alle Tests liefen auf drei Android-Geräten (Pixel 6 Pro, Pixel 7 und OnePlus Nord 2), um hardwareabhängige Ausreißer zu minimieren. Weil einzelne Durchläufe Schwankungen unterliegen können (z. B. durch Systemprozesse, Umwelteinflüsse etc.) wurden pro App und Benchmark jeweils 10 Runs durchgeführt, deren Mittelwerte dann zur Auswertung dienten. Zudem wurde jede App als Release Build kompiliert, um praxisnahe Werte zu erhalten.
Mit dem Testaufbau stand die Bühne. Nachdem alle Apps auf allen drei Geräten automatisiert durch die Benchmarks liefen und Flashlight fleißig Daten gesammelt hatte, lag eine riesige Menge an Messwerten vor.
Hier die Ergebnisse des Listenbenchmarks auf dem Testgerät Pixel 7.
React Native zeigt in diesem Szenario eine sehr stabile Performance. Die Bildrate bleibt fast konstant bei 60 FPS, mit nur minimalen Schwankungen. Das spricht für eine gut optimierte Darstellung. Auch bei wiederholten Scrollbewegungen kommt es zu keinen größeren Einbrüchen.
Flutter hingegen fällt durch regelmäßige, deutlich ausgeprägte Einbrüche auf. Mehrmals sinkt die Bildrate auf unter 30 FPS. Zwischen den Einbrüchen erholt sich Flutter zwar, aber die Schwankungen bleiben bestehen.
Native liegt in der Gesamtbetrachtung im oberen Bereich, mit Werten zwischen 55 und 60 FPS. Einzelne kleinere Einbrüche sind vorhanden.
Kotlin Multiplatform zeigt ein ähnliches Verhalten wie die native Variante. Die Bildrate ist größtenteils stabil, mit leichten Schwankungen.
Ob Native oder Cross-Platform: Mehr zu unserem App Development gibt es hier:
Die Grafik zeigt die RAM-Auslastung während des Listen-Benchmarks auf dem OnePlus Nord 2. Über 25 Sekunden hinweg wurde gemessen, wie viel Arbeitsspeicher die jeweilige App beim Scrollen durch 500 Einträge benötigt.
React Native belegt mit Abstand den meisten Speicher. Der Verbrauch steigt früh auf über 260 MB und bleibt konstant hoch, mit einzelnen Ausschlägen Richtung 280 MB. Damit liegt React Native deutlich über den anderen Frameworks.
Flutter zeigt eine stabilere, aber ebenfalls erhöhte Auslastung: Nach einem frühen Sprung pendelt sich die Nutzung bei rund 230 MB ein – konstant, aber vergleichsweise speicherintensiv.
Native und Kotlin Multiplatform nutzen den RAM deutlich effizienter. Es fällt besonders auf, dass beide Frameworks einen fast identischen Graphen zeichnen. Beide starten bei etwa 160 MB und stabilisieren sich im Bereich von 180–200 MB. KMP bleibt dabei meist leicht unterhalb der nativen App.
React Native sticht deutlich heraus. Die CPU-Auslastung erreicht mehrfach die höchsten Werte, mit sehr unregelmäßigen Spitzen. Gerade beim Scrollen scheint React Native den Prozessor stark zu fordern.
Flutter zeigt ein ganz anderes Bild: Die CPU-Nutzung bleibt insgesamt moderat und fällt regelmäßig auf nahezu 0 % zurück. Zwischenzeitlich werden Höchstwerte im Bereich von 80–90 % erreicht.
Native und KMP zeigen ein nahezu identisches Profil. Beide Frameworks bewegen sich im mittleren Auslastungsbereich mit Werten meist zwischen 30 und 70 %, ohne extreme Ausreißer.
Die Ergebnisse der Messungen zeigen, dass keines der getesteten Frameworks in allen Kategorien gleichzeitig besonders ressourcenschonend oder besonders performant ist. Vielmehr treten je nach Metrik – also FPS, RAM oder CPU – unterschiedliche Schwerpunkte zutage. Nimmt man den Schnitt aller Messungen performt die Native Applikation jedoch am besten.
Die Benchmarks und Messergebnisse findest du hier in meinem GitHub-Repo.
