Разработка главного экрана (Home Screen) мобильного приложения

Разработка главного экрана (Home Screen) мобильного приложения

Home Screen — первое, что видит авторизованный пользователь. Это агрегатор: он показывает самое важное из разных разделов приложения, предоставляет быстрый доступ к ключевым действиям и задаёт тон всему продукту. Спроектировать его плохо — означает, что пользователь при каждом открытии приложения не понимает, куда идти и что делать.

Архитектурное решение: секции vs лента vs дашборд

Три принципиально разных подхода к домашнему экрану:

Секционированный список — вертикальный scroll с горизонтальными карусельями внутри секций. Классика для eCommerce и контентных приложений (Spotify, Netflix, Airbnb). Реализуется через UICollectionView с compositional layout на iOS или LazyColumn с вложенными LazyRow в Compose. Технический нюанс: вложенный горизонтальный скролл в вертикальном контейнере требует явного указания nestedScrollEnabled на Android, иначе жест скролла перехватывается неправильно.

Дашборд с виджетами — сетка или произвольная раскладка блоков с метриками, быстрыми действиями, статусами. Характерен для финансовых приложений, банков, здоровья. На iOS виджеты как таковые — это другое (WidgetKit для экрана устройства), внутри приложения это просто кастомный grid layout.

Персонализированная лента — бесконечный скролл смешанного контента, ранжированного под пользователя. Требует backend с рекомендательной системой; сам экран — это UITableView/LazyColumn с heterogeneous cell types.

Выбор определяется не предпочтениями дизайнера — а тем, что за продукт и какой главный use case пользователя.

Персонализация и состояния «нового» vs «активного» пользователя

Home Screen нового пользователя (только зарегистрировался, данных нет) и пользователя с историей — это два разных экрана. Нового нужно направить: onboarding-подсказки, заглушки с призывом заполнить данные, рекомендации на основе категории. У активного — реальные данные, персонализированный контент, история.

Если показывать новому пользователю экран с пустыми виджетами — это воспринимается как баг. Дизайн должен явно решить этот вопрос, а не оставлять разработчику.

Header и персональное приветствие

Персональное обращение «Привет, Алексей» — хороший паттерн для создания ощущения персонального продукта. Технически: имя пользователя из локального кэша (UserDefaults / SharedPreferences / MMKV), не ждём ответа API. Аватар из кэша с placeholder пока загружается — URLCache на iOS, Coil + DiskCache на Android.

Уведомление-badge в header (иконка колокольчика с цифрой непрочитанных) — популярный элемент. Цифра берётся из push-payload или из API; UNUserNotificationCenter.current().getDeliveredNotifications() на iOS возвращает только доставленные, не прочитанные — нужна собственная логика счётчика.

Быстрые действия (Quick Actions)

Горизонтальный ряд кнопок под header: «Перевести», «Оплатить», «История» и т.д. Количество — не больше 4–5, иначе иконки слишком маленькие или нужен горизонтальный скролл, что ломает дискавераемость. Если действий больше — показываем 4 + «Ещё», которое открывает полный список.

Иконки быстрых действий — кастомные (не SF Symbols), потому что часто несут брендовый смысл. Состояния: default, pressed (scale down 0.95), disabled.

Баннеры, промо и уведомления внутри экрана

Промо-банер вверху или после header — частый элемент. Carousel с auto-scroll (PageViewController на iOS, HorizontalPager в Compose). Auto-scroll должен останавливаться, когда пользователь взаимодействует вручную — иначе крайне раздражает.

In-app уведомления (не push) — плашки с важным сообщением: «Подтвердите email», «Обновите приложение», «Карта заканчивается». Dismissible, сохраняют dismissed-state в UserDefaults / DataStore, не появляются снова.

Производительность главного экрана

Home Screen часто грузит данные из нескольких API параллельно. На iOS через async let в Swift Concurrency или TaskGroup. На Android через viewModelScope.launch + async/await в корутинах. Оба подхода — параллельные запросы, не последовательные. Последовательные запросы дают суммарный TTI (Time to Interactive) вместо максимального.

Skeleton на время загрузки — обязателен. Home Screen без skeleton при медленном интернете показывает пустой белый экран на 2–4 секунды. Это воспринимается как краш.

Оптимизация для повторного открытия: данные кэшируются (URLCache, Retrofit + OkHttp Cache, или custom storage), экран отображает кэш мгновенно и обновляет в фоне — паттерн stale-while-revalidate.

Процесс и сроки

Стоимость рассчитывается индивидуально после анализа ТЗ и архитектуры.