React Native Tablet- und Foldable-Support: Responsive Layouts

1. Warum Phone-First-Layouts auf Tablet und Foldable brechen

Die meisten React-Native-Apps entstehen als Phone-First-Layout: eine Spalte, feste Pixelwerte für Padding und Bildhöhen, Touch-Targets für den Daumen einer Hand. Sobald dieselbe App auf einem 11-Zoll-iPad oder einem aufgeklappten Foldable läuft, zeigt sich das Problem sofort. Eine Produktliste, die auf dem Phone sinnvoll eine Spalte füllt, lässt auf dem Tablet zwei Drittel des Bildschirms leer oder zieht Textzeilen unnatürlich in die Breite. Responsive Layouts sind hier keine kosmetische Ergänzung, sondern die Voraussetzung dafür, dass eine App auf größeren Screens überhaupt benutzbar wirkt.

Fixe Pixelwerte sind die Wurzel des Problems. Ein Container mit width: 320 oder ein Bild mit fester Höhe von 200 Pixeln geht implizit davon aus, dass der verfügbare Platz begrenzt ist. Auf einem großen Tablet oder im aufgeklappten Zustand eines Foldables steht plötzlich doppelt oder dreifach so viel horizontaler Raum zur Verfügung, und ein Single-Column-Layout verschenkt genau diesen Raum. Für echten Tablet- und Foldable-Support müssen Layout-Entscheidungen relativ zur verfügbaren Fläche getroffen werden, nicht relativ zu einem angenommenen Phone-Viewport.

Auch Touch-Targets sind ein unterschätztes Detail. Ein Button, der für die einhändige Bedienung am unteren Bildschirmrand eines Phones optimiert ist, sitzt auf einem 12,9-Zoll-iPad möglicherweise außerhalb der bequemen Reichweite eines Daumens, während der Nutzer die Tastatur oder den Apple Pencil in der anderen Hand hält. Interaktionsmuster, die auf dem Phone selbstverständlich sind, verlangen auf größeren Screens eine bewusste Neubewertung, wo primäre Aktionen platziert werden und wie groß Tap-Flächen ausfallen müssen.

2. Screengröße erkennen: useWindowDimensions vs. Dimensions.get

React Native bietet zwei Wege, um die aktuelle Fenstergröße zu ermitteln: die imperative API Dimensions.get('window') und den Hook useWindowDimensions(). Der entscheidende Unterschied liegt im Re-Render-Verhalten. Dimensions.get liefert einen Snapshot zum Zeitpunkt des Aufrufs und aktualisiert die Komponente nicht automatisch, wenn sich die Fenstergröße ändert. Bei einer Rotation, beim Auf- oder Zuklappen eines Foldables oder bei einer Größenänderung im iPad-Split-View bleibt die Komponente auf dem alten Wert stehen, bis sie aus einem anderen Grund neu gerendert wird.

useWindowDimensions abonniert dagegen intern das Change-Event von Dimensions und triggert bei jeder Änderung automatisch ein Re-Render der Komponente. Für responsive Layouts, die auf Rotation, Fold-Events und Multitasking-Größenänderungen reagieren sollen, ist der Hook deshalb fast immer die richtige Wahl. Eine zentrale Breakpoint-Logik lässt sich sauber als eigener Hook kapseln, der auf Basis der aktuellen Breite eine Kategorie zurückgibt, statt in jeder Komponente einzelne Zahlenvergleiche zu wiederholen.

Wichtig ist, die Breakpoints an echten Layout-Bedürfnissen auszurichten und nicht an Geräteklassen. Ein Foldable im gefalteten Zustand verhält sich layouttechnisch wie ein schmales Phone, im aufgeklappten Zustand wie ein kleines Tablet, unabhängig vom Marketingnamen des Geräts. Drei Kategorien reichen für die meisten Apps: Phone bis etwa 600 Logical Pixels, Tablet zwischen 600 und 900, große Tablets und aufgeklappte Foldables darüber.

