Дизайн мобильного приложения под iOS и Android: различия гайдлайнов и как их совместить

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

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

Статья рассчитана на продуктовых дизайнеров, которые впервые готовят макеты под обе платформы, и на продакт-менеджеров, которым нужно объяснить команде и заказчику, почему «просто перекрасить iOS-макет для Android» не получится. Мы опираемся на актуальные версии гайдлайнов: iOS 26 с материалом Liquid Glass и Material 3 Expressive, которые обе компании показали в 2025 году.

Почему интерфейсы iOS и Android вообще различаются?

Обе платформы решают одну задачу — дать человеку быстро сделать нужное на маленьком сенсорном экране. Но они выросли из разных философий. Apple исторически строит интерфейс вокруг контента: элементы управления стараются «уступить» место содержимому, а глубина передаётся размытием, полупрозрачностью и движением. В Human Interface Guidelines это сформулировано через принципы ясности, уважения к контенту и глубины, а в iOS 26 продолжено материалом Liquid Glass — полупрозрачными панелями, которые преломляют контент под собой.

Google в Material Design изначально опирался на метафору физического материала: листы бумаги лежат друг над другом, отбрасывают тени, а движение объясняет, откуда что появилось. Material 3 добавил динамический цвет (палитра строится из обоев пользователя), а Material 3 Expressive — больше форм, пружинную анимацию и крупные выразительные компоненты.

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

Третья причина — привычки пользователей. Человек, который годами пользуется одной платформой, переносит её паттерны в каждое новое приложение: ищет «Назад» там, где он обычно бывает, ждёт определённого поведения от свайпа и долгого нажатия. Интерфейс, который ломает эти ожидания, кажется «не таким», даже если пользователь не может объяснить почему.

Чем Human Interface Guidelines отличаются от Material Design?

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

Полные версии правил — в Human Interface Guidelines Apple и на сайте Material Design 3. Их стоит держать открытыми во время работы: гайдлайны обновляются каждый год, и детали, которые были верны два релиза назад, могли поменяться.

Единицы измерения, сетка и размеры экранов

В iOS макет рисуют в points. Один point на старых экранах равен одному пикселю, на Retina — двум, на экранах Super Retina — трём. Поэтому растровую графику экспортируют в трёх размерах (@1x, @2x, @3x), хотя @1x на современных устройствах уже практически не нужен. В Android базовая единица — dp (density-independent pixel), для текста — sp, который дополнительно учитывает пользовательскую настройку размера шрифта. Графика раскладывается по корзинам плотности от mdpi до xxxhdpi, а векторные иконки удобнее отдавать в формате Vector Drawable.

Стартовые фреймы тоже разные. Для iOS команды обычно берут актуальный «средний» iPhone (393×852 pt у iPhone 15 и 16), для Android — 360×800 dp или 412×915 dp. Главное — проверить макет на краях диапазона: самом узком экране и самом широком, включая планшеты и складные устройства. Подробнее про сетку и шаг отступов мы писали в статье о системе 4/8 pt: она одинаково хорошо работает на обеих платформах, потому что 8 делится и на точки, и на dp без дробей.

Отдельная история — безопасные зоны. На iPhone это вырез или Dynamic Island сверху и индикатор «домой» снизу. На Android с версии 15 приложения, нацеленные на актуальный SDK, по умолчанию рисуются «от края до края» (edge-to-edge): контент уходит под строку состояния и панель навигации, а отступы задаются через системные insets. Если дизайнер не нарисовал, что происходит под системными панелями, разработчик решит это сам — и не всегда так, как задумывалось.

• рисуйте в pt для iOS и в dp для Android, не в пикселях;
• держите шаг сетки кратным 4 или 8;
• отмечайте безопасные зоны и поведение контента под системными панелями;
• проверяйте макет на самом узком и самом широком экране.

Типографика: SF Pro против Roboto

Системный шрифт iOS — SF Pro (для текста и заголовков), на Apple Watch — SF Compact, для «книжного» чтения есть антиква New York. Шкала Dynamic Type задаёт роли: Large Title, Title 1–3, Headline, Body, Callout, Subheadline, Footnote, Caption 1–2. Базовый размер основного текста — 17 pt. Шрифт сам подстраивает межбуквенный интервал под кегль, поэтому вручную трекинг SF Pro обычно не трогают.

В Android системный шрифт — Roboto (в Material 3 часто Roboto Flex), но производители смартфонов нередко заменяют его своим, так что точного совпадения с макетом на всех устройствах не будет. Шкала Material 3 построена по ролям: Display, Headline, Title, Body и Label, каждая в трёх размерах — Large, Medium, Small. Body Large — 16 sp.

