iPad Split View und Multitasking-Layouts unterstützen

1. Überblick über die iPadOS-Multitasking-Modi

iPadOS kennt mehrere unterschiedliche Multitasking-Zustände, die sich für eine App grundlegend unterscheiden: Im klassischen Vollbild-Modus nimmt die App den gesamten verfügbaren Bildschirmbereich ein, während Split View den Bildschirm zwischen zwei Apps aufteilt und dabei je nach gewählter Aufteilung Fensterbreiten von nur etwa einem Drittel bis zur Hälfte des Bildschirms zulässt. Slide Over legt eine dritte App als schwebendes, kleineres Fenster über die beiden anderen, wodurch eine App plötzlich in einem deutlich schmaleren, vertikal orientierten Fenster dargestellt wird, unabhängig von der tatsächlichen physischen Ausrichtung des iPads.

Stage Manager, auf neueren iPad-Modellen verfügbar, erweitert dieses Konzept zusätzlich um frei skalierbare, überlappende Fenster, deren Größe die Nutzerin oder der Nutzer per Ziehen an der Fensterecke beliebig verändern kann, ähnlich wie auf einem Desktop-Betriebssystem. Für eine React-Native-App bedeutet dieser gesamte Modus-Katalog, dass die verfügbare Bildschirmfläche zur Laufzeit nicht als feste Konstante behandelt werden darf, sondern als Wert, der sich jederzeit ändern kann, während die App bereits läuft.

2. Wie eine App von Fenstergrößenänderungen erfährt

Der useWindowDimensions-Hook aus dem React-Native-Kern liefert die aktuelle Breite und Höhe des für die App verfügbaren Fensters und löst automatisch ein Re-Rendering der aufrufenden Komponente aus, sobald sich diese Werte ändern, etwa weil die Nutzerin die Grenze zwischen zwei Apps in Split View verschiebt. Im Unterschied zur statischen Dimensions.get('window')-API, die den Wert nur einmalig zum Zeitpunkt des Aufrufs liefert, reagiert useWindowDimensions kontinuierlich auf jede Änderung, was ihn zur bevorzugten Wahl für jede Komponente macht, deren Layout von der tatsächlichen Fenstergröße abhängt.

Für Fälle, in denen eine Fenstergrößenänderung außerhalb des React-Render-Zyklus behandelt werden muss, etwa um eine native Animation anzustoßen, stellt die Dimensions-API zusätzlich einen addEventListener für das change-Event bereit, über den sich auf dieselbe Änderung auch imperativ reagieren lässt. In den meisten Fällen genügt jedoch der deklarative useWindowDimensions-Hook vollständig, weil React ohnehin bereits für Re-Renders bei Zustandsänderungen zuständig ist.

import { useWindowDimensions, View } from 'react-native';

function ProductLayout() {
  const { width } = useWindowDimensions();
  const isCompact = width < 600;

  return (
    <View style={{ flexDirection: isCompact ? 'column' : 'row' }}>
      <ProductList compact={isCompact} />
      <ProductDetail visible={!isCompact} />
    </View>
  );
}

3. Fixe Vollbild-Annahmen im bestehenden Code identifizieren

Der zuverlässigste Weg, versteckte Vollbild-Annahmen in einer bestehenden Codebasis aufzuspüren, ist eine gezielte Suche nach Dimensions.get('window') sowie nach hartcodierten Pixelwerten in Style-Definitionen, die erkennbar von der vollen iPad-Breite ausgehen, etwa width: 1024 oder eine feste Spaltenanzahl in einem Grid, die keine Rücksicht auf eine mögliche Verkleinerung nimmt. Besonders häufig betroffen sind Layouts, die zum Zeitpunkt des Komponenten-Mountens einmalig die Fensterbreite abfragen und das Ergebnis anschließend in einem lokalen State ablegen, ohne auf spätere Änderungen zu reagieren.

Eine zweite, weniger offensichtliche Fehlerquelle liegt in Bedingungen, die Tablet-spezifisches Verhalten ausschließlich anhand des Geräts selbst statt anhand der tatsächlich verfügbaren Fensterbreite bestimmen, etwa eine Prüfung wie Platform.isPad, die auch dann true zurückgibt, wenn die App gerade in einem schmalen Slide-Over-Fenster läuft. Für zuverlässiges Verhalten sollte die tatsächliche Breite über useWindowDimensions und nicht die Geräteklasse selbst über die Layout-Entscheidung bestimmen.

4. Responsive Layout-Strategien statt fester Vollbild-Annahmen

