Гайдлайны интерфейса мобильных приложений: требования iOS и Android

Каждый год Apple App Store Review отклоняет десятки тысяч приложений — и значительная часть реджектов связана не с функциональностью, а с нарушением платформенных требований к интерфейсу. Гайдлайны интерфейса мобильных приложений — это не «вкусовщина дизайнера» и не необязательные рекомендации: это условие допуска в сторы и предсказуемого пользовательского опыта. Apple Human Interface Guidelines (HIG) и Google Material Design 3 определяют, как должны выглядеть и работать приложения на каждой платформе. Нарушить их — значит не только рисковать реджектом, но и сломать ожидания пользователей, которые привыкли к стандартам своей операционной системы.

В этой статье разберём ключевые требования Apple HIG и Google Material Design, покажем, чем iOS-паттерны отличаются от Android, объясним, за что чаще всего реджектят, и расскажем, как встроить соответствие гайдлайнам в процесс разработки. Материал будет полезен продуктовым менеджерам, основателям и всем, кто принимает решения о дизайне мобильного приложения.

Что такое гайдлайны интерфейса и зачем они бизнесу

HIG и Material Design — это «конституции» своих платформ. Они задают правила, по которым приложения должны выглядеть и работать на iOS и Android соответственно. Но для бизнеса важнее прикладное следствие: нарушение гайдлайнов напрямую влияет на деньги.

Во-первых, это реджект в App Store или Google Play. Платформы проверяют соответствие своим требованиям при каждой публикации и обновлении. Реджект — это задержка выхода продукта, дополнительные итерации разработки и доработки дизайна, то есть прямые затраты. Во-вторых, это поведение пользователей: человек, пришедший с iPhone, ожидает привычную навигацию через tab bar и свайп назад. Если приложение работает иначе — он уходит. По данным исследований Nielsen Norman Group, пользователи тратят большую часть времени в других приложениях и ожидают, что ваше будет работать так же.

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

Apple Human Interface Guidelines: ключевые требования iOS

Apple публикует Human Interface Guidelines для всех своих платформ. Для мобильной разработки под iOS ключевые разделы касаются навигации, типографики, системных компонентов и безопасных зон экрана.

Навигация: tab bar, nav bar, свайп-назад

На iOS основная навигация между разделами приложения реализуется через tab bar — панель с иконками в нижней части экрана. Именно такую навигацию ожидает пользователь iPhone. Перемещение между экранами внутри раздела — это navigation bar вверху с кнопкой возврата и жестом свайпа от левого края (edge swipe back). Замена этих паттернов на гамбургер-меню или навигацию в верхней части экрана нарушает ожидания пользователей iOS и является типичной причиной замечаний при ревью.

Отдельного внимания заслуживает кнопка «Назад»: на iOS она генерируется системой автоматически и должна работать через UINavigationController. Перехватывать или скрывать её без весомой причины запрещено гайдлайном.

Safe area, notch/Dynamic Island, отступы

Начиная с iPhone X, у Apple появилась «чёлка» (notch), а с iPhone 14 Pro — Dynamic Island. Системный механизм safe area указывает, в каких границах контент не будет перекрыт системными элементами. Игнорирование safe area ведёт к тому, что кнопки и текст «уходят» под вырез или Dynamic Island — и это один из частых поводов для реджекта. Все интерактивные элементы должны находиться внутри safe area insets, а фоновые изображения могут выходить за её пределы для визуального эффекта.

SF Symbols, шрифт San Francisco, Dynamic Type

SF Symbols — это иконографическая система Apple, включающая более 6000 символов, оптимизированных под шрифт San Francisco. Использование SF Symbols обязательно для системных действий (назад, поделиться, настройки, удалить). Применение сторонних иконок там, где Apple предусмотрел стандартные, разрушает консистентность и может вызвать замечания при ревью.

Шрифт San Francisco задаёт типографическую базу iOS. Приложениям не запрещено использовать кастомные шрифты, но они должны поддерживать Dynamic Type — системный механизм масштабирования текста, которым пользуются люди с нарушениями зрения и просто те, кто предпочитает более крупный шрифт. Приложение, не поддерживающее Dynamic Type, ломается при увеличенных размерах шрифта в настройках iOS.

Тёмная тема, тактильная отдача, жесты

