Айдентика мобильного приложения: иконка и UI-kit
Иконка приложения и логотип — два разных объекта дизайна
Логотип решает задачу узнавания бренда в любом контексте: на сайте, в рекламе, на упаковке. Иконка приложения решает узкую задачу — быть кликабельной точкой на домашнем экране среди десятков других иконок, часто размером с ноготь. Попытка засунуть в иконку полный логотип с текстом или сложной композицией — распространённая ошибка. При масштабировании до 40×40 пикселей детали превращаются в кашу, а буквы становятся нечитаемыми.
Рабочий подход — брать из логотипа только знак или его фрагмент, упрощать форму и адаптировать под квадрат или скруглённый квадрат. Apple и Google в своих гайдлайнах прямо рекомендуют избегать текста в иконке приложения, за исключением случаев, когда буква — это сам знак (как одна буква у известных сервисов). Иконка должна читаться силуэтом, а не деталями.
Требования App Store и Google Play: разница в подходе, а не только в пикселях
Технически разница между платформами не сводится к размеру файла. Apple требует единый статичный квадрат 1024×1024 px без прозрачности и скруглений — систему сама накладывает маску. Google, начиная с Android 8, устроен сложнее: помимо статичной иконки 512×512 px для витрины Play Store, разработчику нужно предоставить адаптивную иконку из двух слоёв.
| Параметр | App Store (iOS) | Google Play (Android) |
|---|---|---|
| Основной размер | 1024×1024 px, единый файл | 512×512 px для витрины + адаптивная иконка |
| Форма | Квадрат, маску накладывает система | Форма маски зависит от launcher-а (круг, квадрат, капля) |
| Слои | Один плоский слой | Foreground + background, отдельные PNG/Vector |
| Прозрачность | Не допускается | Допускается в foreground-слое |
| Тёмная тема | Поддерживается отдельным набором с iOS 18 (tinted/dark icon) | Themed icon через Material You, monochrome-слой |
Главный вывод из этой таблицы: дизайнить «одну иконку для всех» — путь к переделкам. Нужно сразу закладывать два продакшн-файла с разной логикой сборки.
Адаптивные иконки Android: что скрывается за словом «foreground»
Адаптивная иконка Android — это не один рисунок, а конструктор из двух слоёв размером 108×108 dp каждый. Фоновый слой обычно однотонный или с лёгким градиентом, передний несёт сам знак. Проблема в том, что система обрезает эти слои разными масками в зависимости от производителя устройства и лончера — где-то это круг, где-то капля, где-то квадрат со скруглением.
Гарантированно видимая зона — только центральные 66×66 dp. Оставшиеся 18 dp с каждой стороны зарезервированы под безопасный отступ и параллакс-эффект при повороте телефона. Если знак упирается в края этой зоны, при агрессивной маске (например, круглой) он будет обрезан. Практический вывод: знак нужно рисовать с запасом внутри безопасной зоны, а не растягивать на весь холст 108×108 — это типичная ошибка, из-за которой иконки после публикации выглядят обрезанными на части устройств.
Светлая и тёмная тема — не косметика, а отдельный контур дизайна
Тёмный режим давно перестал быть опциональной фичей, и иконки с UI-компонентами, которые не адаптированы под него, выглядят как забытый долг. Здесь работают два разных требования — к самой app-иконке и к элементам интерфейса внутри приложения.
- Для иконки приложения — избегать тонких линий и мелких деталей, которые тают на тёмном фоне лончера; использовать плотные, контрастные формы.
- Для UI-элементов — обеспечивать контрастность минимум 3:1 по WCAG AA/AAA, если иконка используется отдельно, без подписи текстом.
- Не инвертировать цвета механически — тёмная тема требует отдельной калибровки насыщенности, иначе яркие акцентные цвета «кричат» на тёмном фоне.
- Проверять компоненты на реальных устройствах с OLED-экранами, где чёрный — это отсутствие подсветки, а не просто тёмно-серый.
Здесь и рождается идея дизайн-токенов: вместо того чтобы вручную красить каждую кнопку под тёмную тему, задаются семантические переменные — «цвет фона поверхности», «цвет текста на акценте» — и их значения меняются автоматически при переключении темы. Разработчик берёт токен, а не хардкодит hex-код, и вся система переключается синхронно.
Из чего состоит полноценный UI-kit — сравнение минимального и системного набора
Часто UI-kit путают с набором кнопок и палитрой из пяти цветов. На практике полноценная система для мобильного приложения устроена иначе, и разница между «стартовым набором» и зрелой дизайн-системой ощущается уже через два-три релиза.
| Компонент | Минимальный набор | Системный UI-kit |
|---|---|---|
| Цвет | Плоская палитра (5-8 цветов) | Семантические токены (surface, accent, error) с версиями для тёмной темы |
| Типографика | 2-3 стиля текста | Полная сетка стилей с line-height, letter-spacing, адаптацией под платформу |
| Иконки | Один стиль, разные размеры S/M/L/XL | 2 фиксированных размера, 2px толщина линии, 3-5 стилевых вариантов |
| Компоненты | Кнопки, поля ввода | + карточки, модалки, табы, состояния loading/error/empty, анимации переходов |
| Сетка и отступы | Произвольные значения | Единая шкала отступов (4/8/12/16...), grid-система под разные экраны |
| Документация | Файл в Figma | Библиотека компонентов, синхронизированная с кодовой базой (design tokens в JSON) |
Опыт Альфа-банка показывает, что сокращение количества размеров иконок до двух и фиксация толщины линии на 2px не обедняет систему, а наоборот — снимает лишние решения с дизайнеров и делает интерфейс визуально однороднее. Чем меньше произвольных параметров в системе, тем меньше расхождений между экранами одного приложения.
Айдентика приложения как система, а не набор файлов
Ошибка многих команд — делать иконку приложения отдельно от UI-kit, будто это два разных проекта. На деле иконка — это точка входа в систему, которая должна использовать ту же палитру, ту же логику форм и ту же толщину линий, что и компоненты внутри приложения. Если иконка на домашнем экране скруглённая и мягкая, а кнопки внутри острые и геометричные — бренд ощущается расколотым, даже если пользователь не может объяснить, что именно не так.
Системный подход означает, что палитра, типографика, сетка отступов и стилистика иконок описаны как единые токены, а не как отдельные решения для каждого экрана. По данным кейса компании «Звук», внедрение такой дизайн-системы сократило время на разработку макетов на 30-50%, а сборку готовых экранов — в 3-4 раза. Это не абстрактная экономия: команда перестаёт каждый раз придумывать, какой оттенок серого использовать для disabled-кнопки, потому что ответ уже зафиксирован в токене.
Управление версиями здесь работает так же, как в разработке кода: изменения в базовых токенах — цвете, размере, радиусе скругления — автоматически подтягиваются во все компоненты и экраны, где они используются. Кросс-платформенная совместимость достигается не копированием пикселей между iOS и Android, а синхронизацией на уровне логики: одна и та же семантика цвета и формы, разная техническая реализация под требования каждой платформы. Именно так иконка перестаёт быть «картинкой для магазина приложений» и становится частью цельного бренд-опыта.
Иконка приложения и логотип — два разных объекта дизайна
Логотип решает задачу узнавания бренда в любом контексте: на сайте, в рекламе, на упаковке. Иконка приложения решает узкую задачу — быть кликабельной точкой на домашнем экране среди десятков других иконок, часто размером с ноготь. Попытка засунуть в иконку полный логотип с текстом или сложной композицией — распространённая ошибка. При масштабировании до 40×40 пикселей детали превращаются в кашу, а буквы становятся нечитаемыми.
Рабочий подход — брать из логотипа только знак или его фрагмент, упрощать форму и адаптировать под квадрат или скруглённый квадрат. Apple и Google в своих гайдлайнах прямо рекомендуют избегать текста в иконке приложения, за исключением случаев, когда буква — это сам знак (как одна буква у известных сервисов). Иконка должна читаться силуэтом, а не деталями.
Требования App Store и Google Play: разница в подходе, а не только в пикселях
Технически разница между платформами не сводится к размеру файла. Apple требует единый статичный квадрат 1024×1024 px без прозрачности и скруглений — систему сама накладывает маску. Google, начиная с Android 8, устроен сложнее: помимо статичной иконки 512×512 px для витрины Play Store, разработчику нужно предоставить адаптивную иконку из двух слоёв.
| Параметр | App Store (iOS) | Google Play (Android) |
|---|---|---|
| Основной размер | 1024×1024 px, единый файл | 512×512 px для витрины + адаптивная иконка |
| Форма | Квадрат, маску накладывает система | Форма маски зависит от launcher-а (круг, квадрат, капля) |
| Слои | Один плоский слой | Foreground + background, отдельные PNG/Vector |
| Прозрачность | Не допускается | Допускается в foreground-слое |
| Тёмная тема | Поддерживается отдельным набором с iOS 18 (tinted/dark icon) | Themed icon через Material You, monochrome-слой |
Главный вывод из этой таблицы: дизайнить «одну иконку для всех» — путь к переделкам. Нужно сразу закладывать два продакшн-файла с разной логикой сборки.
Адаптивные иконки Android: что скрывается за словом «foreground»
Адаптивная иконка Android — это не один рисунок, а конструктор из двух слоёв размером 108×108 dp каждый. Фоновый слой обычно однотонный или с лёгким градиентом, передний несёт сам знак. Проблема в том, что система обрезает эти слои разными масками в зависимости от производителя устройства и лончера — где-то это круг, где-то капля, где-то квадрат со скруглением.
Гарантированно видимая зона — только центральные 66×66 dp. Оставшиеся 18 dp с каждой стороны зарезервированы под безопасный отступ и параллакс-эффект при повороте телефона. Если знак упирается в края этой зоны, при агрессивной маске (например, круглой) он будет обрезан. Практический вывод: знак нужно рисовать с запасом внутри безопасной зоны, а не растягивать на весь холст 108×108 — это типичная ошибка, из-за которой иконки после публикации выглядят обрезанными на части устройств.
Светлая и тёмная тема — не косметика, а отдельный контур дизайна
Тёмный режим давно перестал быть опциональной фичей, и иконки с UI-компонентами, которые не адаптированы под него, выглядят как забытый долг. Здесь работают два разных требования — к самой app-иконке и к элементам интерфейса внутри приложения.
- Для иконки приложения — избегать тонких линий и мелких деталей, которые тают на тёмном фоне лончера; использовать плотные, контрастные формы.
- Для UI-элементов — обеспечивать контрастность минимум 3:1 по WCAG AA/AAA, если иконка используется отдельно, без подписи текстом.
- Не инвертировать цвета механически — тёмная тема требует отдельной калибровки насыщенности, иначе яркие акцентные цвета «кричат» на тёмном фоне.
- Проверять компоненты на реальных устройствах с OLED-экранами, где чёрный — это отсутствие подсветки, а не просто тёмно-серый.
Здесь и рождается идея дизайн-токенов: вместо того чтобы вручную красить каждую кнопку под тёмную тему, задаются семантические переменные — «цвет фона поверхности», «цвет текста на акценте» — и их значения меняются автоматически при переключении темы. Разработчик берёт токен, а не хардкодит hex-код, и вся система переключается синхронно.
Из чего состоит полноценный UI-kit — сравнение минимального и системного набора
Часто UI-kit путают с набором кнопок и палитрой из пяти цветов. На практике полноценная система для мобильного приложения устроена иначе, и разница между «стартовым набором» и зрелой дизайн-системой ощущается уже через два-три релиза.
| Компонент | Минимальный набор | Системный UI-kit |
|---|---|---|
| Цвет | Плоская палитра (5-8 цветов) | Семантические токены (surface, accent, error) с версиями для тёмной темы |
| Типографика | 2-3 стиля текста | Полная сетка стилей с line-height, letter-spacing, адаптацией под платформу |
| Иконки | Один стиль, разные размеры S/M/L/XL | 2 фиксированных размера, 2px толщина линии, 3-5 стилевых вариантов |
| Компоненты | Кнопки, поля ввода | + карточки, модалки, табы, состояния loading/error/empty, анимации переходов |
| Сетка и отступы | Произвольные значения | Единая шкала отступов (4/8/12/16...), grid-система под разные экраны |
| Документация | Файл в Figma | Библиотека компонентов, синхронизированная с кодовой базой (design tokens в JSON) |
Опыт Альфа-банка показывает, что сокращение количества размеров иконок до двух и фиксация толщины линии на 2px не обедняет систему, а наоборот — снимает лишние решения с дизайнеров и делает интерфейс визуально однороднее. Чем меньше произвольных параметров в системе, тем меньше расхождений между экранами одного приложения.
Айдентика приложения как система, а не набор файлов
Ошибка многих команд — делать иконку приложения отдельно от UI-kit, будто это два разных проекта. На деле иконка — это точка входа в систему, которая должна использовать ту же палитру, ту же логику форм и ту же толщину линий, что и компоненты внутри приложения. Если иконка на домашнем экране скруглённая и мягкая, а кнопки внутри острые и геометричные — бренд ощущается расколотым, даже если пользователь не может объяснить, что именно не так.
Системный подход означает, что палитра, типографика, сетка отступов и стилистика иконок описаны как единые токены, а не как отдельные решения для каждого экрана. По данным кейса компании «Звук», внедрение такой дизайн-системы сократило время на разработку макетов на 30-50%, а сборку готовых экранов — в 3-4 раза. Это не абстрактная экономия: команда перестаёт каждый раз придумывать, какой оттенок серого использовать для disabled-кнопки, потому что ответ уже зафиксирован в токене.
Управление версиями здесь работает так же, как в разработке кода: изменения в базовых токенах — цвете, размере, радиусе скругления — автоматически подтягиваются во все компоненты и экраны, где они используются. Кросс-платформенная совместимость достигается не копированием пикселей между iOS и Android, а синхронизацией на уровне логики: одна и та же семантика цвета и формы, разная техническая реализация под требования каждой платформы. Именно так иконка перестаёт быть «картинкой для магазина приложений» и становится частью цельного бренд-опыта.
Актуальные статьи
МегаФон, BMW, ВТБ и ещё 240+ компаний. Смотрите как это выглядит в шоуриле:
В наше брендинговое агентство обращаются, чтобы заказать:
