Создание иконок мобильного приложения под iOS и Android

Разнобой в иконках мобильного приложения: где ломается интерфейс

Иконки мобильного приложения редко попадают в план релиза отдельной задачей — их готовят в последнюю неделю, между сборкой и отправкой на проверку. Дизайнер отдаёт значки одним набором, разработчик подставляет их как есть, и в приложении появляется разнобой графики: часть значков обрезана по краям, часть рассчитана на светлую тему и пропадает на тёмной, часть вытянута под пропорции чужой платформы.

Дальше подключается расхождение интерфейса между платформами. Один и тот же значок на iOS и Android отрисовывается по разным маскам: на одной системе он вписан в круг, на другой — в квадрат со скруглением. Если набор готовили под одну платформу и просто перенесли во вторую, половина значков теряет поля по краям, а мелкие детали сливаются в пятно на реальном экране.

Цена такого расхождения — возврат сборки из проверки. Правила оформления в Apple Human Interface Guidelines и в Material Design описывают поля, сетку и поведение значка в тёмной теме; если набор им не соответствует, сборку возвращают, а исправление упирается в новую сборку и повторную очередь на модерацию. При релизе в обе системы цикл проходится дважды.

Отдельная боль — правки иконок после релиза. Заменить один значок в магазине нельзя: он зашит в сборку, поэтому исправление ждёт следующего релиза и снова проходит полный цикл проверки. Ошибку в графике, которая видна на первом экране, приходится терпеть неделями.

Разбираем, как это закрывается: как из одного исходника собираются корректные наборы под обе платформы, светлую и тёмную темы, и почему тогда правки перестают быть аварийными.

Что даёт единый набор графики: скорость сборки и меньше правок

Единый источник графики вместо ручного сведения версий

Иконки живут как библиотека компонентов в Figma: один мастер на глиф, векторная отрисовка, выравнивание по пиксельной сетке. Экран собирается из ссылок на мастер, а не из копий файлов, поэтому правка иконки расходится по всем макетам сразу — ручное сведение версий между экранами и платформами уходит из процесса.

Единый источник графики экономит время не в момент отрисовки, а на каждом следующем экране: новый макет собирается из готовых символов, а не рисуется заново. Доля мкетов, которые возвращаются на доработку из-за расхождений между экранами, падает — правки становятся точечными, а не каскадными.

Общая система символов снимает целый класс ошибок

Плотности экрана и размеры иконок экспортируются из одного мастера, поэтому не появляется «поехавших» толщин обводки и разной оптической массы между платформами. Состояния — активное, неактивное, нажатое — описаны вариантами компонента, а не отдельными наборами файлов: разработчик не собирает иконку по частям и не угадывает отступы при вёрстке.

Скорость вывода экранов растёт за счёт предсказуемых размеров и точек привязки, на которые опирается вёрстка. Консистентность графики перестаёт зависеть от того, кто именно рисовал конкретный экран, — новый человек в команде подключается к готовой системе, а не восстанавливает её по разрозненным файлам.

Варианты поставки набора: отдельные комплекты или единый источник

Набор иконок можно поставлять по-разному, и от выбора зависит, как правки доходят до релиза. Раздельные комплекты под iOS и Android живут независимо, единый источник собирается в форматы обеих платформ из одних исходников, а между ними есть гибридный путь с ручной доводкой.

Раздельные комплекты под iOS и Android

Каждая платформа получает собственный набор растровых и векторных файлов, мастер-файл лежит рядом. Так поступают, когда требования платформ расходятся по форме знака и общий рисунок пришлось бы всё равно рассинхронизировать. Ограничение предсказуемое: правку повторяют в каждом комплекте, расхождения копятся и всплывают на проверке перед публикацией.

Единый источник и сборка под платформы

Векторные исходники хранятся одним набором, из которого сборка раскладывает размеры, плотности и форматы под каждую платформу. Правка в источнике расходится по всему набору сразу, история изменений остаётся в системе контроля версий. Платформенная адаптация графики здесь делается параметрами сборки, а не руками — это и есть основное ограничение варианта.

