Как согласовать дизайн мобильного приложения, если iOS и Android должны выглядеть по-разному

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

Почему iOS и Android не могут жить по одному макету

Apple и Google формализовали свои принципы в отдельных гайдлайнах — Human Interface Guidelines и Material Design — и они расходятся не в деталях, а в базовой логике интерфейса. Навигация снизу экрана устроена иначе, кнопка «назад» на Android системная, а на iOS — часть макета, отступы и единицы измерения считаются по-разному (pt против dp), иконки и модальные окна ведут себя не одинаково. Пытаться выдать один макет за решение для обеих платформ — то же самое, что сдать один чертёж для двух разных фундаментов: формально он есть, но строить по нему нельзя.

Что ломается в согласовании, когда клиент видит две версии вместо одной

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

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

Один поток ревью или два параллельных?

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

Чек-лист — что сверять на каждой платформе перед одобрением

• Навигация: таб-бар/системная навигация соответствует паттернам платформы, а не скопирована с другой
• Зоны нажатия: минимальный размер тач-таргетов выдержан для конкретной платформы
• Иконки: нет смешения стилей (не используются Android-иконки в iOS-версии и наоборот)
• Типографика: системные шрифты и их начертания не заменены произвольно
• Тёмная тема: обе версии проверены в светлой и тёмной теме, а не только в одной
• Состояния ошибок: пустые экраны, ошибки загрузки, офлайн-режим проработаны на обеих платформах одинаково по смыслу, но не обязательно одинаково по форме

Как зафиксировать решение, чтобы iOS- и Android-версии не разошлись через 2 итерации

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

Когда согласование можно сократить

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