Розробка головного екрана (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.

Notification-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 у coroutines. Обидва підходи — паралельні запити, не послідовні. Послідовні запити дають суму TTI (Time to Interactive) замість максимума.

Skeleton на час загрузки — обов'язковий. Home Screen без skeleton при повільному інтернеті показує пустий білий екран на 2–4 секунди. Це сприймається як краш.

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

Процес та терміни

Вартість розраховується індивідуально після аналізу ТЗ та архітектури.