iOS поддерживает тёмную тему на системном уровне с iOS 13. Приложения должны адаптироваться к ней автоматически через семантические цвета (systemBackground, label и т.д.) вместо жёстко заданных hex-значений. Приложение, не поддерживающее тёмную тему, выглядит как белое пятно в тёмном интерфейсе — это замечание при ревью и раздражитель для пользователей.

Тактильная отдача (Haptic Feedback) через Taptic Engine — часть пользовательского опыта на iOS. Apple регламентирует сценарии использования тактильной отдачи: подтверждение действия, ошибка, выбор. Избыточная или нелогичная вибрация трактуется как нарушение гайдлайна.

Google Material Design 3: ключевые требования Android

Google Material Design 3 (Material You) — это актуальное поколение дизайн-системы Google, введённое с Android 12. Оно принципиально отличается от предыдущих версий динамическими цветами и персонализацией под тему системы.

Material You, динамические цвета, токены

Material You позволяет приложениям автоматически адаптировать цветовую схему под обои пользователя через механизм Dynamic Color. На Android 12+ система генерирует цветовые токены из обоев, и приложения могут их использовать, чтобы выглядеть органично в контексте телефона конкретного пользователя. Реализация Dynamic Color — не обязательное требование для публикации, но её наличие является сигналом качества для Google Play.

Дизайн-токены — основа Material Design 3: цвет, типографика, форма, состояния компонентов описываются через токены, а не жёсткие значения. Это упрощает темизацию и поддержку при обновлении дизайн-системы.

Навигация: navigation bar/rail/drawer, системная кнопка «назад»

Android предлагает несколько паттернов навигации в зависимости от размера экрана: navigation bar (нижняя панель, до 5 пунктов) для телефонов, navigation rail (боковая вертикальная панель) для планшетов и складных устройств, navigation drawer (выдвигающаяся панель) для сложных иерархий. В 2024 году Google рекомендует предпочитать navigation bar над hamburger-меню для приложений с 3–5 основными разделами — это ближе к привычкам пользователей и лучше работает с жестовой навигацией.

Особое место занимает системная кнопка «Назад» (или жест свайп от края экрана в Android 10+). Приложение обязано корректно её обрабатывать: переходить на предыдущий экран, закрывать диалоги, сворачиваться при выходе из первого экрана. Игнорирование back gesture — распространённая причина замечаний при ревью Google Play.

Elevation, состояния компонентов, edge-to-edge

Material Design использует elevation (высоту над «поверхностью») для отображения иерархии элементов: чем выше elevation, тем больше тень и отступ от фонового слоя. FAB (Floating Action Button), диалоги и нижние шторки имеют фиксированные значения elevation из спецификации.

Начиная с Android 15, edge-to-edge рендеринг становится обязательным: приложение должно рисовать контент под системными панелями (status bar, navigation bar) и корректно применять window insets. Приложения, не перешедшие на edge-to-edge, будут получать принудительные insets от системы — это может сломать вёрстку, особенно у bottom sheet и navigation bar.

Адаптивность под фрагментацию экранов и плотностей

Android-экосистема включает тысячи устройств с разными размерами экрана и плотностями пикселей (от mdpi до xxxhdpi). Material Design 3 задаёт систему адаптивных макетов через breakpoints: compact (телефоны), medium (складные, планшеты 600–840dp), expanded (большие планшеты, десктоп). Приложение должно корректно работать во всех трёх режимах — Google Play требует этого для листинга в категории «Планшеты и большие экраны».

iOS против Android: чем отличаются паттерны

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

Элемент	iOS (HIG)	Android (Material 3)
Основная навигация	Tab Bar (внизу, до 5 вкладок)	Navigation Bar (внизу) / Navigation Rail (сбоку на планшетах)
Кнопка «Назад»	Кнопка в navigation bar + свайп от левого края	Системная кнопка/жест от нижнего края или бокового края
Типографика	San Francisco + Dynamic Type (обязательна)	Roboto / кастомный + адаптация через sp (масштабируемые пиксели)
Иконки	SF Symbols (обязательны для системных действий)	Material Symbols (рекомендованы, не обязательны)
Тёмная тема	Семантические цвета системы (UIColor.systemBackground и т.д.)	Dynamic Color (Material You) + тёмные токены
Диалоги и шторки	UIAlertController (системный стиль), ActionSheet	AlertDialog, ModalBottomSheet (Material-компоненты)
Шаринг	UIActivityViewController (системный Share Sheet)	Intent.ACTION_SEND (системный Intent Chooser)
Уведомления	Запрос разрешения при первом обращении, стандартные стили	Android 13+: явный запрос POST_NOTIFICATIONS, кастомные каналы

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

