Розробка мобільного додатку для щоденника харчування

Ми розробляємо мобільні додатки для щоденників харчування і знаємо: технічна складність зосереджена не в архітектурі, а в даних. База продуктів з коректними КБЖУ — це роки роботи дієтологів та інженерів. Сканер штрих-кодів працює добре рівно доти, доки користувач не дістає місцевий йогурт без коду або продукт з кількома порціями на упаковці. За час роботи ми реалізували понад 20 проєктів у сфері трекінгу харчування і готові поділитися досвідом.

Розробка мобільного додатку для щоденника харчування: технічні виклики

База продуктів. USDA FoodData Central, Open Food Facts, Edamam — три популярні джерела. У кожного свої примхи: USDA не покриває СНД-продукти, Open Food Facts має краудсорсингові дані з пропусками в нутрієнтах, Edamam віддає API-запити з rate limit 400 на хвилину на безкоштовному плані. Будуємо гібридну систему: локальна база з кешем популярних продуктів (SQLite / Room / CoreData), fallback на API при промаху кешу, модуль користувацьких продуктів для кастомних позицій. Локальний кеш зберігає до 50 000 найчастіше запитуваних продуктів, займаючи близько 100 МБ на пристрої. При першому запуску додаток завантажує базовий набір з 10 000 продуктів. Такий підхід забезпечує швидкість пошуку в 3 рази вищу порівняно з чисто хмарним рішенням.

Сканер штрих-кодів. На iOS використовуємо AVCaptureSession з AVMetadataObjectTypeEAN13Code та рядом інших форматів. Проблема в тому, що сесія має стартувати швидко — користувач уже тримає телефон над упаковкою. Якщо ініціалізувати сесію ліниво при відкритті екрана, затримка 0.5–0.8 секунди б'є по UX. Рішення — preload сесії в момент авторизації на екрані. На Android через CameraX з BarcodeScanning з ML Kit аналогічний підхід: ініціалізувати ImageAnalysis.Analyzer заздалегідь.

Норми КБЖУ. Добова норма калорій розраховується за формулою Міффліна-Сан Жеора з коригуванням на коефіцієнт активності. Користувач вносить зріст, вагу, вік, рівень активності — отримує ціль. Але ціль змінюється: при зниженні ваги треба перераховувати норму кожні 2–4 тижні. Цей стан потрібно зберігати з історією, щоб ретроспективна аналітика була коректною.

Чому гібридна база даних — оптимальне рішення?

Гібридна архітектура поєднує швидкість локального кешу та актуальність хмарних API. Ми гарантуємо, що 80% запитів користувача обробляються з локальної бази (середній час відповіді <100 мс), а решта 20% — через API з кешуванням результату. Це зменшує навантаження на мережу і дозволяє працювати офлайн. У таблиці нижче — порівняння джерел:

Як ми будуємо додаток для щоденника харчування?

Flutter + Riverpod для крос-платформи, або нативно Swift/UIKit + CoreData + Combine для iOS-only проєкту. Модель даних: FoodItem (нутрієнти на 100г), MealEntry (timestamp, їжа, порція в грамах, прийом їжі), DailyLog (агрегат по днях). Агрегацію по днях кешуємо: перераховуємо тільки при додаванні/видаленні записів за цей день.

Рецепти — окрема сутність Recipe з масивом RecipeIngredient. При додаванні рецепту до щоденника розгортаємо інгредієнти з перерахунком порцій. Важливо зберігати знімок КБЖУ в момент додавання, а не посилання на живий рецепт — інакше редагування рецепту ламає історичну аналітику.

З практики: інтеграція з HealthKit для запису калорій в Apple Health через HKQuantityType.dietaryEnergyConsumed. Користувачі з Apple Watch вимагають цього — інакше додаток не вважається в екосистемі. Аналогічно на Android — Health Connect API (ExerciseSessionRecord, NutritionRecord).

Для push-сповіщень використовуємо APNs на iOS та FCM на Android. Налаштовуємо категорії: нагадування про прийоми їжі, сповіщення про досягнення цілі. Deep linking через Universal Links/App Links дозволяє відкривати додаток за посиланням на конкретний продукт.