// hooks/useBreakpoint.js
// Custom hook wrapping useWindowDimensions with a stable breakpoint API
import { useWindowDimensions } from 'react-native';

const BREAKPOINTS = {
  phone: 0,
  tablet: 600,
  largeTablet: 900,
};

export function useBreakpoint() {
  // useWindowDimensions re-renders on rotation, fold and multitasking resize
  const { width, height } = useWindowDimensions();

  const isTablet = width >= BREAKPOINTS.tablet;
  const isLargeTablet = width >= BREAKPOINTS.largeTablet;
  const isLandscape = width > height;

  let breakpoint = 'phone';
  if (isLargeTablet) breakpoint = 'largeTablet';
  else if (isTablet) breakpoint = 'tablet';

  return { width, height, breakpoint, isTablet, isLargeTablet, isLandscape };
}

// Usage in a component
function ProductGrid() {
  const { breakpoint, isTablet } = useBreakpoint();
  const columns = breakpoint === 'largeTablet' ? 4 : breakpoint === 'tablet' ? 3 : 1;

  return <ProductList numColumns={columns} showSidebar={isTablet} />;
}

3. Safe-Area-Handling für Notches und Multitasking-Insets

Safe-Area-Insets sind auf dem Phone meist eine Randnotiz: eine Notch oben, eine Home-Indicator-Leiste unten. Auf Tablets und im iPad-Multitasking werden sie zum aktiven Layout-Faktor. react-native-safe-area-context liefert über useSafeAreaInsets() die aktuellen Insets, und der entscheidende Punkt für Tablet- und Foldable-Support ist, dass sich diese Werte dynamisch ändern, wenn die App in Split View oder Slide Over verschoben wird, nicht nur beim App-Start einmalig ermittelt werden.

Im Split View auf dem iPad bekommt eine App plötzlich einen schmaleren Viewport, während die abgerundeten Ecken und eventuelle Notch-Bereiche weiterhin relativ zum Gesamtbildschirm existieren, nicht relativ zum reduzierten App-Fenster. Eine App, die im Slide-Over-Modus als schwebendes Fenster über einer anderen App liegt, hat zusätzlich abgerundete Ecken auf allen vier Seiten, die in der Vollbildansicht nicht vorhanden sind. Wer Insets einmalig beim Mount abfragt und danach als Konstante behandelt, produziert genau in diesen Übergängen sichtbar falsch positionierte Header und Footer.

Auf Foldables kommt ein weiterer Fall hinzu: Im gefalteten Zustand mit Außendisplay gelten andere Insets als im aufgeklappten Zustand mit Innendisplay, und der Übergang zwischen beiden passiert oft ohne vollständigen Remount der App. Der SafeAreaProvider muss deshalb hoch genug im Baum sitzen, dass er bei jeder relevanten Layout-Änderung neu misst, und Komponenten sollten Insets über den Hook konsumieren statt sie in lokalem State zu duplizieren.

4. Adaptive Layout-Patterns: Master-Detail, Grid, Navigation

Das Master-Detail-Pattern ist das wichtigste Werkzeug für responsive Layouts in Listen-Detail-Anwendungen. Auf dem Phone wird eine Liste angezeigt, ein Tap navigiert per Stack auf einen eigenen Detail-Screen. Ab einem definierten Breakpoint, typischerweise dem Tablet-Breakpoint, wechselt dieselbe Ansicht in eine Split-View-Darstellung: Liste links, Detail rechts, beide gleichzeitig sichtbar, ohne Navigation. Die Herausforderung liegt darin, diesen Wechsel ohne doppelte Codepfade umzusetzen, sondern über eine gemeinsame State-Quelle, die je nach Breakpoint entweder als Navigation-Push oder als parallele Darstellung interpretiert wird.

