Android (Kotlin & Java): native App-Entwicklung

Seit der Google I/O 2019 empfiehlt Google Kotlin offiziell als bevorzugte Sprache für die Android-Entwicklung. Kotlin läuft wie Java auf der Java Virtual Machine, ist aber deutlich kompakter, reduziert typische Fehlerquellen wie Null-Pointer-Exceptions durch eingebautes Null-Safety-Konzept und lässt sich nahtlos mit bestehendem Java-Code kombinieren. Neue Android-Projekte entstehen heute nahezu ausschließlich in Kotlin, und auch die neuesten Jetpack-Bibliotheken sowie das moderne UI-Toolkit Jetpack Compose sind Kotlin-first konzipiert. Compose ersetzt das ältere, XML-basierte Layout-System durch einen deklarativen Ansatz, bei dem die Oberfläche direkt als Kotlin-Funktion beschrieben wird, was Boilerplate-Code spürbar reduziert und Änderungen an Bildschirmen deutlich schneller macht.

Java bleibt trotzdem relevant, und das aus gutem Grund. Ein erheblicher Teil des bestehenden Android-Ökosystems, darunter viele langjährig gewachsene Enterprise-Apps, Bibliotheken und interne Tools, ist in Java geschrieben und wird es auch bleiben. Google unterstützt Java als vollwertige Sprache für Android weiterhin uneingeschränkt, und Kotlin- sowie Java-Dateien lassen sich problemlos im selben Projekt mischen. In der Praxis bedeutet das: Bestehende Java-Codebasen müssen nicht komplett neu geschrieben werden, um von neuen Kotlin-Funktionen zu profitieren, und neue Module lassen sich direkt in Kotlin ergänzen, während gewachsener Java-Code unverändert weiterläuft. Genau dieses Zusammenspiel, nicht die Entscheidung für die eine oder andere Sprache, ist der Kern moderner nativer Android-Entwicklung.

Auch auf Werkzeugebene ist dieses Nebeneinander unkompliziert: Android Studio, Gradle und die Android-Toolchain behandeln Kotlin- und Java-Quelldateien im selben Modul gleichwertig, sodass ein Team schrittweise migrieren kann, statt einen riskanten Komplett-Umstieg auf einmal zu wagen. In vielen gewachsenen Projekten sieht das konkret so aus: Bestehende Aktivitäten, Fragmente und Utility-Klassen bleiben in Java, während neue Features, neue Bildschirme und insbesondere die Oberfläche über Jetpack Compose direkt in Kotlin entstehen. Für Auftraggeber bedeutet das planbare Kosten, weil funktionierender Code nicht aus reiner Prinzipientreue neu geschrieben werden muss.

Diese Koexistenz ist auch der Grund, warum die Unterscheidung "Kotlin oder Java" bei näherem Hinsehen die falsche Frage ist. Die relevantere Frage lautet: Welche Teile eines Projekts profitieren am meisten von Kotlins kompakterer Syntax und den modernen Jetpack-Bibliotheken, und welche Teile laufen in bewährtem, gut getestetem Java-Code stabil und ohne Migrationsrisiko weiter? Genau diese Abwägung trifft man Modul für Modul, nicht einmalig für das gesamte Projekt.

Cross-Platform-Frameworks haben in den letzten Jahren stark aufgeholt, technisch bleiben aber drei Eigenschaften, bei denen native Android-Entwicklung im direkten Vergleich weiterhin die Nase vorn hat.

Keine dieser drei Stärken ist für sich genommen exklusiv nativ, in Ansätzen bieten auch Cross-Platform-Frameworks Zugriff auf Hardware und Play-Dienste. Der Unterschied liegt in der Konsequenz: Native Entwicklung muss nicht erst eine Brücke zu diesen Funktionen bauen, sie ist von Haus aus die Plattform selbst. Das reduziert vor allem das Risiko, bei neuen Android-Versionen oder Rand-Fällen auf eine fehlende oder verspätete Framework-Unterstützung zu stoßen.

Drei Kennzahlen zeigen, warum native Android-Entwicklung auch neben etablierten Cross-Platform-Frameworks ihre Berechtigung behält. Sie sind bewusst als Orientierung zu verstehen, nicht als exakte, tagesaktuelle Messwerte, denn Marktanteile und Adoptionsraten verschieben sich kontinuierlich und unterscheiden sich je nach Erhebungsmethode und Region.