Як ми тестуємо сканування в складних умовах?

Сканування перевіряємо при різному освітленні (напівтемрява супермаркету — частий сценарій), з різними кутами нахилу та відстанями. Використовуємо фізичний набір з 100+ штрих-кодів різних форматів (EAN-13, UPC-A, Code 128). Для кожного сценарію вимірюємо успішність розпізнавання — наш середній результат 98% при нормальному освітленні та 90% у напівтемряві. Це досягається за рахунок попереднього налаштування параметрів камери та алгоритмів стабілізації.

Як ми забезпечуємо безпеку користувацьких даних?

Додаток запитує дозвіл на відстеження через ATT (App Tracking Transparency) на iOS. Всі дані про харчування зберігаються локально з шифруванням (CryptoKit на iOS, Jetpack Security на Android). При синхронізації з сервером використовуємо TLS 1.3 та токени автентифікації з коротким терміном життя. Користувач може експортувати дані в CSV або Google Sheets.

Що входить у нашу роботу

• Технічна документація (архітектура, схеми даних, API-специфікації)
• Вихідний код з тестами (unit, widget, integration)
• Інтеграція з HealthKit/Health Connect (за запитом)
• Налаштування push-сповіщень (APNs/FCM)
• Допомога з публікацією в сторах (App Store Connect, Google Play Console)
• Підтримка 1 місяць після релізу (виправлення критичних помилок)

Орієнтири за термінами

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

Про що ще важливо пам'ятати

• Для сканера використовуємо AVCaptureSession на iOS та CameraX на Android.
• Коректність розрахунків при нестандартних одиницях порцій та нульовому вмісті нутрієнтів — обов'язкова частина тестування.
• Офлайн-режим: пошук у локальному кеші, додавання продуктів з подальшою синхронізацією.

Аналітика мобільних застосунків: Firebase, Amplitude, AppsFlyer та атрибуція

Наша команда регулярно стикається з проектами, де аналітика вже «налаштована», але реальних інсайтів немає. Типовий приклад — стартап з 50k DAU: трекінг десятків подій без жодної відповіді на питання «чому користувачі не доходять до оплати». За два тижні ми побудували базову воронку і з'ясували, що 70% аудиторії відвалюється на екрані верифікації номера телефону. Після локалізації бага retention зріс на 12%. Висновок: аналітика повинна починатися з конкретних питань, а не з трекінгу всього підряд.

Чому таксономія подій — основа аналітики мобільних застосунків?

Firebase Analytics, Amplitude, Mixpanel — технічно схожі. Різниця в тому, що ви в них кладете. Типова помилка: події screen_view, button_tap_1, button_tap_2 без контексту. Через місяць ніхто не пам'ятає, що таке button_tap_2.

Правильна таксономія: об'єкт + дія + контекст. product_viewed, checkout_started, payment_completed з параметрами product_id, category, price, source. Це дозволяє будувати воронки, когортний аналіз та retention без додаткового трекінгу.

Ми фіксуємо naming convention у tracking plan — документі (Google Sheet або Amplitude Data Catalog), де описано кожну подію, її параметри та умови спрацьовування. Tracking plan синхронізується з командою аналітиків до початку розробки, а не після. Такий підхід гарантує, що через місяць дані залишаться інтерпретованими, а не перетворяться на звалище. Досвід впровадження на 50+ проектах підтверджує: при відсутності tracking plan вартість підтримки аналітики зростає у 2-3 рази за рахунок переробок.

Що обрати для аналітики мобільних застосунків: Firebase, Amplitude чи Mixpanel?

Таблиця нижче показує ключові відмінності трьох популярних платформ. Вибір залежить від бюджету, трафіку та завдань.

Firebase Analytics — безкоштовно, глибока інтеграція з Google Ads, BigQuery-експорт для сирих даних. Обмеження: затримка даних до 24 годин, обмежені воронки. Для стартапів з Google Ads трафіком — перший вибір.

