Підготовка асетів 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, далі перевірки йдуть автоматично — дублі, втрачені щільності та застарілі версії відсікаються до збірки, а не після релізу.

Що з ліцензіями на шрифти та графіку?

Шрифт усередині застосунку ліцензується окремо від настільного, частину накреслень вбудовувати не можна. Звіряємо умови з правовласником до експорту й фіксуємо в реєстрі асетів, що і в якому вигляді дозволено розповсюджувати.

Як бути із закритими матеріалами?

Працюємо з вивантаженням потрібного шару, тестовими даними та знеособленими макетами. Доступ видаємо точково й відкликаємо після передачі — вихідники не покидають контур замовника.

Обговоримо задачу: як ми заходимо у ваш проєкт

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

Щоб підготувати оцінку та план робіт, нам потрібно від вас:

• Розуміння продукту — призначення застосунку, платформи, очікуване навантаження й цільова аудиторія.
• Матеріали щодо інтерфейсу — макети у вихідниках, каталог асетів, стани екранів, темна й світла теми, якщо вони передбачені.
• Доступи — репозиторій, тестовий стенд серверної частини, кабінет публікації та ключі підпису, якщо застосунок уже випускався.
• Межі відповідальності — що закриваємо ми, а що залишається на вашому боці: підтримка серверної частини, контент, дизайн нових екранів.
• Обмеження — строки, прив'язані до дати, вимоги щодо сумісності з уже працюючими версіями застосунку.
• Точку приймання — хто з вашого боку приймає результат і за якими критеріями.

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