Dynamic Type und Textskalierung in Apps

Warum Textskalierung so wichtig ist

Sehkraft ist keine Ja-Nein-Frage. Sehr viele Menschen sehen ausreichend, um ein Smartphone zu nutzen, aber nur mit größerer Schrift. Mit dem Alter lässt die Naheinstellung des Auges nach (Alterssichtigkeit), dazu kommen Kurzsichtigkeit, Augenerkrankungen oder einfach das Lesen bei schlechtem Licht. Deshalb bieten iOS und Android seit Langem eine systemweite Einstellung für die Schriftgröße. Wer sie hochstellt, erwartet, dass jede App folgt.

Eine App, die feste Schriftgrößen erzwingt, ignoriert diese Einstellung und bleibt für viele Menschen schwer lesbar. Der gute Nachricht: Wenn du die Bordmittel der Plattform richtig verwendest, skaliert dein Text fast von selbst. Die Arbeit steckt weniger im Text als im Layout drumherum.

iOS: Dynamic Type

Dynamic Type ist Apples System für skalierbaren Text. Nutzer:innen wählen ihre bevorzugte Textgröße einmal zentral, unter Einstellungen → Bedienungshilfen → Anzeige & Textgröße → Größerer Text , und alle Apps, die Dynamic Type unterstützen, folgen dieser Wahl. Standardmäßig gibt es sieben Größen; aktiviert man die zusätzlichen Bedienungshilfen-Größen, kommen fünf weitere dazu, in Summe also zwölf. Die Voreinstellung heißt Large.

Der Schlüssel sind die Textstile(Text Styles): semantische Rollen wie body , headline , title oder caption . Du sagst dem System nicht „17 Punkt", sondern „das ist Fließtext", und iOS wählt die passende Größe für die aktuelle Nutzer:innen-Einstellung. Seit iOS 11 passen sich alle Textstile an alle zwölf Größen an. Verwendest du sie, bekommst du die volle Skalierung praktisch geschenkt.

 // SwiftUI: .body skaliert automatisch mit Dynamic Type 
Text("Heutige Termine")
    .font(.body) // UIKit: preferredFont(forTextStyle:) liefert die passende Größe 
label.font = .preferredFont(forTextStyle: .body)
label.adjustsFontForContentSizeCategory = true

Der Zusatz adjustsFontForContentSizeCategory in UIKit ist wichtig: Er sorgt dafür, dass das Label seine Größe auch dann aktualisiert, wenn Nutzer:innen die Einstellung ändern, während die App geöffnet ist. In SwiftUI passiert das automatisch.

Android: sp-Einheiten und nichtlineare Skalierung

Android trennt zwei Maßeinheiten sauber: dp (dichteunabhängige Pixel) für Layout-Maße und sp (skalierbare Pixel, scalable pixels ) für Schriftgrößen. Der Unterschied: sp berücksichtigt zusätzlich die von Nutzer:innen gewählte Schriftgröße. Die Regel ist einfach und folgenreich: Schriftgrößen immer in sp , niemals in dp oder festen Pixeln. Als Untergrenze für Fließtext empfiehlt Google mindestens 12 sp.

Seit Android 14 ist die Schriftskalierung nichtlinear: Sehr große Schriften wachsen langsamer als kleine, damit Überschriften bei maximaler Einstellung nicht ins Unermessliche springen und das Verhältnis zwischen Text und Layout lesbar bleibt. Eine praktische Folge: Das alte Feld scaledDensity ist dadurch nicht mehr verlässlich. Wer einen Skalierungsfaktor braucht, nutzt fontScale nur noch informativ und rechnet mit TypedValue.applyDimension() beziehungsweise deriveDimension() zwischen sp und Pixeln um; diese Methoden wenden die nichtlineare Kurve korrekt an.

 // XML-Layout: sp für die Schrift, sp auch für lineHeight 
<TextView
    android:textSize="16sp"
    android:lineHeight="24sp" /> // Jetpack Compose: fontSize in .sp 
Text(
    text = "Heutige Termine",
    fontSize = 16.sp
)

Eigene Schriften skalierbar machen

