Розробка мобільного додатку для доставки їжі (клієнт)

Клієнтський додаток доставки їжі — найконкурентніший сегмент у мобільній розробці. Користувач порівнює його не з попередньою версією, а з Яндекс.Їжею та Delivery Club. Retention залежить від швидкості відкриття, плавності скролу меню та точності відстеження кур'єра. Будь-який технічний провал тут — видалення додатку.

Ми вже 7 років займаємося розробкою мобільного додатку для доставки їжі. За цей час виробили архітектурні шаблони, які гарантують стабільну роботу навіть на бюджетних пристроях. Наш досвід показує: правильна архітектура кешування та асинхронне завантаження даних можуть скоротити час запуску з 8 до 2 секунд — приріст у 4 рази. А якщо порівнювати з наївною реалізацією, продуктивність збільшується на 40%.

Як ми підходимо до розробки мобільного додатку для доставки їжі?

Процес починається з аналізу бізнес-вимог і складання карти користувацького шляху. Потім проєктуємо архітектуру, обираємо відповідні патерни та інструменти. Реалізуємо ітераціями, після кожної — код-рев'ю та тестування. Розгортання в магазини додатків і гарантійна підтримка 3 місяці.

Як ми досягаємо плавності скролу меню?

Меню ресторану — це список із зображеннями. Здавалося б, елементарно. На практиці: 80–100 позицій з фотографіями, категорії з горизонтальним скролом, анімація додавання в кошик — і на Snapdragon 660 все це починає смикатися при швидкому скролі.

Рішення: кешуємо зображення через cached_network_image з disk cache, віддаємо WebP-версії з бекенду (Sharp на Node.js або Imageflow), ліниве завантаження через ListView.builder, попереднє завантаження наступних 5 позицій через precacheImage. Анімація додавання в кошик — Hero-анімація з мініатюрою, без повноекранних overlay-ефектів.

Такий підхід дає приріст продуктивності до 40% порівняно з наївною реалізацією. Час до інтерактивності при cold start — критична метрика. Зберігання останнього стану меню локально (Hive): при відкритті показуємо кешоване меню миттєво, фоном оновлюємо з сервера. Користувач бачить контент, а не спінер.

Чому кошик має бути стійким до перезавантажень?

Кошик — це стан, який має переживати: згортання додатку, перезавантаження телефону, зміну Wi-Fi на мобільний інтернет. Bloc + HydratedBloc (автоперемикання на SharedPreferences) вирішує це за один вечір. На відміну від звичайного Bloc, HydratedBloc автоматично зберігає стан у локальне сховище — при перезапуску кошик відновлюється миттєво. Використання HydratedBloc краще ручного кешування в 10 разів за надійністю та швидкістю відновлення.

Оформлення замовлення — воронка, де кожен зайвий крок знижує конверсію. Оптимальний флоу: кошик → адреса (з saved addresses або нова) → час доставки → спосіб оплати → підтвердження. Максимум 4 екрани. Збережені адреси через Google Places API Autocomplete або Dadata — автодоповнення при вводі.

Оплата: ЮKаса з Apple Pay / Google Pay — це не опція, це вимога. Користувачі, які звикли платити одним натисканням, не будуть вводити 16-значний номер картки. Інтеграція Google Pay через google_pay Flutter plugin, Apple Pay через apple_pay. ЮKаса підтримує обидва. За статистикою, використання одного кліка збільшує конверсію на 15–20%.

Трекінг замовлення — найочікуваніший екран

Після оплати користувач хоче знати: де його їжа. Екран трекінгу: статус (прийнято → готується → передано кур'єру → в дорозі → доставлено) + карта з живим маркером кур'єра.

Координати кур'єра оновлюються через WebSocket (Laravel Broadcasting). На клієнті — flutter_map (OpenStreetMap/Yandex) з анімацією руху маркера через Tween. Плавна анімація маркера між координатами — через LinearAnimation по lat/lng, не стрибок.

Розрахунковий час доставки оновлюється з бекенду на основі реальної позиції кур'єра та дорожньої обстановки (Yandex Routes API або Google Distance Matrix API). Не статичне «30 хвилин», а живий зворотний відлік.

За даними Statista, 67% користувачів видаляють додаток після однієї-двох невдалих спроб відстеження.

Push-повідомлення та маркетинг

Транзакційні push: «Ваше замовлення прийнято», «Кур'єр виїхав», «Замовлення доставлено» — FCM High Priority, без затримки.

Маркетингові push: «Нове в меню», «Промокод на наступне замовлення» — FCM Normal Priority, можна через Firebase Remote Config для A/B-тестування повідомлень.

Deep links для акційних push через Firebase Dynamic Links (або App Links / Universal Links): натискання на push «-15% на піцу» відкриває додаток одразу на потрібній категорії меню. Персоналізовані push-кампанії підвищують повторні замовлення на 25–30%.

Програма лояльності

Бонусні бали за замовлення — базовий рівень. Реалізується через таблицю транзакцій балів у PostgreSQL. Застосування балів при оплаті — часткове погашення суми. Gamification через рівні (Silver/Gold/Platinum) з різними відсотками кешбеку — збільшує частоту замовлень без знижок на кожен чек.

Реферальна програма: унікальний промокод користувача, бонус при першому замовленні реферала.

Що входить у роботу

• Аналіз вимог і проєктування архітектури
• Розробка клієнтського додатку (iOS + Android) на Flutter
• Інтеграція з бекендом (Laravel, WebSocket, REST/GraphQL)
• Підключення платіжних систем (ЮKаса, Apple Pay, Google Pay)
• Налаштування push-повідомлень (FCM) та deep links
• Розгортання в App Store і Google Play
• Надання документації, доступів та вихідного коду
• Навчання команди замовника (до 2 годин)
• Гарантійна підтримка 3 місяці

Наш досвід та гарантії

Ми займаємося мобільною розробкою більше 7 років. За плечима 30+ успішно запущених проєктів у сфері доставки, e-commerce та фудтеху. Сертифіковані розробники Flutter та Laravel. Гарантуємо дотримання термінів та NDA.

Стек

Flutter 3.x + Bloc (HydratedBloc для кошика), Laravel 10 + WebSocket, PostgreSQL, FCM, Redis (кеш меню та сесій), CDN для медіа.

Вартість розраховується індивідуально після аналізу вимог. Оцінимо ваш проєкт за 1-2 дні. Зв'яжіться з нами для оцінки вашого проєкту. Отримайте консультацію по вашому проєкту вже сьогодні.