Реализация поддержки Dynamic Type (масштабирование шрифтов) в iOS

Пользователь с нарушением зрения открывает ваше приложение и через Onboarding не может прочитать текст — шрифт слишком мелкий. Он идёт в Настройки, включает Larger Text на максимум, возвращается — а текст всё тот же. Это не гипотеза: до 30% пользователей iOS увеличивают шрифт. Dynamic Type — системный механизм, позволяющий подстроить размер текста под предпочтения. Если его нет, вы теряете аудиторию и рискуете попасть под Section 4.2 App Store Review Guidelines.

Мы — мобильные разработчики с 10+ годами опыта в iOS (Swift 5.9+, SwiftUI, UIKit). За 5 лет мы внедрили Dynamic Type в 40+ проектах — от fintech до edtech. Получите консультацию и аудит доступности вашего приложения.

Почему Dynamic Type важен для доступности?

Согласно Apple Human Interface Guidelines, Dynamic Type — обязательный элемент доступности. Без него пользователи с нарушениями зрения не могут комфортно читать контент. Статистика: около 30% пользователей iOS настраивают размер шрифта больше стандартного. Игнорируя Dynamic Type, вы теряете аудиторию. Кроме того, это частая причина отказа в публикации в App Store.

Как правильно подключить Dynamic Type

UIKit

UIFont.preferredFont(forTextStyle: .body) — шрифт с поддержкой Dynamic Type из системной таблицы. Автоматически масштабируется при смене настройки. adjustsFontForContentSizeCategory = true на UILabel, UITextField, UITextView — включает реагирование на изменение в реальном времени (без рестарта приложения).

Для кастомных шрифтов: UIFontMetrics(forTextStyle: .body).scaledFont(for: customFont). UIFontMetrics масштабирует кастомный шрифт пропорционально системной таблице для выбранного TextStyle.

Частая ошибка: задать шрифт через UIFont(name: "CustomFont-Regular", size: 17) без UIFontMetrics — размер фиксированный, Dynamic Type не работает.

SwiftUI

Font.body, Font.headline, Font.caption — системные шрифты с Dynamic Type из коробки. Для кастомных: Font.custom("CustomFont-Regular", size: 17, relativeTo: .body) — параметр relativeTo включает масштабирование.

@ScaledMetric — для масштабирования нешрифтовых значений (отступы, иконки):

@ScaledMetric(relativeTo: .body) var iconSize: CGFloat = 24

При AX5 иконка вырастет до ~72pt. Это важно: иконки и отступы должны масштабироваться вместе с текстом, иначе layout разваливается.

Как избежать проблем с layout на крупных размерах?

Фиксированная высота строк и контейнеров

UILabel с numberOfLines = 1 и фиксированной высотой — текст обрезается. На AX5 заголовок из 20 символов занимает 3 строки. Решение: убрать фиксированные height constraints на текстовых элементах, использовать numberOfLines = 0 где возможно.

Горизонтальные стеки с текстом

UIStackView с axis = .horizontal и двумя UILabel — при крупном шрифте метки не помещаются рядом. Нужно либо переключать axis на .vertical при больших размерах через traitCollectionDidChange, либо изначально проектировать вертикальный layout.

В SwiftUI: ViewThatFits (iOS 16+) — выбирает layout в зависимости от доступного пространства. Для ранних версий — @Environment(\.sizeCategory) + условный HStack/VStack.

Таблицы и коллекции

UITableViewCell с Auto Layout и без фиксированной высоты — нормально. С tableView.rowHeight = 44 — при AX5 контент не влезет. tableView.rowHeight = UITableView.automaticDimension обязателен.

Кнопки с иконкой и текстом

На AX3+ текст может переноситься и кнопка меняет размер — это может нарушить layout соседних элементов.

Как тестировать Dynamic Type на всех размерах?

Xcode Simulator: меняем размер шрифта через Settings прямо в симуляторе. Или через Environment Overrides (Xcode Debug → Simulate Dynamic Type) — удобнее при разработке.

Обязательно проверяем accessibility размеры (AX1-AX5) — многие команды тестируют только стандартный диапазон и пропускают проблемы с экстремальными размерами.

Snapshot-тесты с фиксированными ContentSizeCategory: UITraitCollection(preferredContentSizeCategory: .accessibilityExtraExtraExtraLarge) — добавляем в CI, чтобы layout-регрессии ловились автоматически. Это сокращает время ручного тестирования на 80%.

Сравнение UIKit и SwiftUI для Dynamic Type

Типичные проблемы и их решения

Перечислим частые грабли и как их обойти. Если в UILabel текст обрезается — проверьте numberOfLines и снимите фиксированную высоту. Кастомный шрифт не масштабируется — скорее всего, вы забыли UIFontMetrics. Layout разваливается на AX5 — примените ViewThatFits или динамическую смену оси стека. Кнопки становятся слишком большими — установите adjustsFontForContentSizeCategory и используйте @ScaledMetric. Проблемы с таблицами — всегда используйте automaticDimension.

