Jedes Layout in Ihrer App trägt eine Annahme, die niemand aufgeschrieben hat: dass der Bildschirm ein Rechteck ist, dass er seine Form behält, solange die App offen ist, und dass der Nutzer sie einhändig etwa dreissig Zentimeter vor dem Gesicht hält.
Drei davon sind jetzt optional.
Die Annahme, die wirklich bricht
Es ist verlockend, das unter Responsive Design abzulegen und weiterzugehen. Entwickler bedienen seit fünfzehn Jahren mehrere Bildschirmgrössen — das sind halt ein paar Grössen mehr.
Diese Rahmung übersieht, was anders ist. Responsive Design nimmt an, dass der Viewport beim Start feststeht. Man prüft die Breite einmal, wählt ein Layout, rendert. Foldables brechen das: Der Bildschirm ändert seine Form, während Ihre App läuft — mitten in der Aufgabe, manchmal mitten im Tastendruck. Eine App, die ihre Masse beim Start liest und eine Layout-Entscheidung cached, tut beim ersten Aufklappen sichtbar das Falsche.
Die zweite gebrochene Annahme: dass der ganze Bildschirm nutzbar ist. Ein gefaltetes Gerät hat ein Scharnier mittendurch. Inhalt unter dieser Falte ist nicht bloss hässlich — er ist unlesbar, und ein Button dort ist unzuverlässig.
Foldables: ein Gerät, zwei Geräte
Das nützliche Denkmodell: Ein Foldable ist zwei Geräte, die sich einen Prozess teilen — und Ihre App muss beide sein.
Gefaltet ist es ein schmales Telefon — oft schmaler als ein Standard-Handy, was Teams überrascht, deren Mindestbreiten-Annahmen ein iPhone gesetzt hat. Aufgeklappt ist es ein kleines Tablet mit quadratischerem Seitenverhältnis als jedes Tablet, auf dem Sie getestet haben.
Der Übergang dazwischen ist, wo das Engineering wohnt. Klappt jemand mitten in der Aufgabe auf, müssen drei Dinge überleben: die Scroll-Position, der Eingabezustand und der Fokus. Eine halb getippte Nachricht zu verlieren, weil der Nutzer das Gerät geöffnet hat, ist die Art Bug, für die Apps gelöscht werden — und es ist das Standardverhalten, wenn Sie das OS Ihre Activity unbehandelt neu erzeugen lassen.
Es gibt auch einen Mittelzustand. Geräte, die halb offen stehen bleiben — aufs Pult gestellt, Kamera oben, Inhalt unten — ermöglichen genuin nützliche Modi für Videocalls und Fotografie. Ihn zu unterstützen ist optional. Zu wissen, dass es ihn gibt, damit Ihr Layout nicht in etwas Absurdes kollabiert, ist es nicht.
Abb. — Eine App, drei Haltungen. Die Übergänge sind der harte Teil, nicht die Layouts.
Wearables haben ein völlig anderes Budget
Eine Uhr ist kein kleines Telefon — und sie als eines zu behandeln produziert die Apps, die niemand zweimal öffnet.
Die Beschränkung ist nicht die Bildschirmgrösse. Es ist das Interaktionsbudget — die gesamte Aufmerksamkeit, die ein Nutzer aufwendet, bevor er die Aufgabe abbricht. Auf einem Telefon sind das Minuten. Auf einer Uhr ist es ungefähr die Zeitspanne, die jemand den Arm oben hält — ein paar Sekunden.
Diese eine Tatsache sollte bestimmen, was Sie bauen. Eine Uhr-App, die Scrollen durch eine Liste, Auswählen und Bestätigen verlangt, hat das Budget bereits überzogen. Eine, die das eine relevanteste Ding zeigt, mit höchstens einer Aktion, passt hinein.
Die ehrliche Antwort für die meisten Produkte: Die Uhr-Fläche ist eine Benachrichtigung und ein Blick — keine App. Die Lieferverfolgung, die Bordkarte, die eine Zahl, die zählt. Eine volle Navigationshierarchie für eine Uhr zu bauen ist ein verbreiteter und teurer Fehler — der Aufwand fliesst hinein, die Nutzung kommt nie, und das Team schliesst, Wearables seien egal, obwohl es eine Telefon-App auf kleinem Bildschirm gebaut hat.
Spatial: interessant — und noch nicht Ihr Problem
Headsets ziehen gemessen an ihrer installierten Basis einen unverhältnismässigen Anteil der Strategiegespräche an, und beim Zeithorizont lohnt sich Klartext.
Für die überwältigende Mehrheit der Apps lautet die richtige Spatial-Strategie dieses Jahr: sicherstellen, dass die bestehende App in einem Kompatibilitätsfenster akzeptabel läuft — und das Engineering woanders ausgeben. Die Gerätezahl rechtfertigt für eine Allzweck-App noch keinen eigenen Build.
Die Ausnahmen sind real, aber schmal: Training und Simulation, komplexe 3D-Daten, Fernunterstützung, bei der es das Ergebnis wirklich ändert, die Hände des anderen zu sehen. Sitzt Ihr Produkt in einem dieser Felder, rechnet sich die Sache anders und verdient ernsthafte Investition. Wenn nicht, ist eine Store-Präsenz auf einer Plattform mit wenigen Nutzern ein Eitelkeitsprojekt mit Wartungskosten.
Das Testproblem
Hier ist das praktische Hindernis, an dem die meisten Teams scheitern — und es ist weder Design noch Code.
Ein Foldable lässt sich ohne Foldable nicht richtig testen. Emulatoren beherrschen die Geometrie — sie zeigen ein gefaltetes und ein aufgeklapptes Layout und feuern den Konfigurationswechsel. Was sie nicht reproduzieren: wie sich das Scharnier unter einem Daumen anfühlt, ob die Falte über Ihrer Hauptaktion sitzt, oder wie der Übergang auf echter Hardware in voller Geschwindigkeit aussieht.
Für Uhren gilt dasselbe, schärfer. Ein Zifferblatt in 400% Zoom auf einem Desktop-Monitor sagt nichts über Lesbarkeit am Handgelenk, im Tageslicht, beim Gehen.
Budgetieren Sie mindestens ein physisches Gerät pro Formfaktor, den Sie zu unterstützen behaupten. Das sind bescheidene Hardwarekosten gegen die Alternative: Ihr Layoutproblem aus einer Ein-Stern-Bewertung zu erfahren, die es schlecht beschreibt.
Automatisiertes Testen hilft beim mechanischen Teil. Ein Test, der durch jede Fenstergrössen-Klasse rotiert und prüft, dass nichts überläuft, kein interaktives Element unter dem Scharnier landet und der Zustand einen Konfigurationswechsel überlebt, fängt die meisten Regressionen billig. Einmal aufgesetzt, schützt er Sie auf jedem Gerät, das später erscheint.
Was sich in Ihrem Code wirklich ändert
Hören Sie auf, den Gerätetyp zu lesen, und lesen Sie die Fenstergrösse — kontinuierlich. Beide grossen Plattformen bieten inzwischen Grössenklassen, die das aktuelle Fenster beschreiben statt die Hardware, und beide feuern Updates bei Änderung. Code, der auf «ist das ein Tablet» verzweigt, ist auf einem Foldable bereits falsch.
Machen Sie das Überleben von Zustand explizit. Nehmen Sie an, Ihre UI kann jederzeit zerstört und neu erzeugt werden — und alles nicht bewusst Gespeicherte ist verloren. Auf Android ist das ausgetretenes Terrain; für viel iOS-Code ist es neu relevant.
Bauen Sie für einen Bereich, nicht für Breakpoints. Layouts, die an drei konkreten Breiten hängen, brechen am vierten Gerät — und es gibt immer ein viertes Gerät. Kontinuierliche Anpassung — Inhalt, der umfliesst, statt zwischen festen Designs zu springen — kostet vorne mehr und danach nichts mehr.
Und behandeln Sie das Scharnier, das die Plattform-APIs für Sie beschreiben: wo es ist, in welche Richtung es läuft, ob das Gerät gefaltet ist. Es zu ignorieren setzt einen Button in eine Falte.
Noch etwas, das Teams erwischt: Mit den Bildschirmen vervielfachen sich die Eingabemethoden. Ein aufgeklapptes Gerät ist gross genug, dass Leute Tastaturen anschliessen. Eine Uhr nimmt Sprache und eine Krone. Ein tabletgrosses Foldable wird mit Stift benutzt. Code, der Touch als einzige Eingabe annimmt, fühlt sich auf allen subtil kaputt an — keine Tastaturkürzel, kein Fokusring, keine sinnvolle Tab-Reihenfolge.
Diese Arbeit ist überwiegend Barrierefreiheits-Arbeit mit anderem Hut. Eine App mit sauberer Fokusreihenfolge und echter Tastaturunterstützung erledigt das meiste davon bereits — ein weiterer Grund, warum sich die Accessibility-Investition an Stellen auszahlt, die niemand vorhergesagt hat.
Wie Sie das priorisieren
Prüfen Sie Ihre Analytics, bevor Sie irgendetwas entscheiden. Der Foldable-Anteil variiert enorm nach Markt — bedeutsam in Teilen Asiens, vernachlässigbar anderswo — und die richtige Investition hängt an Ihren Nutzern, nicht am allgemeinen Trend.
Finden Sie echte Foldable-Nutzung, lohnt sich die Arbeit sauber, und sie ist nicht riesig: kontinuierliche Layouts, Zustandserhalt, Scharnier-Bewusstsein. Das meiste davon verbessert nebenbei Ihre Tablet-Erfahrung — und das ist der Teil, der den Business Case trägt.
Finden Sie Uhr-Nutzer, bauen Sie den Blick, nicht die App.
Es gibt einen kommerziellen Winkel, den Sie mit der Budgetverantwortung besprechen sollten. Foldable-Besitzer sitzen in jedem Markt, in dem es sie gibt, am Premium-Ende — das sind teure, bewusst gekaufte Geräte. Monetarisiert Ihr Produkt, ist dieses Segment überproportional wertvoll relativ zu seinem Installationsanteil — und eine App, die sich beim Aufklappen schlecht benimmt, versagt vor genau den Nutzern, die Sie am liebsten behalten würden.
Dasselbe Argument läuft für Uhren andersherum. Uhr-Nutzer sind engagiert, aber die Fläche erzeugt fast keinen direkten Umsatz — der Investitionsfall ruht also auf Retention und Gewohnheit statt auf Conversion. Ehrlich zu sein, welches von beiden Sie kaufen, verhindert das übliche Ergebnis: Ein Team liefert eine Uhr-App, sieht keine Umsatzbewegung und gibt sie still auf.
Und finden Sie keins von beidem, ist der nützliche Zug, keinen Code mehr zu schreiben, der das später schwer macht. Eine App auf Fenstergrössen-Anpassung und diszipliniertem Zustandsmanagement trägt jede Form, die als Nächstes erscheint, ohne Neubau. Eine App auf drei hartkodierten Breakpoints und gecachten Layout-Entscheidungen braucht einen — jedes Mal.
