Впровадження Dynamic Type (масштабування шрифтів) у iOS

TRUETECH займається розробкою, підтримкою та обслуговуванням мобільних додатків iOS, Android, PWA. Маємо великий досвід та експертизу для публікації мобільних додатків до популярних маркетів Google Play, App Store, Amazon, AppGallery та інші.

Розробка та підтримка будь-яких видів мобільних додатків:

Інформаційні та розважальні мобільні програми
Новинки, ігри, довідники, онлайн-каталоги, погодні, фітнес та здоров'я, туристичні, освітні, соціальні мережі та месенджери, квіз, блоги та подкасти, форуми, агрегатори
Мобільні програми електронної комерції
Інтернет-магазини, B2B-додатки, маркетплейси, онлайн-обмінники, кешбек-сервіси, біржі, дропшиппінг-платформи, програми лояльності, доставка їжі та товарів, платіжні системи
Мобільні програми для управління бізнес-процесами
CRM-системи, ERP-системи, управління проектами, інструменти для команди продажів, облік фінансів, управління виробництвом, логістика та доставка, управління персоналом, системи моніторингу даних
Мобільні програми електронних послуг
Дошки оголошень, онлайн-школи, онлайн-кінотеатри, платформи надання електронних послуг, платформи кешбеку, відеохостинги, тематичні портали, платформи онлайн-бронювання та запису, платформи онлайн-торгівлі

Це лише деякі з типів мобільних додатків, з якими ми працюємо, і кожен із них може мати свої специфічні особливості та функціональність, а також бути адаптованим під конкретні потреби та цілі клієнта.

Послуги, які ми пропонуємо
Показано 1 з 1Усі 1734 послуг
Впровадження Dynamic Type (масштабування шрифтів) у iOS
Середній
~2-3 дні
Часті запитання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_mobile-applications_feedme_467_0.webp
    Розробка мобільного додатка для компанії FEEDME
    871
  • image_mobile-applications_xoomer_471_0.webp
    Розробка мобільного додатку для компанії XOOMER
    755
  • image_mobile-applications_rhl_428_0.webp
    Розробка мобільного додатку для компанії RHL
    1178
  • image_mobile-applications_zippy_411_0.webp
    Розробка мобільного додатку для компанії ZIPPY
    1051
  • image_mobile-applications_affhome_429_0.webp
    Розробка мобільного додатку для компанії Affhome
    978
  • image_mobile-applications_flavors_409_0.webp
    Розробка мобільного додатку для компанії FLAVORS
    574

Користувач із порушенням зору відкриває ваш додаток і через 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

Аспект UIKit SwiftUI
Системні шрифти UIFont.preferredFont(forTextStyle:) Font.body, Font.headline
Кастомні шрифти UIFontMetrics.scaledFont(for:) Font.custom(_:size:relativeTo:)
Масштабування контейнерів adjustsFontForContentSizeCategory Вбудовано за замовчуванням
Масштабування нешрифтових Вручну через contentSizeCategory @ScaledMetric
Адаптація layout traitCollectionDidChange @Environment(\.sizeCategory)

Типові проблеми та їх вирішення

Перелічимо часті граблі та як їх обійти. Якщо в 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. Документація: опис використаних підходів та політики масштабування.
Приклад з практикиОдин із наших клієнтів — фінтех-додаток із сотнями екранів. Після аудиту ми виявили, що 70% екранів використовують фіксовані шрифти. Ми переписали текстові стилі, додали `UIFontMetrics` для кастомних шрифтів і замінили фіксовані висоти на Auto Layout. Результат: додаток коректно відображається на всіх розмірах, включаючи AX5, а час тестування скоротився на 80% завдяки snapshot-тестам.

Терміни: від 2 до 5 днів залежно від складності. Вартість розраховується індивідуально на основі обсягу робіт. Зв'яжіться з нами для консультації та отримайте аудит доступності вашого додатка.

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

Доступність мобільних застосунків: VoiceOver, TalkBack та WCAG на практиці

Нам не раз доводилося бачити, як застосунок відхиляють в App Store через гайдлайн 1.1 або корпоративний клієнт вимагає WCAG 2.1 AA. Accessibility не закладений в архітектуру з самого початку — вбудовувати його в готовий продукт боляче. Ми знаємо, як це виправити, і маємо досвід 5+ років у цій сфері.

Чому не варто відкладати доступність?

Чому «додати доступність потім» не працює

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

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

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

Правильне налаштування скорочує час тестування втричі порівняно з постфактум-виправленнями. Ми гарантуємо відповідність WCAG 2.1 AA у вашому проекті.

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 для мобільних стали де-факто стандартом при корпоративних тендерах та держзакупівлях.

Які критерії 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

Порівняння підходів iOS та Android до критичних помилок

Типова помилка iOS (Swift) Android (Kotlin)
Неправильне групування shouldGroupAccessibilityChildren importantForAccessibility, accessibilityTraversalAfter
Відсутній фокус canBecomeFocused для елементів focusable="true" + nextFocusForward
Масштабування тексту UIFont.preferredFont + Dynamic Type systemFontSize, autoSizeStepGranularity
Озвучення статусу UIAccessibility.post(notification:announcement) announceForAccessibility() / sendAccessibilityEvent()

Як будуємо процес

Ми починаємо з аудиту: Accessibility Inspector в Xcode та TalkBack developer settings на Android — проходимо всі екрани з увімкненим Screen Reader і фіксуємо кожен випадок, коли потрібно більше 3 дій для виконання цільової операції. Далі — автоматизовані перевірки: XCUITest підтримує accessibility assertions; для Android використовуємо Accessibility Test Framework (ATF), вбудований в Espresso. Це ловить регресії на CI. Фінальний етап — тестування з реальними користувачами, які використовують допоміжні технології. Жодною автоматизацією це не замінити.

Інструмент Платформа Що перевіряє
Xcode Accessibility Inspector iOS/macOS Мітки, контраст, порядок фокусу
Android Accessibility Scanner Android Контраст, розміри touch targets
Deque axe DevTools Cross-platform WCAG-відповідність
VoiceOver (iOS) iOS Навігація через Screen Reader
TalkBack (Android) Android Навігація через Screen Reader

Що входить у роботу

Пропонуємо варіант «під ключ»: від аудиту до передачі документації. У результаті ви отримуєте:

  • Детальний звіт зі знайденими порушеннями та пріоритетами виправлень.
  • Виправлений код з коментарями (Swift, Kotlin, Flutter або React Native).
  • Документацію для команди щодо підтримки accessibility далі.
  • Навчання розробників (2–4 години воркшопу).
  • Гарантію на виправлення — 6 місяців безкоштовної підтримки регресій.

Ми впровадили accessibility у 20+ застосунках різного масштабу — від фінансових додатків до медичних систем. Оцінимо ваш проект безкоштовно. Зв'яжіться з нами, щоб отримати консультацію та приклад звіту з реального кейсу.