Гибридный путь с ручной доводкой

Общий источник отвечает за базовую форму и цвет, а отдельные знаки дорабатываются под платформу вручную и сохраняются как переопределения. Подходит, когда большая часть набора общая, но несколько иконок требуют индивидуальной оптики.

Как мы собираем и внедряем иконки: этапы работы

Набор иконок ломается не на этапе рисования, а на внедрении: файлы приходят с разными именами, часть форматов не подхватывается сборкой, а на реальном экране иконка проваливается по контрасту в тёмной теме. Мы ведём эту работу как инженерный процесс с фиксированными точками контроля — от инвентаризации графики до приёмки набора.

Как устроены этапы внедрения набора иконок

1. Инвентаризация графики. Разбираем текущие каталоги ресурсов и материалы в магазинах приложений: находим дубли, устаревшие версии и графику, нарисованную под конкретный экран. На выходе — реестр иконок с указанием, где каждая применяется.
2. Схема именования файлов. До сборки фиксируем структуру каталогов и правила именования: имя отражает назначение, размер и тему, а не автора. Это убирает ручное переименование при следующем релизе.
3. Сборка комплектов. Готовим векторные исходники и производные растровые наборы под нужные режимы отображения, отдельно — варианты для тёмной темы, выделенного состояния и витрин магазинов.
4. Проверка на реальных экранах. Прогоняем набор на живых устройствах и в эмуляторах: смотрим читаемость на малой и большой диагонали, поведение в тёмной теме, выравнивание по сетке.
5. Приёмка набора. Сверяем результат с реестром: всё на месте, имена совпадают, лишних файлов нет. Расхождения закрываем до передачи.
6. Передача и обучение. Отдаём исходники, каталог ресурсов, реестр и правила именования, показываем команде заказчика, как добавить новую иконку, не нарушив структуру.

Что остаётся на стороне заказчика

Комплект подключается к проекту без ручной правки имён, а реестр и правила именования дальше работают как внутренний стандарт. Новая иконка добавляется за один шаг — без разбора чужих слоёв и пересборки всего набора.

Что передаём на руки: исходники, правила оформления и регламент

Собрать иконку — половина работы. Вторая половина в том, чтобы через полгода новый раздел в приложении не потребовал перерисовывать весь набор, а сборка под каждую платформу не зависела от чьей-то памяти о нужных размерах. Поэтому набор передаём не картинками на выходе, а рабочим комплектом: исходники, правила и регламент, по которому его можно расширять без нас.

Что входит в комплект

• Рабочие исходники — векторные файлы с разложенными слоями, отдельными символами и мастер-страницами: правка одной фигуры расходится по всему набору, а не по десяти копиям.
• Собранные комплекты под платформы — готовые наборы в нужных форматах и размерах, с корректной прозрачностью и без ручной доводки на стороне разработки.
• Правила оформления графики — сетка и отступы, толщины линий, радиусы, поведение мелких деталей на минимальных размерах.
• Правила именования — единая схема имён файлов и символов, чтобы элемент находился поиском, а не перебором папок.
• Документация по набору — короткий справочник: где лежит, как собрать, что делать при расхождении версий.

Правила и порядок работы

• Описание прав доступа к хранилищу графики — владелец, редакторы, читатели и порядок выдачи прав новому человеку.
• Регламент обновления набора — как добавляется новый символ, кто утверждает, в какие сроки и как фиксируется версия.

Такой комплект закрывает типовой сценарий: набор живёт и расширяется внутри вашей команды, а мы остаёмся на подхвате — например, когда символов становится столько, что нужен редизайн всей системы.

Кейс: единый источник графики убрал расхождения между платформами

Ситуация до

Заказчик приносил графику выгрузкой из макетов: каждый символ в трёх размерах, часть — растром, часть — контуром, толщина обводки и скругления выставлялись вручную отдельно под каждую платформу. Новый символ рисовался дважды, файлы подключались по именам, и к концу цикла выпуска накапливалось 8-12 правок — расходились сетка, оптический размер и цвет активного состояния.

