Flutter jenseits vom Handy: Multi-Window, iPad und adaptive Layouts

Wir denken zu oft nur an Handys

Auf der FlutterCon 2026 gab es einen Talk, der mich bei einem Punkt erwischt hat: Ich baue Flutter-Apps fast immer für das Handy. Alles andere läuft nebenher mit.

David Castaño von Very Good Ventures hat genau das angesprochen. Wenn wir "Flutter" sagen, meinen wir meistens Android und iOS auf dem Smartphone. Dabei gibt es iPadOS. Und Android läuft längst auf sehr vielen verschiedenen Geräten.

Sein Punkt: Die Hardware ist weiter als unsere Apps.

Das Problem: Hochskalierte iPhone-Apps

Ein iPad Pro mit M4 oder M5 ist ein richtig starkes Gerät. Trotzdem laufen darauf oft dieselben Apps wie auf dem iPhone, nur größer dargestellt oder in einem kleinen Fenster.

Das Beispiel aus dem Talk: Hast du in Xcode nur iPhone als Ziel eingestellt, läuft deine App auf dem iPad in einem kleinen Fenster mit 390 x 844 Punkten. Drumherum ist leerer Platz. Du kannst es nicht aufziehen.

Der Fix für den ersten Schritt ist klein. Du aktivierst iPad-Support in den Projekteinstellungen. Ohne das gibt es kein Stretching, egal wie gut dein Layout ist.

Aber das ist nur die Tür. Danach brauchst du Layouts, die damit umgehen können.

Schritt 1: Scene Lifecycle wird Pflicht

Hier bin ich als Agenturinhaber hellhörig geworden. Das betrifft jede bestehende iOS-App.

Bisher hatte eine iOS-App einen App-Lifecycle: ein Fenster, eine Engine. Apple trennt das jetzt auf. Fenster werden zu eigenen Szenen mit eigenem Lebenszyklus. Dieser Scene Lifecycle ist ab dem SDK 27 verpflichtend. Wer ihn nicht übernommen hat, dessen App stürzt laut Talk sofort ab, wenn sie mit dem neuen SDK gebaut wird. Der Speaker hat das live gezeigt.

Der Auslöser ist laut Talk Apples Schritt Richtung Multi-Window auf dem iPhone, mit dem kommenden Dual-Screen-Gerät, das im Vortrag "iPhone Duo" hieß. Es ist das erste Mal, dass Apple Multi-Window auf ein iPhone bringt.

Was heißt das praktisch?

• Neuere Flutter-Versionen bringen die Boilerplate für Szenen mit. Der Speaker nannte "3.3.41" als Version, was vermutlich verhört ist. Prüf also selbst, ab welcher Flutter-Version das bei dir greift.
• Hast du den Standard-App-Delegate, wird automatisch migriert.
• Hast du einen eigenen App-Delegate oder Scene-Delegate, musst du von Hand ran. Router verdrahten, Plugins sauber registrieren.

Ich glaube: Wenn du eine ältere App hast, die seit einem Jahr niemand angefasst hat, ist das ein Wartungsthema, das du auf dem Schirm haben solltest. Nicht in Panik, aber eingeplant. Mehr dazu, warum laufende Pflege zur App gehört, steht in Was eine App laufend kostet.

Schritt 2: Adaptive Layouts statt Gerätelogik

Sobald iPad-Support an ist, brauchst du Layouts, die sich anpassen. Die Empfehlungen aus dem Talk sind bodenständig.

Schau auf die Box, nicht aufs Gerät

Frag nicht, ob du auf einem Handy oder Tablet bist. Frag, wie groß der Container ist, der deinen Inhalt hält. Heute ist es ein Handy, morgen ein Tablet, später vielleicht ein TV oder ein Bildschirm, den man beliebig aufziehen kann. Wer an Constraints denkt, ist für alles davon vorbereitet.

Bausteine statt Wände

Das Bild, das hängen geblieben ist: "Bricks, not walls". Baue deine UI aus kleinen, eigenständigen Teilen und nicht aus riesigen Seiten.

Das gilt auch für den State. Wenn Widgets und ihr Zustand granular sind, kannst du ein Widget auf einen anderen Screen setzen, und es funktioniert dort mit dem richtigen State. Auf dem Handy zeigst du eine Notiz. Auf dem iPad zeigst du Liste, Notiz und Werkzeuge nebeneinander, ohne zwischen Ansichten zu wechseln.

Das passt zu dem, was ich über State Management in Flutter denke. Kleine, klar geschnittene Cubits lassen sich leichter neu kombinieren als ein Bloc, der den halben Screen besitzt. Das ist meine Erfahrung, nicht Teil des Talks.

Die offizielle Doku dazu gibt es unter docs.flutter.dev/ui/adaptive-responsive, auf die der Speaker per QR-Code verwiesen hat.

Was du davon hast

Du nutzt den Platz besser. Mehr Inhalt gleichzeitig, weniger Wechsel. Und du bist für neue Formfaktoren gerüstet, etwa Geräte mit zwei Bildschirmen, die beim Öffnen, Schließen oder Drehen ihr Layout ändern.

Ein Beispiel aus dem Talk: Googles Edge-Gallery-App für lokale KI auf dem iPad. Der Speaker fand es schade, dass sie auf einem so starken Gerät nicht mehr herausholt. Dafür braucht es keine Multi-Window-Architektur, nur ein besseres Layout.

Schritt 3: Multi-Window, wo es Sinn ergibt

Jetzt wird es architektonisch. Und ich sage gleich: Das brauchen die wenigsten Apps.