Responsive Grid-Systeme lösen das analoge Problem für Karten- und Produktlisten: Die Anzahl der Spalten hängt von der verfügbaren Breite ab, nicht von einer festen Konstante. Ein Grid mit einer Spalte auf dem Phone, drei Spalten auf dem Tablet und vier bis fünf Spalten auf einem großen, aufgeklappten Foldable nutzt die Fläche proportional aus, ohne dass einzelne Karten unnatürlich gestreckt werden. Wichtig ist, die Spaltenanzahl an Breite und einem Mindest-Kartendurchmesser zu berechnen, statt einen fixen Wert pro Breakpoint hart zu codieren.

Conditional Navigation ergänzt beide Patterns: Auf dem Phone bleibt eine Stack-Navigation mit vollflächigen Screens sinnvoll, auf dem Tablet kann eine permanent sichtbare Seitenleiste oder ein Drawer die Navigation übernehmen, weil genug horizontale Fläche vorhanden ist, um Navigation und Inhalt gleichzeitig zu zeigen. Die Navigationsbibliothek muss diesen Wechsel unterstützen, ohne dass beim Überschreiten des Breakpoints der gesamte Navigationsstatus verloren geht.

// components/MasterDetailLayout.jsx
// Responsive master-detail layout: stack navigation on phone, split view on tablet
import { View, StyleSheet } from 'react-native';
import { useBreakpoint } from '../hooks/useBreakpoint';

export function MasterDetailLayout({ list, selectedId, onSelect, renderDetail }) {
  const { isTablet } = useBreakpoint();

  if (!isTablet) {
    // Phone: only list or only detail is visible, navigation handles the rest
    return selectedId
      ? <View style={styles.flexFill}>{renderDetail(selectedId)}</View>
      : <View style={styles.flexFill}>{list}</View>;
  }

  // Tablet and larger: list and detail side by side
  return (
    <View style={styles.row}>
      <View style={styles.listPane}>
        {list}
      </View>
      <View style={styles.flexFill}>
        {selectedId ? renderDetail(selectedId) : <EmptyDetailState />}
      </View>
    </View>
  );
}

const styles = StyleSheet.create({
  flexFill: { flex: 1 },
  row: { flex: 1, flexDirection: 'row' },
  listPane: { width: 360, borderRightWidth: 1, borderColor: '#e2e8f0' },
});

5. iPad-Multi-Window: Slide Over, Split View, Stage Manager

Multi-Window auf iPadOS bringt drei relevante Modi mit sich: Split View, in dem zwei Apps nebeneinander laufen und sich der verfügbare Platz per Ziehpunkt anpassen lässt, Slide Over, in dem eine App als schwebendes, kleineres Fenster über einer anderen liegt, und Stage Manager, das mehrere frei skalierbare Fenster gleichzeitig erlaubt. Für Tablet- und Foldable-Support bedeutet das, dass sich die Fenstergröße der App jederzeit ändern kann, ohne dass ein Nutzer die App aktiv neu startet oder ein Gerät dreht.

Die praktische Konsequenz: Eine App darf beim Ressourcenverbrauch nicht davon ausgehen, dass die aktuelle Fenstergröße stabil bleibt, und sie darf bei einer Größenänderung nicht mit einem vollständigen Remount reagieren. Ein Remount verliert Scroll-Positionen, Formulareingaben und Navigationszustand, was in einem Slide-Over-Fenster, das ein Nutzer während der Arbeit an einer anderen App kurz aufzieht, extrem störend wirkt. Layout-Entscheidungen müssen deshalb rein auf Basis der aktuellen Breite aus useWindowDimensions getroffen werden, während der darunterliegende Komponentenbaum stabil bleibt.

Stage Manager verschärft das Problem zusätzlich, weil Nutzer Fenster frei in der Größe ziehen können und die App in Echtzeit auf beliebige Zwischengrößen reagieren muss, nicht nur auf ein festes Set von Standardgrößen. Ein Layout, das nur für drei feste Breakpoints getestet wurde, zeigt in solchen Zwischenzuständen oft abgeschnittenen Text oder überlappende Elemente. Kontinuierliches, proportionales Skalieren statt harter Sprünge an einzelnen Pixelwerten reduziert dieses Risiko deutlich.

