Mobile App Development for Nutrition Diary
A nutrition diary is one of those applications where technical complexity isn't in architecture but in data. A product database with correct macros — this is years of work by dietitians and engineers. A barcode scanner works fine until the user pulls out a local yogurt without a barcode or a product with multiple servings per package.
Where the Complexity Concentrates
Product Database. USDA FoodData Central, Open Food Facts, Edamam — three popular sources. Each has quirks: USDA doesn't cover CIS products, Open Food Facts has crowdsourced data with missing nutrients, Edamam returns API requests with 400 per-minute rate limit on the free plan. We build a hybrid system: local database with cache of popular products (SQLite / Room / CoreData), API fallback on cache miss, user products module for custom items.
Barcode Scanner. On iOS we use AVCaptureSession with AVMetadataObjectTypeEAN13Code and other formats. The problem is the session must start quickly — the user already has the phone over the package. If you initialize the session lazily when opening the screen, 0.5–0.8 second latency hurts UX. Solution — preload the session at app authorization time. On Android via CameraX with BarcodeScanning from ML Kit, similar approach: initialize ImageAnalysis.Analyzer early.
Macro Norms. Daily calorie requirements are calculated using the Mifflin-St Jeor equation with activity coefficient adjustment. The user enters height, weight, age, activity level — gets a goal. But the goal changes: as weight decreases, recalculate the norm every 2–4 weeks. This state needs to be stored with history so retrospective analytics is correct.
How We Build It
Flutter + Riverpod for cross-platform, or native Swift/UIKit + CoreData + Combine for iOS-only projects. Data model: FoodItem (nutrients per 100g), MealEntry (timestamp, food, serving in grams, meal type — breakfast/lunch/dinner/snack), DailyLog (daily aggregate). Daily aggregation is cached: recalculate only when adding/deleting entries for that day.
Recipes are a separate Recipe entity with array of RecipeIngredient. When adding a recipe to the diary, we expand ingredients with portion recalculation. It's important to store a snapshot of macros when adding, not a reference to the live recipe — otherwise editing a recipe breaks historical analytics.
From practice: HealthKit integration to record calories to Apple Health through HKQuantityType.dietaryEnergyConsumed. Users with Apple Watch expect this — otherwise the app doesn't count in the ecosystem. Similarly on Android — Health Connect API (ExerciseSessionRecord, NutritionRecord).
Work Process
We determine product data sources, target markets (this determines the database), whether health integration is needed, monetization model (freemium, subscription). We design the database schema, prototype key screens, develop MVP, test on real devices with physical barcodes.
Timeline Guidelines
MVP with manual entry, basic search, diary and daily stats — 4–6 weeks. Full product with scanner, HealthKit/Health Connect sync, recipes, month charts and push reminders — 10–16 weeks. Pricing is calculated individually.
Testing Focus
Scanning with different lighting (supermarket dimness is common), macro calculation correctness with non-standard portion units, proper handling of products with zero nutrient values, offline behavior (search in local cache without API calls).