Подготовка ассетов iOS для @1x, @2x, @3x

Почему подготовка ассетов iOS ломает релизы приложения

Один макет уходит в разработку, а дальше начинается ручная работа: под каждый масштаб графики — @1x, @2x, @3x — картинку выгружают отдельно, переименовывают и раскладывают по папкам. Дизайнер отдал один набор, второй дорисовали по памяти, третий взяли из прошлого релиза — и уже никто не скажет, какой файл актуальный, а какой остался от предыдущей итерации.

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

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

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

Что даёт единый конвейер графики в приложении

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

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

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

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

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

Три способа собрать графику под разные экраны

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

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

Этапы наведения порядка в графике приложения

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

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

Дальше поддержка идёт предсказуемо: новый экран — тот же путь и те же проверки.

Что остаётся в проекте и документации после работы

Работа заканчивается не собранным каталогом, а правилами, по которым следующий дизайнер или разработчик повторит результат без нас. В проект уходят структура каталога, регламенты и инструкции — всё, что описывает, откуда берётся каждый @1x, @2x и @3x и что делать при добавлении новой графики.

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

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

Кейс: приложение с разросшимся набором изображений

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

Что изменили

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

Метрики до и после

Набор сократился с 620 файлов до 390 — дубли вычистили и больше не создаём. Время подготовки графики упало с двух-трёх дней до трёх-четырёх часов, цикл выпуска обновления — с двух недель до недели. Класс ошибок «не тот масштаб» из релизов ушёл: за десять последних выпусков ни одного отката по графике.

Что делать, если ассеты уже разъехались по репозиториям?

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

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

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

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

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

Технические сомнения: масштабы, вес, приватность

Три плотности — @1x, @2x, @3x — закрывают почти весь парк устройств, но не отменяют ручных решений. Иконки и логотипы отдаём вектором, растровые наборы готовим только там, где вектор недоступен: фотоконтент, текстуры, сложные эффекты прозрачности. Иначе в сборке оседают десятки файлов, которые никто не проверяет на реальных экранах.

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

Что с лицензиями на шрифты и графику?

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

Как быть с закрытыми материалами?

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

Обсудим задачу: как мы заходим в ваш проект

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

Чтобы подготовить оценку и план работ, нам нужно от вас:

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

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