6. Foldable-Support auf Android: Hinge und Jetpack WindowManager

Android-Foldables bringen ein Layout-Problem mit, das es auf iPad nicht gibt: die Hinge, also den physischen Falzbereich, der bei manchen Geräten das Display in zwei visuelle Hälften teilt oder eine tote Zone verursacht, über die kein Content platziert werden sollte. Zusätzlich muss eine App die aktuelle Faltungshaltung kennen, etwa flach aufgeklappt, halb geöffnet im Tabletop-Modus oder vollständig gefaltet, weil sich daraus sinnvolle Layout-Entscheidungen ergeben, etwa ein geteiltes Layout im Tabletop-Modus mit Steuerung unten und Inhalt oben.

React Native Core exponiert diese Informationen nicht. Die Jetpack-WindowManager-Bibliothek von Android liefert über WindowInfoTracker die Fold-Geometrie, den Fold-Status und die Posture, aber der Zugriff darauf erfordert eine native Bridge, weil diese APIs nur auf Kotlin- beziehungsweise Java-Ebene existieren. Ein natives Modul liest die Fold-Daten über einen Flow-Listener aus und sendet sie als Event an die JavaScript-Seite, wo sie zusammen mit den Ergebnissen aus useWindowDimensions die endgültige Layout-Entscheidung bestimmen. Für echten Tablet- und Foldable-Support auf Android führt an dieser nativen Bridge kein Weg vorbei.

Kontinuität über den Faltvorgang hinweg ist der zweite kritische Punkt. Wenn ein Nutzer ein Gerät während der Nutzung auf- oder zuklappt, darf die App weder ihren Navigationsstatus noch Formulareingaben verlieren, selbst wenn sich die Fensterkonfiguration technisch ändert. Der native Listener sollte deshalb als reine Datenquelle für Layout-Entscheidungen dienen und niemals einen Reload oder Remount der React-Native-Instanz auslösen.

// android/app/src/main/java/com/example/app/FoldStateModule.kt
// Native module bridging Jetpack WindowManager fold state to JavaScript
package com.example.app

import androidx.window.layout.WindowInfoTracker
import androidx.window.layout.FoldingFeature
import com.facebook.react.bridge.*
import com.facebook.react.modules.core.DeviceEventManagerModule
import kotlinx.coroutines.*

class FoldStateModule(reactContext: ReactApplicationContext) :
    ReactContextBaseJavaModule(reactContext) {

    private val scope = CoroutineScope(Dispatchers.Main + SupervisorJob())

    override fun getName() = "FoldStateModule"

    @ReactMethod
    fun startObserving() {
        val activity = currentActivity ?: return
        val tracker = WindowInfoTracker.getOrCreate(activity)

        scope.launch {
            tracker.windowLayoutInfo(activity).collect { layoutInfo ->
                val feature = layoutInfo.displayFeatures
                    .filterIsInstance<FoldingFeature>()
                    .firstOrNull()

                val payload = Arguments.createMap().apply {
                    putBoolean("isSeparating", feature?.isSeparating ?: false)
                    putString("orientation", feature?.orientation?.toString() ?: "NONE")
                    // FLAT, HALF_OPENED, or NONE when no folding feature is present
                    putString("state", feature?.state?.toString() ?: "FLAT")
                }
                sendEvent("foldStateChanged", payload)
            }
        }
    }

    private fun sendEvent(eventName: String, params: WritableMap) {
        reactApplicationContext
            .getJSModule(DeviceEventManagerModule.RCTDeviceEventEmitter::class.java)
            .emit(eventName, params)
    }
}

7. Orientation-Handling ohne Verlust von Scroll- und Formularstatus

Nicht jeder Screen profitiert von freier Rotation. Ein Kamera-Screen oder ein Video-Player kann sinnvoll auf Landscape gelockt werden, während eine Formular- oder Listenansicht in beiden Orientierungen funktionieren sollte, besonders auf Tablet und aufgeklapptem Foldable, wo Landscape oft der natürlichere Zustand ist. Die Entscheidung zwischen Locking und freier Rotation sollte deshalb pro Screen getroffen werden, nicht global für die gesamte App, weil ein globales Lock auf großen Screens genau die responsive Layouts zunichtemacht, die für Tablet-Nutzung sinnvoll wären.

