Мы разрабатываем мобильные приложения для дневников питания и знаем: техническая сложность сосредоточена не в архитектуре, а в данных. База продуктов с корректными КБЖУ — это годы работы диетологов и инженеров. Штрих-код сканер работает хорошо ровно до тех пор, пока пользователь не достаёт локальный йогурт без кода или продукт с несколькими порциями на упаковке. За время работы мы реализовали более 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 с кешированием результата. Это уменьшает нагрузку на сеть и позволяет работать офлайн. В таблице ниже — сравнение источников:
| Источник | Охват | Rate limit | Точность данных |
|---|---|---|---|
| USDA | США, базовые продукты | 1000/день | Высокая (верифицировано) |
| Open Food Facts | Глобальный | 400/мин бесплатно | Средняя (краудсорсинг) |
| Edamam | Глобальный, с акцентом на рецепты | 400/мин бесплатно | Высокая (партнёрские базы) |
| Локальный кеш | Пользовательский | Не ограничен | Настраиваемая |
Как мы строим приложение для дневника питания?
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 месяц после релиза (исправление критических ошибок)
Ориентиры по срокам
| Функционал | Сроки |
|---|---|
| MVP (ручной ввод, поиск, дневник, статистика) | 4–6 недель |
| Полный продукт (сканер, синк с HealthKit/Health Connect, рецепты, графики, push) | 10–16 недель |
Стоимость рассчитывается индивидуально после анализа требований. Чтобы получить консультацию, свяжитесь с нами — оценим ваш проект за 1-2 рабочих дня. Обратитесь к нашим менеджерам, чтобы заказать разработку под ключ.
О чём ещё важно помнить
- Для сканера используем AVCaptureSession на iOS и CameraX на Android.
- Корректность расчётов при нестандартных единицах порций и нулевом содержании нутриентов — обязательная часть тестирования.
- Офлайн-режим: поиск в локальном кеше, добавление продуктов с последующей синхронизацией.