Главное общее требование — масштабирование. Пользователь может увеличить системный шрифт: в iOS через Dynamic Type, в Android — вплоть до 200% начиная с Android 14. Макет, в котором текст жёстко заперт в контейнеры фиксированной высоты, на крупном шрифте развалится. Закладывайте перенос строк, растущие по высоте карточки и альтернативную раскладку для самых крупных размеров. Если продукт использует фирменный шрифт, его тоже нужно привязать к системному масштабированию, а не только к макету.

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

Навигация и кнопка «Назад»: самое заметное различие

Именно навигация чаще всего выдаёт приложение, «перенесённое» с другой платформы. В iOS верхний уровень почти всегда — tab bar внизу экрана, от трёх до пяти разделов. В iOS 26 панель вкладок стала плавающей, из Liquid Glass, и умеет сжиматься при прокрутке, освобождая место контенту. Гамбургер-меню Apple не рекомендует: скрытые разделы реже открывают.

В Android есть три варианта. На телефонах основной — navigation bar внизу, тоже 3–5 пунктов. На планшетах и в горизонтальной ориентации — navigation rail, вертикальная полоса слева. Для большого числа разделов или редко используемых пунктов — navigation drawer, выезжающая панель. Подробно о выборе схемы — в статье о навигации в мобильном приложении.

Возврат назад устроен принципиально по-разному. В iOS «Назад» — это кнопка в левом верхнем углу навигационной панели с подписью или стрелкой, плюс жест-свайп от левого края экрана. Если на экране нет кнопки «Назад», пользователю iPhone вернуться неочевидно. В Android «Назад» — системная функция: жест от любого бокового края или кнопка в панели навигации. Стрелка в top app bar есть, но она дублирует системный возврат. С Android 13 появился predictive back: при начале жеста система показывает, куда пользователь вернётся, и в свежих версиях эта анимация работает по умолчанию у приложений, которые её поддержали.

Отсюда несколько практических следствий:

1. Не размещайте в iOS-версии важных жестов на левом крае экрана — он занят возвратом.
2. В Android не делайте собственную кнопку «Назад» внизу экрана: системная уже есть, а две конкурирующие сбивают с толку.
3. Определите, что делает «Назад» на каждом экране, включая модальные окна и формы с несохранёнными данными, и опишите это в спецификации.
4. Учитывайте поведение вкладок: в iOS каждая вкладка обычно хранит свою историю, а повторное нажатие на активную вкладку возвращает к её корню. В Android-реализациях поведение зависит от выбранной архитектуры навигации, и его стоит зафиксировать явно.

Компоненты, которые есть только на одной платформе

Часть элементов у платформ общая, но называется по-разному: action sheet и bottom sheet, segmented control и segmented button, alert и dialog. А часть существует только у одной стороны, и попытка перенести её «как есть» создаёт ощущение чужеродности.

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

Практическое правило: если компонент существует только на одной платформе, на второй ищите не визуальную копию, а аналог по задаче. Snackbar с «Отменить» в iOS обычно превращается в короткий баннер или в возможность отменить действие через меню; FAB — в кнопку в навигационной панели или в заметную кнопку в контенте.

Цвет, материалы, тени и тёмная тема

В iOS глубину передают размытие и полупрозрачность, а не тени. Liquid Glass в iOS 26 усилил это: панели навигации, вкладки и всплывающие элементы стали «стеклянными» и показывают контент под собой. Для дизайнера это означает, что контраст текста на таких панелях зависит от того, что лежит под ними, и проверять его нужно на реальном контенте, а не на однотонной подложке.

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

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

Анимации, жесты и тактильный отклик

Анимации iOS — физические и непрерывные: экран следует за пальцем, его можно «отпустить» на полпути, переходы прерываются без рывков. Дочерний экран въезжает справа, модальное окно поднимается снизу как карточка, которую можно смахнуть вниз. В Material движение объясняет иерархию: элемент раскрывается из того места, на которое нажали (container transform), а переходы между разделами одного уровня обычно мягко растворяются. Material 3 Expressive сделал пружинные кривые основой системы движения.

Жесты тоже распределены по-разному. В iOS левый край отдан возврату, свайп вниз закрывает модальные карточки, долгое нажатие открывает контекстное меню с предпросмотром. В Android оба боковых края заняты системным «Назад», а долгое нажатие традиционно включает режим выбора. Не назначайте собственные важные действия на системные жесты — пользователь их не найдёт или будет срабатывать не то.

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

Иконка приложения, сторы и первый запуск

Иконку для App Store готовят в одном размере 1024×1024 px, скругление система накладывает сама. В iOS 26 иконки стали многослойными: Apple предлагает собирать их в Icon Composer, чтобы система могла показывать светлый, тёмный, тонированный и «прозрачный» варианты. В Android используется адаптивная иконка: передний и задний слои по 108×108 dp, из которых гарантированно видна центральная зона около 72 dp — форму маски задаёт оболочка производителя. Для тематических иконок Android 13+ нужен ещё монохромный слой.