Что входит в нашу работу по внедрению Dynamic Type

1. Аудит текущего приложения: выявление мест с фиксированными шрифтами и layout.
2. Настройка текстовых стилей: переход на preferredFont и UIFontMetrics.
3. Адаптация constraints: замена фиксированных высот на автоматические.
4. Создание кастомных компонентов с поддержкой Dynamic Type.
5. Тестирование на всех размерах (xSmall–AX5) вручную и через snapshot-тесты.
6. Интеграция в CI/CD: добавление проверок на регрессии layout.
7. Документация: описание использованных подходов и политики масштабирования.

Сроки: от 2 до 5 дней в зависимости от сложности. Стоимость рассчитывается индивидуально на основе объёма работ. Свяжитесь с нами для консультации и получите аудит доступности вашего приложения.

Мы гарантируем, что после внедрения ваше приложение будет соответствовать требованиям App Store по accessibility, а пользователи с любым зрением смогут комфортно им пользоваться.

Доступность мобильных приложений: VoiceOver, TalkBack и WCAG на практике

Приложение отклонили в App Store по гайдлайну 1.1, или пришёл запрос от корпоративного клиента с требованием WCAG 2.1 AA — обе ситуации означают одно: accessibility не был заложен в архитектуру с самого начала, а теперь его нужно встраивать в готовый продукт. Это больно.

Почему «добавить доступность потом» не работает

Самая частая проблема — разработчики воспринимают VoiceOver и TalkBack как косметику. Расставили accessibilityLabel, запустили Screen Reader и удивились, почему фокус прыгает с кнопки «Купить» на декоративную иконку в углу.

На iOS ошибка живёт в неправильной группировке элементов. Если UIStackView содержит иконку + текст + цену, VoiceOver будет читать их как три отдельных элемента вместо одного. Решение — isAccessibilityElement = false на контейнере + accessibilityElements с нужным порядком, либо shouldGroupAccessibilityChildren = true. Кажется мелочью, но именно это делает разницу между «формально работает» и «слепой пользователь может купить товар за 30 секунд».

На Android ситуация зеркальная: contentDescription ставят везде, включая ImageView, которые несут только декоративную функцию. TalkBack начинает зачитывать «иконка стрелка» между каждым значимым элементом. Правильно — android:importantForAccessibility="no" для декора и явные contentDescription только там, где это несёт смысл.

Dynamic Type и масштабирование шрифтов

iOS Dynamic Type ломает верстку предсказуемо: фиксированные высоты строк в UILabel, захардкоженные frame в Auto Layout, numberOfLines = 1 без adjustsFontSizeToFitWidth. Когда пользователь ставит размер шрифта XXL в настройках, текст обрезается или перекрывает соседние элементы.

Правильная реализация использует .font = UIFont.preferredFont(forTextStyle: .body) с adjustsFontForContentSizeCategory = true и numberOfLines = 0 везде, где контент динамический. В SwiftUI это работает из коробки через .dynamicTypeSize() modifier.

На стороне Flutter эквивалент — textScaleFactor через MediaQuery. Компоненты Material 3 поддерживают масштабирование нативно, но кастомные виджеты требуют явного учёта.

WCAG 2.1 в мобильном контексте

Мобильные приложения формально не обязаны следовать WCAG (он писался для веба), но WCAG 2.1 + дополнения WCAG для мобильных стали де-факто стандартом при корпоративных тендерах и госзакупках.

Критичные критерии применительно к мобилу:

• 1.4.3 Contrast Minimum — соотношение контраста текста к фону минимум 4.5:1. Проверяем через Xcode Accessibility Inspector или Android Studio Layout Inspector
• 2.4.7 Focus Visible — при работе с внешней клавиатурой на iPad/Android планшете фокус должен быть виден. Часто забытый сценарий
• 2.5.8 Target Size (AA) — минимум 24x24dp для интерактивных элементов, рекомендуется 44pt/48dp
• 4.1.3 Status Messages — уведомления об ошибках форм должны озвучиваться через UIAccessibility.post(notification: .announcement) или AccessibilityNodeInfo.RoleDescription на Android

Как строим процесс

Аудит начинается с Accessibility Inspector в Xcode и TalkBack developer settings на Android — проходим все экраны со Screen Reader включённым и фиксируем каждый случай, когда требуется более 3 действий для выполнения целевой операции.

Дальше — автоматизированные проверки. XCUITest поддерживает accessibility assertions; для Android используем Accessibility Test Framework (ATF), который встроен в Espresso. Это ловит регрессии на CI.

Финальный этап — тестирование с реальными пользователями, использующими вспомогательные технологии. Никакой автоматизацией это не заменить.

Сроки

Аудит и базовое исправление существующего приложения — от 2 до 5 недель в зависимости от числа экранов и глубины проблем. Внедрение accessibility с нуля в новый проект практически не влияет на сроки при правильном дизайне компонентной системы — закладываем 10-15% overhead на разработку UI-слоя.