Создание иконки для iOS: технические требования и процесс

Иконка iOS: почему приложение отклоняют на проверке

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

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

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

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

Что даёт единая система графики и как её измерить

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

Правки перестают размножаться по файлам

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

Ручная нарезка уходит из выпуска

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

Отказы отображения закрываются до выпуска

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

Стабильное отображение между обновлениями

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

Сравнение подходов к оформлению: что и когда подходит

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

Как выбрать режим

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

Как проходит работа: от аудита макетов до передачи

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

1. Аудит макетов. Разбираем исходник: вектор или растр, есть ли прозрачность и скругления, как иконка читается на светлой и тёмной теме. На выходе — правки к дизайну и схема набора под все размеры и режимы отображения.
2. Настройка каталога исходников. Собираем изображения в каталог, который подхватывает сборка: имена файлов, привязка к размерам и вариантам отображения. Ошибка в структуре — и подставится системная иконка, поэтому каталог проверяем отдельно.
3. Слои и маски. Убираем альфа-канал, выравниваем поля, следим, чтобы композицию не съедала системная маска. Края и центр остаются читаемыми и в настройках, и в карточке магазина.
4. Тестовая сборка. Ставим на реальные устройства с разными экранами и темами: список приложений, домашний экран, уведомления, поиск. Отдельно проверяем кэш — после обновления система может показывать старую версию.
5. Передача заказчику. Отдаём каталог исходников, макет, правила именования и инструкцию по замене, чтобы команда обновляла иконку своими силами. Плюс памятка, что проверять перед релизом.

Дальше набор живёт вместе с проектом: при смене брендинга или добавлении тем иконки iOS пересобираются по этой же схеме.

Комплект исходников, правил и регламентов обновления

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

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

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

Кейс: как пересборка иконки iOS ускорила выпуск обновлений

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

Что было

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

Что изменили

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

Что стало

Подготовка комплекта сократилась с 2-3 недель до 2 дней, а правки дизайна перестали блокировать релиз: пересборка занимает минуты. За 14 релизов — ни одного отклонения по оформлению иконки, цикл выпуска обновлений сократился почти вдвое, а сама иконка перестала быть отдельным согласованием между дизайном и разработкой.

Что делать, если оформление уже опубликовано с ошибками?

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

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

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

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

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

Технические вопросы, которые задают перед стартом

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

Как знак будет выглядеть на разных устройствах и в тёмной теме?

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

Можно ли обновить иконку без выпуска новой версии?

Иконка лежит внутри сборки, поэтому замена означает новую сборку и повторную проверку в магазине. Без релиза переключается только альтернативный вариант — если он заранее заложен и вызывается из настроек приложения.

Что нужно с вашей стороны на входе?

Векторный макет или знак в кривых, палитру, правила отступов и минимальный допустимый размер логотипа. Если макета нет — соберём мастер-файл сами и покажем контрольные рендеры до того, как файл уйдёт в сборку.

Обсудим задачу: вернёмся с оценкой и планом работ

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

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

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