Der technisch heikle Teil ist, was bei einer tatsächlichen Rotation mit dem bestehenden Zustand passiert. React Native rendert Komponenten bei einer Orientierungsänderung nicht automatisch neu auf, solange kein Remount ausgelöst wird, aber schlecht geschriebene Layout-Logik, die auf Basis von Orientation-Checks bedingt Komponenten unmountet und neu mountet, verliert dabei Scroll-Positionen in Listen und unkontrollierte Formulareingaben, die nicht in einem übergeordneten State gehalten werden.

Die robuste Lösung ist, Formularstatus grundsätzlich außerhalb der Layout-Komponente zu halten, etwa in einem Formular-State-Management oder in einem Context, der von der Orientierung unabhängig ist, und Scroll-Positionen über onScroll in einer Ref statt in lokalem State zu tracken, damit sie bei einem Re-Render aus anderen Gründen nicht zurückgesetzt werden. Die Layout-Struktur selbst darf sich bei Rotation ändern, aber die zugrunde liegenden Daten und Eingaben müssen unabhängig davon erhalten bleiben.

8. Responsive Typografie und Spacing statt fixer Werte

Feste Schriftgrößen und Abstände sind das gleiche Problem wie feste Pixelbreiten, nur im Detail statt im Grobraster. Ein Fließtext mit 16 Pixeln wirkt auf dem Phone lesbar, auf einem großen Tablet in Armlänge Entfernung aber unangenehm klein. Statt einzelner harter Werte in jeder Komponente sollte ein zentrales Token-System Schriftgrößen und Abstände pro Breakpoint definieren, sodass eine Komponente einen semantischen Wert wie spacing.md referenziert und die konkrete Zahl je nach aktivem Breakpoint aufgelöst wird.

Ein häufiger Fehler ist, diese Entscheidung an die Geräteerkennung statt an die tatsächliche Bildschirmgröße zu koppeln, etwa über Platform.isPad. Das Flag unterscheidet nur zwischen iPhone und iPad, kennt aber weder Android-Tablets noch die tatsächliche aktuelle Fenstergröße im Multitasking oder auf einem Foldable. Ein iPad im Slide-Over-Modus hat effektiv eine Phone-große Fensterbreite, würde mit einer Platform.isPad-Prüfung aber trotzdem die Tablet-Typografie erhalten und Text abgeschnitten oder überlappend darstellen.

Die korrekte Grundlage bleibt die tatsächliche Breite aus useWindowDimensions, kombiniert mit demselben Breakpoint-System, das auch für Grid-Spalten und Navigation verwendet wird. So skalieren Schriftgröße, Zeilenhöhe und Abstände konsistent mit dem restlichen Layout, und ein Token-basiertes System erlaubt es, diese Werte an einer Stelle zu pflegen, statt sie über Dutzende Komponenten verteilt hart zu codieren.

{
  "breakpoints": {
    "phone": 0,
    "tablet": 600,
    "largeTablet": 900
  },
  "spacing": {
    "phone":       { "xs": 4, "sm": 8, "md": 16, "lg": 24, "xl": 32 },
    "tablet":      { "xs": 6, "sm": 12, "md": 24, "lg": 36, "xl": 48 },
    "largeTablet": { "xs": 8, "sm": 16, "md": 32, "lg": 48, "xl": 64 }
  },
  "typography": {
    "phone":       { "body": 16, "heading": 22, "caption": 12, "lineHeight": 1.4 },
    "tablet":      { "body": 17, "heading": 26, "caption": 13, "lineHeight": 1.45 },
    "largeTablet": { "body": 18, "heading": 30, "caption": 14, "lineHeight": 1.5 }
  }
}

9. Testing-Strategie für Tablet- und Foldable-Layouts