Что изменили и что получилось

Мы собрали мастер-набор в Figma как единый источник: сетка, ключевые линии, толщина обводки и размеры вынесены в переменные, экспорт в векторные форматы идёт одной командой. Иконка стала компонентом с вариантами состояний, поэтому новый символ собирается из готовых частей, а не рисуется заново.

Доля расхождений между платформами упала с трети набора до нуля — несовпадения ловит автоматическая проверка при сборке, а не заказчик на приёмке. Время на добавление нового символа сократилось с нескольких часов до 20-30 минут вместе с экспортом и подключением в оба проекта. Число правок за цикл выпуска — с 8-12 до одной-двух, и те касаются смысла иконки, а не её геометрии.

Отклик заказчика: «перестали спорить, какой файл актуальный» — набор иконок обновляется из одного места, и обе платформы получают одинаковый результат.

Чем отличается адаптация графики под iOS от Android?

Разница начинается с того, кому принадлежит форма. В iOS маску со скруглениями накладывает сама система, поэтому дизайнер отдаёт полный квадрат, а углы срезаются уже на устройстве — прозрачности в исходнике быть не должно, фон является частью иконки. В Android используется двухслойная схема: фон и символ лежат отдельно, форму задаёт оболочка устройства и может менять её от круглой до квадратной со скруглением, добавляя наклон при повороте экрана.

Ключевое расхождение — в безопасных зонах. В Android символ обязан помещаться во внутренний круг, который заметно меньше полотна: остальное кольцо уходит под маску и параллакс. В iOS маска срезает куда меньше, поэтому один и тот же рисунок, плотно уложенный в андроидную зону, на iOS выглядит мелким и потерянным. Отсюда и берётся отдельная версия под платформу — вопрос не вкуса, а геометрии.

Второй слой — оптический вес символа. На iOS иконка чаще лежит на однотонной подложке, и тонкие линии на ней теряют контраст; на Android символ скользит над подвижным фоном, и те же линии разваливаются при наклоне. Стоковые толщины приходится разводить: на одной платформе штрих уплотняем, на другой разгружаем, композицию поджимаем к центру.

Один общий файл работает там, где знак простой, центрированный, с запасом по краям, на спокойном фоне без градиентов и без элементов у границы безопасной зоны. Отдельная версия нужна, если силуэт держится на форме углов, есть мелкие детали, сложный фон или требуется поддержка тёмной темы и монохромного режима — там маска и перекраска ломают исходный замысел.

Перед сдачей мы накладываем макеты на реальные маски платформ, прогоняем контраст на светлом и тёмном фоне и смотрим иконку в мелком размере, где и проявляется расхождение по весу. Это и есть проверка требованиям платформ к графике — до того, как приложение уйдёт в публикацию.

Частые технические сомнения: масштабирование, фон, обновление

Графика — та часть релиза, где правки после выпуска обходятся дороже всего, поэтому вопросы по ней лучше снять заранее. Ниже — самые частые: обновление набора в уже опубликованном продукте, частичная перерисовка, расхождение комплектов при синхронизации, потерянные исходники и удалённая работа с командой заказчика.

Нужно перерисовать одну иконку из набора — придётся переделывать всё?

Нет. Если мастер-файлы со слоями сохранены, правится только нужный знак, остальные остаются нетронутыми. Мы синхронизируем его с общей сеткой и оптическим весом соседей, иначе один элемент начинает «выпадать» из ряда.

Что делать, если комплекты для разных платформ при обновлении расходятся?

Мы держим единый мастер-файл, из которого генерируются оба набора, поэтому расхождение исключено по построению. Отдельно задаются правила масштабирования и подложки: как знак ведёт себя на светлом и тёмном фоне и что попадает в системные размеры.

Исходники потерялись. Набор можно восстановить?

Можно. Мы перерисовываем знак векторно по растровому эталону и заново выстраиваем слоистую структуру, сверяя результат по контрольным размерам. На выходе заказчик получает редактируемые файлы, а не только готовые картинки.