Створення іконки для 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.

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

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

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

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

Повернути застосунок на попередні місця складніше, ніж виправити оформлення, тому зняття виправдане лише якщо цього прямо вимагає рев'ю.

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

Технічні питання, які ставлять перед стартом

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

Як знак виглядатиме на різних пристроях і в темній темі?

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

Чи можна оновити іконку без випуску нової версії?

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

Що потрібно з вашого боку на вході?

Векторний макет або знак у кривих, палітру, правила відступів і мінімальний допустимий розмір логотипа. Якщо макета немає — зберемо майстер-файл самі та покажемо контрольні рендери до того, як файл піде у збірку.

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

Іконка — перше, що бачить користувач у каталозі, і один із пунктів, на яких найчастіше спотикається публікація.

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

• Склад робіт — від аудиту поточного набору до фінальної викладки, з розбивкою за етапами та точками, де потрібне ваше узгодження.
• Вимоги до макета: розміри, сітка, відступи, заокруглення, формати вихідних файлів — списком, який дизайнери застосовують без листування з нами.
• Готовий набір іконок під усі потрібні розміри й режими, включно з темною темою та варіантами для різних поверхонь системи.
• План робіт із термінами за етапами та зрозумілою схемою взаємодії: хто погоджує, хто передає вихідні файли і в якому вигляді.
• Список перевірок перед відправленням на модерацію — щоб іконка пройшла з першого разу, а не повернулася із зауваженням про прозорість або заокруглені кути.
• Інструкцію з оновлення іконки в наступних релізах: як змінювати набір, не ламаючи вже опубліковані версії.
• Підтримку на етапі публікації: повернули зауваження — розбираємо причину й правимо.

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