Доступность (accessibility) как часть гайдлайнов

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

Минимальный размер тач-целей: Apple рекомендует не менее 44×44 точек для всех интерактивных элементов; Google — не менее 48×48 dp. Иконки-кнопки меньшего визуального размера должны иметь невидимую «зону касания» нужного размера через padding или hitbox.

Контраст: по WCAG 2.2 минимальное соотношение контраста основного текста к фону — 4.5:1, для крупного текста (18pt+) — 3:1. Цвета, которые «красиво смотрятся» в Figma, могут не проходить проверку контраста, особенно на белом фоне в светлой теме iOS.

VoiceOver (iOS) и TalkBack (Android) — экранные дикторы для людей с нарушениями зрения. Каждый элемент интерфейса должен иметь осмысленный accessibility label (не «кнопка» или «изображение», а «Добавить в корзину» или «Фото профиля»). Изображения, несущие смысловую нагрузку, должны иметь alt-текст; декоративные — помечаться как isAccessibilityElement = false.

Dynamic Type на iOS: пользователи с нарушениями зрения часто устанавливают очень крупные размеры шрифта. Если вёрстка не адаптирована к ним, текст либо обрезается, либо перекрывает другие элементы. Apple проверяет поддержку Dynamic Type при ревью приложений для App Store. На Android аналог — масштабирование текста через системные настройки; шрифты должны использовать sp (scale-independent pixels), а не dp.

За что реджектят в App Store и Google Play

Ниже — практический чек-лист типичных нарушений гайдлайнов, которые приводят к отклонению при ревью. Он не заменяет полный текст App Store Review Guidelines и политик Google Play, но покрывает большинство частых кейсов.

App Store (Apple) — типичные причины реджекта по UI:

• Контент выходит за пределы safe area — перекрывается Dynamic Island или нотчем.
• Использование нестандартных иконок вместо SF Symbols для системных действий (Share, Back, Delete).
• Отсутствие поддержки Dynamic Type — текст обрезается при крупных системных шрифтах.
• Нет поддержки тёмной темы — приложение выглядит как белое пятно в Dark Mode.
• Кастомный жест навигации конфликтует с edge swipe back системы.
• Кнопки или ссылки меньше 44×44 pt без увеличенной зоны касания.
• Приложение не сохраняет состояние при переходе в фон и обратно (suspending/resuming).
• Нет корректного поведения при переворачивании экрана (если приложение должно поддерживать ориентации).
• Accessibility labels отсутствуют или бессодержательны («кнопка», «image1»).
• Использование приватных API или нестандартных жестов, конкурирующих с системными.

Google Play (Android) — типичные причины отклонения по UI:

• Приложение не обрабатывает системную кнопку/жест «Назад» — пользователь не может выйти из экрана.
• Нет адаптации под edge-to-edge: контент уходит под status bar или navigation bar.
• Приложение не поддерживает ни одну из рекомендованных ориентаций или крашит при повороте.
• Текст задан в dp вместо sp — не масштабируется при увеличении шрифта в настройках.
• Нет разрешения POST_NOTIFICATIONS (Android 13+) — push-уведомления не работают без запроса.
• Приложение запрашивает чрезмерные разрешения, не обоснованные функционалом (нарушение политики, не HIG, но часто сопровождает UI-проблемы).
• Нет поддержки больших экранов (планшеты, складные) — интерфейс «растягивается» на весь экран без адаптации.
• Контент-элементы меньше 48×48 dp без padding до нужного размера тач-зоны.

Как встроить гайдлайны в процесс разработки

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

Дизайн-система на токенах. Если команда создаёт компоненты через дизайн-токены (цвет, типографика, отступы, состояния), а не хардкодит значения — обновление под новые версии HIG или Material Design превращается в замену токенов, а не переверстку всего приложения. UI/UX-дизайн мобильного интерфейса с такой дизайн-системой в несколько раз снижает стоимость поддержки и адаптации под обновления платформ.