Различаются и требования сторов. В App Store действует ручная модерация по App Store Review Guidelines, в Google Play — свои правила и автоматические проверки, плюс требования к целевой версии SDK. Скриншоты для сторов готовят под разные форматы. Экран запуска в iOS — статичная заглушка без брендовых анимаций и рекламы, в Android 12+ — системный Splash Screen с иконкой по центру. Подробнее про первые минуты пользователя в приложении — в статье об онбординге.

Один дизайн или два: как выбрать стратегию?

На практике встречаются три подхода, и у каждого есть своя область применения.

Мы рекомендуем по умолчанию второй вариант. Общими остаются бренд, палитра, иллюстрации, контент, иконки продукта, основная логика экранов. Платформенными — навигация верхнего уровня, возврат назад, системные компоненты (диалоги, выбор даты, меню, переключатели), жесты и анимации переходов. Если приложение собирают на Flutter или React Native, это тоже реализуемо: во Flutter, например, есть и Material-, и Cupertino-виджеты, а адаптивные компоненты переключаются по платформе.

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

Как адаптировать макет под вторую платформу: пошаговый план

Допустим, основной макет уже готов под iOS, и нужно сделать Android-версию. Порядок работы, который экономит больше всего времени:

1. Вынесите всё общее в токены. Цвета, типографика, отступы, радиусы и тени — в семантических переменных с отдельными значениями для каждой платформы. Как это устроить, мы описывали в руководстве по дизайн-токенам.
2. Составьте карту компонентов. Таблица «компонент iOS → аналог в Material → что меняется». Отдельно отметьте компоненты, у которых нет аналога, и решение для них.
3. Перестройте навигацию. Tab bar → navigation bar, кнопки «Назад» → системный возврат и стрелка в top app bar, large title → top app bar с выравниванием влево.
4. Замените системные элементы. Диалоги, action sheet, выбор даты и времени, переключатели, поля ввода, меню — на платформенные версии.
5. Пересчитайте размеры. Зоны нажатия — не меньше 48 dp, типографика — по шкале Material, безопасные зоны и поведение под системными панелями — по правилам edge-to-edge.
6. Опишите жесты и переходы. Что делает свайп, долгое нажатие, системное «Назад» на каждом ключевом экране.
7. Проверьте на устройствах. Минимум один бюджетный Android с маленьким экраном, один флагман, планшет или складной телефон, крупный системный шрифт и тёмную тему.
8. Передайте разработке спецификацию различий. Отдельный раздел в документации: какие экраны и компоненты отличаются и почему. Процесс передачи мы подробно разбирали в статье о передаче дизайна в разработку.

Частые ошибки при дизайне под обе платформы

• Android-версия как копия iOS. Кнопка «Назад» в левом верхнем углу без системного возврата, iOS-переключатели и колесо выбора даты — пользователи Android сразу это замечают.
• Гамбургер-меню в iOS для основных разделов. Скрытая навигация снижает использование разделов, и в iOS она выглядит чужой.
• Фиксированные размеры текста. На крупном системном шрифте подписи обрезаются, кнопки «съезжают».
• Важные действия на системных жестах. Свайп от края, конфликтующий с возвратом назад.
• Забытые состояния. Пустые экраны, загрузка, ошибка сети, отсутствие прав — на обеих платформах их нужно нарисовать.
• Контраст на полупрозрачных панелях. Текст на Liquid Glass или тональных поверхностях проверяют на реальном контенте, а не на белом фоне.
• Устаревшие гайдлайны. Ориентир «как было в прошлом году» — частая причина замечаний на ревью и визуального старения приложения.

Чек-лист перед передачей макетов в разработку

• Макеты в pt (iOS) и dp/sp (Android), сетка кратна 4 или 8.
• Зоны нажатия: не меньше 44×44 pt и 48×48 dp.
• Навигация верхнего уровня и возврат назад соответствуют платформе.
• Системные компоненты заменены на платформенные аналоги, есть карта соответствий.
• Типографика привязана к Dynamic Type и масштабированию sp, проверена на крупном шрифте.
• Светлая и тёмная темы на семантических токенах, контраст проверен по WCAG.
• Безопасные зоны, вырезы, edge-to-edge и поведение под системными панелями отрисованы.
• Жесты и анимации переходов описаны, учтена настройка уменьшения движения.
• Иконка приложения подготовлена в форматах обеих платформ, включая тёмный и монохромный варианты.
• Есть спецификация различий между версиями и согласована с разработкой.

Если пройтись по этому списку до начала разработки, большая часть «платформенных» замечаний не всплывёт на тестировании и в отзывах пользователей после релиза.

Редакция Флагштока

Пишем об UX/UI-дизайне: исследования, интерфейсы, дизайн-системы и доступность.