Android ist offiziell Compose-first. Ihre View-basierte App ist jetzt Legacy-Code.

Bei Google I/O 2026 diese Woche hat Google die Entscheidung getroffen, auf die Android-Entwickler seit Jahren gewartet haben. Jetpack Compose ist jetzt der offizielle Standardweg für den Aufbau von Android-UIs. Das View-Toolkit – die Welt aus TextView, ListView, ConstraintLayout und Fragment, auf der die meisten Produktions-Apps noch basieren – befindet sich im Wartungsmodus. Es erhält nur kritische Bugfixes und sonst nichts.

Google hat die Formulierung sorgfältig gewählt. Views sind nicht deprecated, und es gibt kein Entfernungsdatum. Aber „Wartungsmodus“ hat hier eine präzise Bedeutung. Keine neuen Features, keine neuen APIs, und alle neuen Android Studio UI-Tools sind eingefroren, einschließlich des Layout Editors und Navigation Editors. Neue Jetpack-Bibliotheken, Dokumentation, Codelabs und Beispiele werden Compose-first sein. Die offizielle Empfehlung ist klar: Neue UIs in Compose bauen und bestehende Screens beim Anfassen konvertieren.

Wir liefern seit Jahren native Android-Apps für das Gesundheitswesen, IoT und E-Commerce, und die meisten davon begannen als View-basierte Projekte. Das ist also für viele Teams eine echte Entscheidung, keine Schlagzeile. So interpretieren wir das.

Das praktische Risiko liegt nicht darin, dass Ihre App abstürzt. Das wird sie nicht. Das Risiko ist subtiler. Ihre Codebasis driftet still und leise auf eine nicht mehr unterstützte Insel. Jede neue Android-Funktion, jede neue Material-Komponente, jede Tooling-Verbesserung setzt jetzt Compose voraus. Ein Team, das 2027 noch mit Views arbeitet, ist nicht in Gefahr – es zahlt nur eine wachsende Gebühr in Form von Workarounds und fehlenden Features.

Der Instinkt, die gesamte App neu zu schreiben, ist der falsche. Wir haben erlebt, wie Big-Bang-UI-Rewrites monatelang stagnieren und Regressionen mit sich bringen, und Compose ist für den gegenteiligen Ansatz konzipiert. ComposeView und AndroidView ermöglichen es, Compose und Views auf demselben Screen – sogar im selben Layout – laufen zu lassen. Sie können einen Screen konvertieren, dann eine Komponente, und Nutzer sehen nie die Naht. Compose 1.11, ebenfalls auf der I/O vorgestellt, hat die Performance speziell für diese Hybrid-Screens verbessert.

Es gibt auch einen Personalaspekt, den man leicht übersieht. Compose ist das, was neue Android-Entwickler heute lernen. Kandidaten erwarten es, und die aktuelle Dokumentation setzt es voraus. Eine View-lastige Codebasis wird immer schwieriger zu besetzen, und diese Kosten bleiben unsichtbar, bis Sie drei Monate in einer Suche stecken.

Google hat außerdem einen Android Studio Migration Assistant vorgestellt, der einen KI-Agenten verwendet, um Screens zu portieren, und AI Studio kann jetzt Compose-Apps aus einem Prompt generieren. Das wird helfen. Aber aus unserer eigenen Arbeit mit KI-Agenten in echten Delivery-Pipelines wiederholt sich die Lektion immer wieder: Ein Agent, der einen Screen konvertiert, ist nur nützlich, wenn ein Entwickler, der Compose kennt, die Ausgabe überprüft. Behandeln Sie eine generierte Migration als Entwurf, nicht als Ergebnis. Die Teams, die Probleme bekommen, sind diejenigen, bei denen das Konvertierungsvolumen die Review-Kapazität übersteigt.

Wenn Sie eine View-basierte Android-App betreiben, tun Sie dieses Quartal eine konkrete Sache. Wählen Sie Ihren nächsten wirklich neuen Screen und bauen Sie ihn von Anfang bis Ende in Compose, mit ordentlich verdrahtetem Interop. Nicht als Spike, sondern als Screen, den Sie tatsächlich ausliefern. Diese eine Übung sagt Ihnen mehr als jedes Planungsdokument: wie Ihr Team mit Compose-Zustand umgeht, wo Ihr Designsystem Compose-Äquivalente benötigt, wie Ihr Build- und Test-Setup damit zurechtkommt. Setzen Sie dann eine einfache Regel. Jeder Screen, den Sie wesentlich anfassen, wird konvertiert. Stetig und unspektakulär – und es summiert sich.

Noch etwas für Teams, die sowohl iOS als auch Android betreiben. Compose-first auf Android deckt sich mit dem, wo SwiftUI auf iOS bereits steht. Beide Plattformen erwarten jetzt eine deklarative, zustandsgesteuerte UI-Schicht. Wenn Sie native iOS- und Android-Arbeit planen, ist dies ein guter Moment, Ihre Architektur so auszurichten, dass beide Plattformen auf die gleiche Weise über UI nachdenken. Das macht die Codebasen einfacher zu besetzen und einfacher zu reviewen – etwas, das wir über unsere vergangenen mobilen Projekte hinweg als lohnend erlebt haben.

Das ist kein Notfall. Es ist eine Richtung. Androids UI-Plattform hat jetzt einen klaren Standard, und die Kosten des Ignorierens sind kein Absturz. Es ist ein langsamer Aufbau von Reibung.

Wenn ein Stapel von View-basierten Android-Screens ohne klaren Migrationsplan vertraut klingt, sprechen Sie uns an.