Responsive Layouts, die nur auf einem einzigen Simulator getestet werden, geben eine trügerische Sicherheit. Auf iOS-Seite bedeutet ein realistischer Testplan mindestens drei Simulator-Größen: ein kompaktes iPhone, ein 11-Zoll-iPad und ein 12,9-Zoll-iPad, jeweils zusätzlich im Split-View- und Slide-Over-Modus geprüft, weil sich dort die effektive Fenstergröße unabhängig vom physischen Gerät ändert. Reine Portrait-Tests auf dem größten iPad reichen nicht aus, um Multitasking-Bugs aufzudecken.

Auf Android-Seite lässt sich über den Android Studio Device Manager oder direkt per avdmanager ein Foldable-Emulator-Profil erzeugen, das dem Galaxy-Fold-Formfaktor nachempfunden ist und sowohl den gefalteten als auch den aufgeklappten Zustand simulieren kann. Zusätzlich empfiehlt sich ein separates Tablet-Profil mit klassischer 10-Zoll-Auflösung, um sicherzustellen, dass die Breakpoint-Logik auch ohne Fold-spezifische APIs korrekt greift, denn nicht jedes Android-Tablet hat eine Hinge.

Visuelle Regressionstests bringen bei Multi-Window-Resizing ein spezifisches Risiko mit sich: Ein Screenshot-Test, der nur eine feste Fenstergröße abdeckt, übersieht Layout-Brüche bei Zwischengrößen, die etwa bei Stage Manager oder beim Ziehen des Split-View-Reglers entstehen. Ein robuster Testansatz rendert dieselbe Komponente bei mehreren repräsentativen Breiten, mindestens an den Breakpoint-Grenzen selbst sowie knapp darüber und darunter, um Sprünge in der Darstellung frühzeitig zu erkennen, statt sie erst im manuellen QA-Durchlauf zu entdecken.

#!/usr/bin/env bash
# Create and launch Android tablet and foldable emulator profiles for testing
set -euo pipefail

# Foldable profile similar to the Galaxy Fold form factor
avdmanager create avd \
  --name "foldable_test" \
  --package "system-images;android-34;google_apis;x86_64" \
  --device "7.6in Foldable" \
  --force

# Classic 10-inch tablet profile, no hinge, tests breakpoints alone
avdmanager create avd \
  --name "tablet_10in_test" \
  --package "system-images;android-34;google_apis;x86_64" \
  --device "10.1in WXGA (Tablet)" \
  --force

# Launch the foldable emulator, starting in the unfolded state
emulator -avd foldable_test -feature WindowManager -no-snapshot &

# Toggle fold state at runtime via emulator console
adb emu fold
adb emu unfold

10. Zusammenfassung

Echter Tablet- und Foldable-Support in React Native entsteht nicht durch nachträgliches Hochskalieren eines Phone-Layouts, sondern durch bewusste Entscheidungen an mehreren Ebenen gleichzeitig: useWindowDimensions statt Dimensions.get für live reagierende Layouts, ein Breakpoint-System, das an tatsächlichen Bildschirmbreiten statt an Geräteklassen hängt, konsequentes Safe-Area-Handling über Multitasking-Übergänge hinweg und Master-Detail-Patterns, die Navigation und Content-Layout je nach verfügbarer Fläche umschalten.

Auf Android kommt mit der Hinge und den Jetpack-WindowManager-APIs eine zusätzliche Ebene hinzu, die nur über eine native Bridge zugänglich ist, aber für sauberen Foldable-Support unverzichtbar bleibt. Responsive Typografie und Spacing über ein Token-System statt fixer Werte, orientierungsunabhängiger Formular- und Scroll-State sowie eine Testing-Strategie, die Tablet-Simulatoren, Foldable-Emulatoren und Multitasking-Zwischengrößen einschließt, runden ein Setup ab, das responsive Layouts nicht nur auf dem Papier, sondern im tatsächlichen Nutzungsalltag zuverlässig macht.

11. FAQ: Tablet- und Foldable-Support in React Native