Разработка светлой темы (Light Mode) мобильного приложения
Недавно к нам пришёл клиент с проектом фитнес-трекера: приложение на SwiftUI, 50+ экранов, тёмная тема уже готова, а светлая — просто наследует цвета из дизайн-макетов без системы. Через месяц тестирования пользователи жаловались, что на ярком солнце текст нечитаем, а кнопки сливаются с фоном. Типичная ситуация: светлая тема — не просто инвертирование цветов, а продуманная цветовая система с семантическими токенами, контрастными отношениями и адаптацией под разные экраны. Мы взялись за проект и за 3 дня перестроили всю цветовую архитектуру — теперь приложение работает и на OLED, и на LCD, и в условиях разного освещения. За 7 лет мы реализовали light mode для 30+ проектов — от фитнес-трекеров до банковских приложений, и каждый раз семантические токены ускоряли редизайн в 5–10 раз по сравнению с прямыми HEX-значениями.
Почему семантические токены — база светлой темы?
Типичная ошибка в начале проекта — использовать конкретные HEX-значения напрямую в компонентах. Работает поначалу, но при первом же редизайне или добавлении тёмной темы превращается в nightmare: 200 мест с #F5F5F5, которые нужно найти и заменить. Прямое задание цветов — это технический долг, который резко увеличивает стоимость поддержки.
Правильный подход — семантические токены с момента старта. Имена токенов описывают назначение цвета, а не его внешний вид:
-
background.primary— основной фон экранов -
background.secondary— фон карточек, sidebar -
surface.default— поверхность компонентов -
text.primary,text.secondary,text.disabled -
accent.default,accent.pressed,accent.disabled -
border.default,border.focused
Токены хранятся в едином источнике правды — на iOS это UIColor named colors в Asset Catalog (Color Set с одним Light вариантом сейчас, Dark позже). В SwiftUI используем Color("backgroundPrimary") или кастомный extension Color. На Android — Material Design 3 ColorScheme через MaterialTheme. Flutter — ThemeData с полным ColorScheme. Экономия времени на поддержке при таком подходе достигает 70%.
| Подход | Гибкость | Время на редизайн | Риск ошибок |
|---|---|---|---|
| Прямые HEX-значения | Низкая | 2-3 недели | Высокий |
| Семантические токены | Высокая | 2-3 дня | Низкий |
Как правильно выстроить типографическую шкалу?
Типографическая шкала — часть light theme. Не просто «размер шрифта», а полная спецификация: font family, size, weight, line height, letter spacing для каждого текстового стиля. Минимальный набор включает Display / Large Title, Headline, Body, Body Small, Caption, Overline. Каждый стиль должен быть задан в едином объекте — например, Font.TextStyle в SwiftUI или Typography в Material Design.
На iOS шрифтовая шкала строится на UIFont.preferredFont(forTextStyle:) — это Dynamic Type, который автоматически масштабируется под пользовательские настройки доступности. Игнорировать Dynamic Type — значит сломать приложение для людей с нарушением зрения и получить потенциальный reject от Apple в соответствии с App Store Review Guidelines Section 4.2.
| Уровень контраста | Коэффициент | Рекомендация |
|---|---|---|
| AA (обычный текст) | 4.5:1 | Минимум для readability |
| AAA (обычный текст) | 7:1 | Оптимально для доступности |
Как обеспечить контраст на разных экранах?
Контраст — критический параметр для читабельности. WCAG AA требует 4.5:1 для текста до 18pt и 3:1 для крупного текста и UI-элементов. Для продуктов с широкой аудиторией мы стремимся к AAA (7:1) там, где это возможно без ущерба для дизайна. Проверяем контраст на каждом этапе — от макетов до финального билда.
Инструменты проверки: Figma плагин A11y - Color Contrast Checker, Xcode Accessibility Inspector, Android Accessibility Scanner. Проверяем не только основной текст, но и placeholder-текст в полях (часто грешит низким контрастом), disabled состояния, иконки и границы.
Тени и elevation: невидимая иерархия
В light mode тени — основной способ показать иерархию слоёв. Material Design 3 использует elevation + shadowColor. iOS UIKit — layer.shadowOffset, shadowRadius, shadowOpacity. Ошибка: одинаковая тень для всех компонентов. Правило: 3–4 уровня теней, от subtle (карточка в списке) до prominent (modal, bottom sheet). Наши инженеры подбирают параметры теней так, чтобы они выглядели естественно на любом экране и не вымывались при разном освещении.
Частые ошибки при реализации теней:
- Использование одной тени для всех элементов (плоская иерархия)
- Слишком высокая opacity (тень выглядит грязно)
- Игнорирование shadowColor на Android (по умолчанию чёрный — лучше задать оттенок)
Что входит в нашу работу
При заказе разработки светлой темы вы получаете:
- Дизайн-систему цветов — полный набор семантических токенов с документацией и примерами использования для iOS (SwiftUI/UIKit), Android (Jetpack Compose), Flutter.
- Типографическую шкалу со спецификациями для каждого стиля, включая Dynamic Type.
- Конфигурацию теней с 3–4 уровнями и рекомендациями по elevation.
- Проверку контрастности по WCAG AA/AAA с отчётом.
- Исходники в Asset Catalog / ThemeData — готовые к интеграции.
- Документацию по миграции и добавлению dark mode в будущем.
- Поддержку в течение двух недель после сдачи.
Сроки и как начать
Ориентировочный срок — от 1 до 3 дней в зависимости от объёма приложения и наличия готовой дизайн-системы. Стоимость рассчитывается индивидуально после анализа текущего кода и макетов. Мы гарантируем, что светлая тема пройдёт ревью Apple и Google Play без замечаний по доступности.
Свяжитесь с нами, чтобы оценить ваш проект. Получите консультацию по внедрению семантических токенов и контрастной цветовой схемы — это займёт не больше часа.