Amplitude — продуктова аналітика з акцентом на когорти та шляхи користувача. Journeys (колишній Pathfinder) показує реальні шляхи між подіями — не передбачувані воронки, а фактичні маршрути. Session Replay — запис сесій для UX-аналізу. Безкоштовний тир до 10 млн events/місяць достатній для більшості продуктів на старті.

Mixpanel — ближче до Amplitude, сильніший у сегментації в реальному часі. Insights, Funnels, Retention — базові інструменти, які закривають 90% аналітичних завдань продакта.

Більш формальні визначення цих платформ можна знайти у Wikipedia (Firebase) та Wikipedia (Amplitude).

Як вирішити проблему мультиканальної атрибуції з AppsFlyer?

Знати звідки прийшов користувач — окреме завдання. Firebase Attribution працює лише всередині Google-екосистеми. Для мультиканальної атрибуції (Facebook Ads, TikTok, Apple Search Ads, programmatic) потрібен MMP — Mobile Measurement Partner.

AppsFlyer — лідер ринку. OneLink — universal deep link, який працює на iOS та Android і коректно атрибутує встановлення з будь-якого каналу. Protect360 — вбудований захист від fraud (фейкові встановлення, click injection на Android). Adjust та Branch — конкуренти з подібним функціоналом. Branch сильний у deep linking; Adjust популярний у gaming.

Згідно з Apple, з iOS 14.5 застосунки повинні отримувати дозвіл користувача через ATT перед збором IDFA для відстеження. AppsFlyer використовує probabilistic matching (IP + user agent + timing) для цих користувачів — точність нижча, але краще ніж нічого. SKAdNetwork та Privacy Preserving Attribution надають агреговані дані від Apple із затримкою 24-72 години.

Як налаштувати crash-аналітику, щоб не пропускати баги?

Firebase Crashlytics — стандарт для crash reporting. Автоматично групує креші за стектрейсом, показує affected users %, velocity alerts при зростанні crash rate більш ніж на 10% за годину.

Важливо: символікація. На iOS .dSYM файли повинні автоматично завантажуватися при кожній збірці — через Fastlane upload_symbols_to_crashlytics або Xcode Cloud built-in. Без символів креш у Crashlytics виглядає як набір адрес пам'яті. Це трапляється частіше, ніж здається при переході на новий CI — в одному проекті з аудиторією 500k користувачів ми виявили, що 40% крешів залишалися несимволізованими через пропущений етап у CI/CD. Після автоматизації час реакції на баги скоротився з 3 годин до 15 хвилин.

Для React Native та Flutter — @sentry/react-native та sentry_flutter дають додатковий контекст: breadcrumbs, мережеві запити перед крешем, стан Redux/Provider.

Нижче — порівняння популярних інструментів crash-аналітики для вибору під свої завдання.

Налаштування оточення

Три оточення з окремими Firebase проектами: dev, staging, production. Змішувати аналітику з тестових сесій і production — поширена помилка, яка спотворює всі метрики. На iOS через GoogleService-Info.plist для кожної схеми, на Android через google-services.json у папці кожного flavor.

Терміни: базова аналітика з Firebase + Crashlytics — 3-5 днів. Повноцінний tracking plan + Amplitude/Mixpanel з воронками та когортами — 2-3 тижні. Атрибуція через AppsFlyer з deep linking та fraud protection — 1-2 тижні. Вартість розраховується індивідуально залежно від складності інтеграцій.

Що входить у нашу роботу

В рамках впровадження аналітики ми надаємо:

• Розробку та узгодження tracking plan з командами продукту та маркетингу.
• Інтеграцію SDK (Firebase, Amplitude, Mixpanel, AppsFlyer) з урахуванням вашого стеку (Swift/Kotlin/Flutter/React Native).
• Налаштування воронок, когорт, дашбордів та алертів.
• Автоматизацію символікації та завантаження .dSYM через Fastlane.
• Документацію щодо подій та параметрів.
• Навчання команди роботі з аналітичною платформою.
• Два тижні пост-релізної підтримки та коригування трекінгу.

Наш досвід — 7 років впровадження аналітики та понад 80 успішних проектів у сфері мобільної розробки. Ми гарантуємо коректність даних і прозорість кожного етапу.

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