Statt feste Pixelwerte in Style-Objekten zu verwenden, sollte ein Layout konsequent auf Flexbox-Eigenschaften wie flex, flexWrap und minWidth aufbauen, die sich unabhängig von der tatsächlich verfügbaren Breite proportional verhalten und dadurch automatisch mit dem Fenster mitwachsen oder schrumpfen. Für strukturelle Entscheidungen, die sich nicht rein über Flexbox lösen lassen, etwa ob eine zweispaltige Ansicht überhaupt sinnvoll ist oder auf eine einspaltige Darstellung umgeschaltet werden muss, eignen sich klar definierte Breakpoints, die auf denselben von useWindowDimensions gelieferten Wert reagieren.

Bewährt hat sich in der Praxis ein zentraler useBreakpoint-Hook, der die aktuelle Fensterbreite in benannte Kategorien wie compact, regular und expanded übersetzt, ähnlich dem Size-Class-Konzept aus UIKit, statt in jeder einzelnen Komponente eigene, möglicherweise inkonsistente Breitenschwellen zu definieren. Dieser gemeinsame Hook sorgt dafür, dass sich alle Komponenten der App an denselben Schwellenwerten orientieren und beim Wechsel zwischen Split View und Vollbild ein konsistentes, statt fragmentiertes Layout-Verhalten zeigen.

import { useWindowDimensions } from 'react-native';

type Breakpoint = 'compact' | 'regular' | 'expanded';

function useBreakpoint(): Breakpoint {
  const { width } = useWindowDimensions();
  if (width < 600) return 'compact';
  if (width < 900) return 'regular';
  return 'expanded';
}

function CatalogScreen() {
  const breakpoint = useBreakpoint();
  const columns = breakpoint === 'compact' ? 1 : breakpoint === 'regular' ? 2 : 3;

  return <ProductGrid columns={columns} />;
}

5. Safe Area im Zusammenspiel mit Multitasking

react-native-safe-area-context liefert die aktuellen Safe-Area-Insets, also den Abstand zu Notch, Home-Indikator und abgerundeten Ecken, wobei sich diese Werte im Split-View- oder Slide-Over-Modus von den Werten im Vollbild-Modus unterscheiden können, weil sich die relative Position der App-Fläche innerhalb des physischen Bildschirms verändert. Eine App, die in Slide Over als schmales, zentriertes Fenster über einer anderen App liegt, hat beispielsweise andere effektive Ränder als dieselbe App im Vollbild-Modus, obwohl das physische Gerät identisch bleibt.

Der SafeAreaProvider aus react-native-safe-area-context reagiert automatisch auf diese Änderungen und aktualisiert die über useSafeAreaInsets gelieferten Werte, sobald sich der Multitasking-Zustand ändert, sodass eine Komponente, die ihre Insets korrekt über den Hook statt über fest angenommene Werte bezieht, in jedem Multitasking-Zustand automatisch korrekt bleibt, ohne dass zusätzlicher Code für die Erkennung des jeweiligen Modus geschrieben werden müsste.

6. Info.plist-Konfiguration für Multitasking-Unterstützung

Damit eine iPad-App Split View und Slide Over überhaupt unterstützt, muss in der Info.plist der Schlüssel UIRequiresFullScreen entweder gar nicht gesetzt oder explizit auf false stehen, weil sein Fehlen in älteren, aus Vorlagen erzeugten Projekten mitunter noch auf true voreingestellt ist und die App dadurch dauerhaft aus dem Multitasking-Verbund ausschließt. Zusätzlich müssen alle unterstützten Interface-Orientierungen sowohl für iPhone als auch für iPad korrekt in UISupportedInterfaceOrientations~ipad deklariert sein, da Multitasking-Fenster auf dem iPad unabhängig von der physischen Geräteausrichtung in beiden Achsen auftreten können.

Für Expo-Projekte lässt sich diese Konfiguration über den ios.requireFullScreen-Schlüssel in der app.json direkt steuern, ohne die native Info.plist manuell zu bearbeiten, wobei der Wert dort bewusst auf false gesetzt werden muss, weil Expo bei neu erzeugten Projekten standardmäßig einen konservativeren Vollbild-Modus aktiviert, der Multitasking sonst effektiv deaktiviert, selbst wenn der restliche Code bereits vollständig responsiv aufgebaut ist.

{
  "expo": {
    "ios": {
      "requireFullScreen": false,
      "supportsTablet": true
    }
  }
}

7. Stage Manager: frei skalierbare Fenster als weitere Stufe