Markenschriften sind kein Hindernis. Beide Plattformen bieten einen Weg, beliebige Schriften wie den System-Fließtext mitskalieren zu lassen. Unter iOS übernimmt das die Klasse UIFontMetrics (seit iOS 11): Sie nimmt deine Schrift und wendet die Dynamic-Type-Kurve eines gewählten Textstils darauf an. Unter Android genügt es, die eigene Schrift in einer TextView oder einem Compose- Text mit einer Größe in sp zu verwenden, dann skaliert sie wie jede andere.

 // Eigene Schrift in 17 pt, skaliert wie der Textstil .body 
let custom = UIFont(name: "MeineSchrift-Regular", size: 17)!
label.font = UIFontMetrics(forTextStyle: .body).scaledFont(for: custom)
label.adjustsFontForContentSizeCategory = true

In SwiftUI lässt sich derselbe Effekt über @ScaledMetric auch auf andere Maße übertragen, etwa auf die Größe eines Icons oder einen Abstand, der zur Schrift passen soll. So bleibt das Verhältnis zwischen Text und umgebenden Elementen auch bei großer Schrift stimmig.

Layouts, die mitwachsen

Die eigentliche Arbeit liegt selten im Text, sondern im Layout. Wenn die Schrift wächst, braucht sie Platz. Feste Höhen, abgeschnittene Zeilen oder nebeneinander erzwungene Elemente sind die typischen Bruchstellen. Drei Grundregeln helfen fast immer:

• Keine festen Höhen für Textcontainer. Lass Knöpfe, Zellen und Karten in der Höhe mitwachsen, statt Text bei großer Schrift abzuschneiden.
• Zeilenumbruch zulassen. Begrenze Texte nicht hart auf eine Zeile, wenn der Inhalt länger werden kann. Ein Label, das auf eine Zeile gezwungen wird, verschwindet sonst hinter „…".
• Bei sehr großer Schrift umbrechen statt quetschen. Zwei nebeneinanderliegende Elemente dürfen bei großer Schrift untereinander rutschen. Auf iOS hilft dabei die Idee, ab den Accessibility-Größen auf ein vertikales Layout umzuschalten.

Der Bezug zu WCAG und EN 301 549

Textskalierung ist nicht nur Komfort, sondern eine Barrierefreiheits-Anforderung. In den Web Content Accessibility Guidelines (WCAG 2.2) verlangt das Erfolgskriterium 1.4.4 „Text vergrößern"(Stufe AA), dass sich Text bis 200 % vergrößern lässt, ohne dass Inhalt oder Funktion verloren gehen. Die WCAG sind für Webseiten geschrieben; für Apps überträgt das Dokument WCAG2ICT diese Kriterien sinngemäß, und der europäische Standard EN 301 549(Kapitel 11) macht sie über das Barrierefreiheitsstärkungsgesetz (BFSG) auch für mobile Anwendungen verbindlich.

Praktisch heißt das: 200 % sind die Untergrenze, die du erfüllen musst. Dynamic Type und die Android-Schriftskalierung gehen darüber hinaus, iOS erlaubt bei den größten Bedienungshilfen-Stufen eine Vergrößerung von deutlich über 300 %. Wer die Plattform-Mittel sauber nutzt, erfüllt 1.4.4 also nicht nur, sondern mit Reserve.

Testen auf beiden Plattformen

Textskalierung lässt sich in Minuten prüfen, und der Test deckt fast alle typischen Fehler auf. Du stellst die Systemschrift auf das Maximum und gehst deine wichtigsten Bildschirme durch.

Findest du Stellen, an denen Text abgeschnitten wird oder das Layout bricht, liegt es fast immer an einer festen Höhe oder einer harten Zeilenbegrenzung, nicht am Text selbst.

Zwei verbreitete Irrtümer

Wenn du tiefer einsteigen willst, sind die offiziellen Quellen von Apple und Google unten verlinkt. Und wie du Bedeutung und Rollen sauber an die Hilfstechnologien übergibst, zeigt der Artikel zur Semantik in SwiftUI und Jetpack Compose.