Diese Zahlen bedeuten nicht, dass native Entwicklung grundsätzlich die bessere Wahl ist. Sie zeigen, dass Android als Plattform Reichweite genug bietet, um eine dedizierte native App wirtschaftlich zu rechtfertigen, und dass Kotlin sich als Sprache durchgesetzt hat, ohne Java dabei zu verdrängen. Für die Entscheidung zwischen nativ und Cross-Platform sind sie ein Baustein neben der konkreten Anforderung an Hardware-Zugriff, Performance und Zielgruppe, nicht das alleinige Kriterium. Wer eine belastbare Einschätzung für das eigene Projekt braucht, kommt an einer kurzen fachlichen Analyse der eigenen Anforderungen ohnehin nicht vorbei, allgemeine Marktzahlen können diese Analyse bestenfalls einordnen, aber nicht ersetzen.

Alle drei Ansätze haben ihre Berechtigung, und die Wahl hängt vom Projekt ab, nicht von einem generellen "Gewinner". React Native und Flutter teilen einen Großteil des Codes zwischen iOS und Android und verkürzen dadurch häufig Entwicklungszeit und Budget. Android nativ verzichtet auf dieses Code-Sharing, gewinnt dafür aber an Performance, Zugriffstiefe und Nähe zur Plattform.

React Native setzt auf JavaScript beziehungsweise TypeScript und rendert Oberflächen über eine Bridge in native UI-Komponenten. Das funktioniert für die meisten Business-Apps gut, kann aber bei sehr komplexen, animationsreichen Oberflächen oder bei Zugriffen auf seltenere native APIs zusätzlichen Aufwand für Eigenentwicklungen bedeuten. Flutter geht einen anderen Weg: Es bringt eine eigene Rendering-Engine mit und zeichnet die komplette Oberfläche selbst, unabhängig vom nativen UI-Toolkit der jeweiligen Plattform. Das sorgt für ein sehr konsistentes Erscheinungsbild über Plattformen hinweg, bedeutet aber auch, dass eine Flutter-App nie ganz wie eine "waschechte" Android-App aussieht, sondern wie eine Flutter-App auf Android.

Erwähnenswert ist außerdem Kotlin Multiplatform, ein von JetBrains entwickelter Mittelweg: Geschäftslogik wird einmal in Kotlin geschrieben und für Android, iOS und weitere Plattformen wiederverwendet, während die Oberfläche pro Plattform nativ bleibt, also auf Android mit Jetpack Compose und auf iOS mit SwiftUI. Für Projekte, die native Oberflächen wollen, aber zumindest die fehleranfällige Geschäftslogik nicht doppelt pflegen möchten, ist das eine interessante Zwischenlösung, die sich technisch klar von React Native und Flutter unterscheidet, weil kein UI-Framework, sondern nur der Kotlin-Code selbst geteilt wird.

Die folgende Tabelle stellt die drei am weitesten verbreiteten Ansätze entlang der Kriterien gegenüber, die in der Praxis am häufigsten über die Wahl entscheiden.

Einschätzung auf Basis der Aussagen in diesem Kapitel.

In der Praxis ist die Entscheidung selten dogmatisch. Manche Teams starten mit React Native oder Flutter, um schnell einen Markt zu testen, und wechseln erst dann zu nativer Android-Entwicklung, wenn Nutzerzahlen, Performance-Anforderungen oder Hardware-Bedarf deutlich zunehmen. Andere setzen von Beginn an auf nativ, weil bereits zu Projektstart klar ist, dass Kamerafunktionen, Sensorik oder eine tiefe Systemintegration im Zentrum der App stehen werden.

Wer unsicher ist, sollte die Entscheidung nicht an einer einzelnen Zeile in dieser Tabelle festmachen, sondern an der Summe der eigenen Anforderungen: Wie viele Plattformen werden wirklich gleichzeitig benötigt, wie tief muss die App in Android-spezifische Funktionen eingreifen, und wie lange soll die App danach gepflegt werden? Diese drei Fragen liefern in der Praxis eine deutlich verlässlichere Grundlage als ein pauschaler Trendvergleich.