Warum sich die Architektur ändert

Das Fenstersystem gehört dem Betriebssystem, nicht der Flutter-Engine. Jedes neue Fenster bekommt eine eigene Flutter-Engine. Was bisher in einer Engine lag, Services, State, gemeinsame Komponenten, ist damit weg, sobald diese Engine schließt.

Aktiviert wird Multi-Window in iOS über das Manifest. Dort stellst du die Unterstützung mehrerer Szenen auf true, standardmäßig ist sie aus.

Ein Hub, viele Fenster

Die vorgeschlagene Lösung: eine zentrale Headless-Engine und mehrere UI-Engines, eine pro Fenster.

• Die Headless-Engine hat keine UI. Sie hält den gemeinsamen State, die Services und Repositories.
• Die UI-Engines kümmern sich um Rendering und Navigation im jeweiligen Fenster.

UI-Logik bleibt im Fenster, App-weite Logik im Hub. Schließt der Nutzer ein Fenster, geht kein Zustand verloren.

Die Kommunikation läuft über Dart-Ports und einen Isolate-Name-Server. Jede Seite registriert einen Port, quasi einen Posteingang. Ändert sich im Fenster etwas, geht die Änderung an den Hub. Der verteilt den neuen Stand an alle Fenster. So bleiben sie synchron.

Auf Android sieht es analog aus: Dort sind es Tasks und Activities statt Szenen.

Ein Detail, das man leicht übersieht: In der Headless-Engine darfst du keine UI-Plugins nutzen, sonst crasht es. UI-Plugins laufen in den UI-Engines, Logik im Hub.

Der Window-Router

Offene Frage: Warum sollte jedes neue Fenster nicht einfach dieselbe Startseite zeigen? Die Antwort ist ein Window-Router, eine Art Fenster-Fabrik. Beim Öffnen übergibst du Parameter, und der Router entscheidet, welcher Widget-Baum geladen wird.

Die Demo

Der Speaker hat eine Notizen-App gebaut, die als Konferenz-Agenda diente. Notizen schreiben, jede in einem eigenen Fenster, nebeneinander, in der Größe veränderbar. Das fühlt sich an wie Desktop-Software. Auf dem Dual-Screen-Simulator lief dieselbe App mit Split View und mehreren Fenstern, und das Layout passte sich beim Öffnen und Drehen an.

Plugins sind der Stolperstein

Das fand ich den praktischsten Teil. Viele Plugins unterstützen den neuen Lifecycle noch nicht. Die Folgen laut Talk: Das Plugin tut nichts, die App stürzt ab, oder die UI taucht im falschen Fenster auf.

Früher haben Plugins oft auf das "Key Window" gesetzt. Jetzt müssen sie wissen, aus welcher Szene sie aufgerufen werden, und ihre UI dort anzeigen. Das heißt: weg vom App-Delegate, hin zum Scene-Delegate.

Mein Take dazu: Bevor du ein Projekt auf den neuen Lifecycle hebst, geh deine Dependencies durch. Wer Plugins mit nativer UI nutzt, etwa Kamera, Dokumentenscanner oder Login-Dialoge, sollte dort zuerst nachschauen. Das ist eine Einschätzung von mir, der Talk hat keine einzelnen Plugins genannt.

Was das für Kundenprojekte heißt

Ich sortiere das für mich so. Das ist meine Meinung, nicht die des Speakers.

Scene Lifecycle: Pflicht. Das ist der einzige Punkt, der dich zum Handeln zwingt. Bestehende iOS-Apps gehören auf die Liste für das nächste Wartungsfenster.

iPad-Support: oft ein günstiger Gewinn. Wenn deine Zielgruppe iPads nutzt, etwa im Gesundheitswesen, in der Gastronomie oder auf der Baustelle, lohnt sich ein ordentliches Tablet-Layout. Der Aufwand hängt davon ab, wie granular die App gebaut ist. Wenn du dir unsicher bist, ob Flutter dafür taugt: Es ist genau das, wofür ich Flutter mag. Eine Codebasis, mehrere Formfaktoren.

Multi-Window: nur mit klarem Nutzen. Eine Terminbuchungs-App braucht kein Multi-Window. Ein Editor, ein Dashboard oder ein Tool mit mehreren parallelen Dokumenten vielleicht schon. Der Aufwand ist real, weil du eine zweite Ebene Architektur einziehst.

Desktop-Denke zahlt sich aus. Wer Apps für mehrere Fenster und Größen denkt, baut meistens auch sauberer. Das hilft bei Flutter im Web genauso wie auf dem Tablet.

Wenn du dir gerade überlegst, eine App bauen zu lassen, sag mir früh, auf welchen Geräten sie laufen soll. Das verändert Layout und Architektur. Mehr dazu in App entwickeln lassen.

Fazit

Der Talk war kein Aufruf, alles auf Multi-Window umzubauen. Er sagt: Denk über das Handy hinaus. Der Scene Lifecycle ist die Pflicht, adaptive Layouts sind die Chance, und Multi-Window mit Headless-Hub ist nur für Apps gedacht, die wie Desktop-Software arbeiten sollen.

Ich nehme mit: alte iOS-Apps prüfen, Layouts auf Constraints und kleine Bausteine umstellen, Plugins checken, bevor es knallt.

Häufig gestellte Fragen (FAQ)

Dieser Artikel wurde inspiriert vom Talk über Multi-Window und adaptive UIs in Flutter von David Castaño (Very Good Ventures) auf der FlutterCon 2026.