Ревью макетов на соответствие гайдлайнам. Перед передачей в разработку каждый экран должен проверяться на соответствие платформенным требованиям: safe area, размеры тач-зон, наличие accessibility labels в спецификации, поддержка тёмной темы. Это занимает часы на этапе дизайна и экономит дни на этапе разработки и ревью.

Тестирование на реальных устройствах. Эмуляторы не воспроизводят всё поведение системы — Dynamic Island, вибрацию, системные шрифты, поведение safe area на нестандартных соотношениях сторон. Для прохождения ревью без замечаний приложение нужно проверять на реальных устройствах, минимум по одному на iOS и Android разных поколений.

Автоматизированные проверки доступности. Инструменты Xcode Accessibility Inspector (iOS) и Android Accessibility Scanner (Android) автоматически находят контрастные проблемы, слишком маленькие тач-цели и отсутствующие labels. Их запуск можно встроить в CI/CD-пайплайн, чтобы проблемы не доходили до ревью.

В разработке мобильных приложений соответствие гайдлайнам — это не дополнительная опция, а часть качества поставки. Команды, которые встраивают проверки с самого начала, проходят App Store и Google Play ревью с первого раза и быстрее выводят продукт на рынок.

Спроектируем интерфейс под гайдлайны iOS и Android

YuSMP проектирует и реализует мобильные интерфейсы, которые проходят ревью App Store и Google Play с первого раза.

Обсудить дизайн приложения

Частые вопросы (FAQ)

Обязательно ли следовать HIG и Material Design?

Технически — нет. Но нарушения гайдлайнов являются одной из главных причин реджектов при ревью App Store и Google Play. Помимо этого, приложения, игнорирующие платформенные паттерны, вызывают у пользователей дискомфорт: незнакомая навигация и нестандартные жесты повышают отток. Поэтому следование HIG и Material Design — это условие допуска в сторы и предсказуемого пользовательского опыта.

Можно ли сделать одинаковый интерфейс на iOS и Android?

Формально — можно, и кроссплатформенные фреймворки (Flutter, React Native) именно так и работают. Но пользователи iOS привыкли к tab bar внизу, свайпу назад и SF Symbols, а пользователи Android — к navigation bar и системной кнопке «назад». Полностью идентичный UI нарушает ожидания одной из аудиторий. Правильный подход — единая дизайн-система с платформенными адаптациями компонентов навигации и типографики.

За какие нарушения гайдлайнов чаще всего реджектят?

Apple чаще всего отклоняет приложения за: использование сторонних иконок вместо SF Symbols там, где они обязательны; игнорирование safe area (контент под нотчем или Dynamic Island); нестандартные паттерны навигации; некорректное отображение при Dynamic Type. Google Play чаще режет за: отсутствие поддержки системной кнопки «Назад»; игнорирование edge-to-edge отрисовки; несоответствие политике безопасности и разрешений.

Чем HIG отличается от Material Design простыми словами?

HIG (Apple) — набор принципов и правил для iOS/iPadOS/macOS, ориентированных на элегантность, минимализм и нативное ощущение платформы. Material Design (Google) — система визуального языка, основанная на метафоре «материи» с тенями, состояниями компонентов и динамическими цветами. HIG более консервативен и директивен; Material Design гибче и чаще обновляется. Оба задают норму для своей платформы, нарушение которой ощущается пользователями как «что-то не так».

Нужны ли гайдлайны, если приложение на Flutter или React Native?

Да, и особенно важны. Кроссплатформенные фреймворки по умолчанию не адаптируют компоненты под платформу автоматически. В Flutter нужно явно использовать CupertinoWidgets для iOS-паттернов и Material widgets для Android. В React Native — использовать Platform.OS для условного рендеринга. Пренебрежение этим ведёт к «Android-приложению на iOS» — раздражающему и более уязвимому к реджекту.

Как гайдлайны связаны с доступностью?

HIG и Material Design напрямую включают требования доступности: минимальный размер тач-целей (44pt на iOS, 48dp на Android), поддержку VoiceOver и TalkBack, совместимость с Dynamic Type. Обе платформы также следуют WCAG 2.2 по контрасту (минимум 4.5:1 для обычного текста). Игнорирование доступности — риск реджекта в App Store (Apple активно проверяет accessibility) и снижение охвата аудитории.