Stage Manager erweitert die klassischen Split-View- und Slide-Over-Modi um frei durch Ziehen skalierbare Fenster, deren Größe sich nicht mehr auf eine begrenzte Anzahl fester Verhältnisse beschränkt, sondern kontinuierlich zwischen einer minimalen und der vollen Bildschirmbreite variieren kann. Für eine React-Native-App bedeutet das, dass Breakpoints nicht als starre, wenige feste Stufen gedacht werden sollten, sondern das Layout auch bei ungewöhnlichen Zwischenbreiten, etwa 740 statt eines der klassischen Split-View-Werte, weiterhin sinnvoll aussehen muss.

Praktisch bedeutet das vor allem, Breakpoint-Grenzen als Bereiche statt als exakte, erwartete Werte zu behandeln, und jedes Layout unabhängig von der genauen Pixelzahl auf Konsistenz zu prüfen, statt sich auf eine kleine, feste Liste bekannter iPad-Auflösungen zu verlassen, die durch Stage Manager ohnehin nicht mehr vollständig ist. Ein Layout, das nur bei exakt 768 oder 1024 Pixel Breite korrekt aussieht, aber bei 850 Pixel bricht, ist in einer Stage-Manager-Welt keine robuste Lösung mehr.

8. Testing-Ansatz für verschiedene Multitasking-Zustände

Der iOS Simulator in Xcode unterstützt Split View und Slide Over direkt über die Simulator-Menüleiste beziehungsweise durch das manuelle Ziehen einer zweiten simulierten App an den Bildschirmrand, wodurch sich die wichtigsten Multitasking-Übergänge bereits während der Entwicklung ohne physisches Gerät testen lassen. Für eine systematische Prüfung lohnt sich eine kleine Checkliste, die neben dem reinen Vollbild-Zustand mindestens die Ein-Drittel- und Zwei-Drittel-Aufteilung in Split View sowie Slide Over in beiden möglichen Bildschirmhälften abdeckt.

Ergänzend zur manuellen Prüfung lässt sich mit Detox oder Maestro ein automatisierter Test schreiben, der die App bei mehreren simulierten Fensterbreiten rendert und über Snapshot-Vergleiche prüft, ob zentrale Layout-Elemente wie Navigationsleisten oder Aktions-Buttons bei keiner der getesteten Breiten abgeschnitten werden oder überlappen. Diese automatisierten Prüfungen ersetzen keine echte Beobachtung auf einem physischen iPad, verhindern aber zuverlässig, dass eine spätere Code-Änderung eine zuvor bereits funktionierende Breite unbemerkt wieder zerstört.

9. Praxisbeispiel: adaptives Grid-Layout für eine Produktliste

Eine Produktlisten-Ansicht, die im Vollbild-Modus eines großen iPads drei oder vier Spalten anzeigt, muss in Split View mit halber Bildschirmbreite auf zwei Spalten reduzieren und in Slide Over oder einer sehr schmalen Stage-Manager-Fensterbreite auf eine einzelne Spalte umschalten, damit einzelne Produktkarten nicht unter eine sinnvolle Mindestbreite gequetscht werden. Die Spaltenanzahl sollte dabei nicht aus einer festen Fenstergrößen-Tabelle abgeleitet werden, sondern direkt aus der verfügbaren Breite geteilt durch eine definierte Mindestbreite pro Karte, damit auch ungewöhnliche Zwischenbreiten unter Stage Manager ein sauberes Ergebnis liefern.

In der Praxis liefert eine einfache Formel wie Math.max(1, Math.floor(width / 280)) für eine Mindestkartenbreite von 280 Pixeln ein robusteres Ergebnis als eine Liste fest definierter Breakpoints, weil sie sich kontinuierlich an jede beliebige Fensterbreite anpasst, statt bei bestimmten, im Vorfeld nicht bedachten Zwischenwerten sichtbar zu springen oder unpassend auszusehen.

import { useWindowDimensions, FlatList } from 'react-native';

const MIN_CARD_WIDTH = 280;

function ProductGrid({ products }: { products: Product[] }) {
  const { width } = useWindowDimensions();
  const columns = Math.max(1, Math.floor(width / MIN_CARD_WIDTH));

  return (
    <FlatList
      key={columns} // erzwingt Neuaufbau bei geänderter Spaltenanzahl
      data={products}
      numColumns={columns}
      renderItem={({ item }) => <ProductCard product={item} />}
    />
  );
}

10. Zusammenfassung

11. FAQ: iPad Split View und Multitasking: Das Wichtigste auf einen Blick