A macro tracker for people who already know their food.

The brief

The macro tracker market is crowded, and most apps have the same problem: the food database is English-first, the barcode step is clunky, and the visual language is either sports-store-loud or hospital-clinical. The brief was a tracker that feels premium in Turkish, respects that a user knows what they're eating, and works with one hand while you're already at the checkout.

What I built

• Turkish food database. Local database of common Turkish meals and ingredients (values per 100g) so a user doesn't have to translate their lunch into an English search term.
• Live barcode scanning. Full-screen camera view with a custom cutout scrim and an animated scan line. On a valid scan, a bottom sheet slides up with the product, live portion-to-calorie math, and a one-tap add.
• OpenFoodFacts integration. REST client against the OpenFoodFacts API with a local cache layer so a re-scanned barcode returns instantly and works offline.
• Mifflin–St Jeor BMR/TDEE engine. Personalised daily targets from the user's profile — age, sex, height, weight, activity level, goal — computed on device.
• Home ring + meal sections. Calories-remaining ring on the home screen, four meal sections (breakfast, lunch, dinner, snack), water intake, and a running history chart across days.
• Two-FAB action stack. A subtle secondary FAB for the barcode scanner sits above the primary "Add Food" button — one thumb, two shortcuts.
• Cloud build. GitHub Actions workflow that produces a signed release APK on every push, so the app can ship without a local Flutter setup.

Design language

Dark background, warm accent, generous type, a single accent colour used sparingly. The rings, cards and lists share the same geometry so the whole app reads as one object. Icons are outline, motion is short and springy, and everything above the fold answers one question: how much macro budget do I have left today?

Analysis

The barcode flow is the app's smallest surface and its most important one — it's the moment where the app either earns daily use or gets uninstalled. Time-to-first-scan on a mid-range Android is under two seconds; the bottom sheet gives the user live portion math while they type, so a 40g portion vs a 60g portion updates in the moment. That's the design principle across the whole app: every screen answers a question, then gets out of the way.

Engineering notes

The cloud-build path took four iterations to get clean — a Dart const-with-runtime-expression compile error, a Kotlin version mismatch (shared_preferences_android required Kotlin 1.9+ against a Flutter 3.24 default of 1.7), and an Android manifest merger issue where a permission block was landing inside <application> rather than before it. Final: Flutter 3.27.0, a corrected sed insertion pattern, and a clean signed APK on every push. That whole story is a useful reminder that most "AI-first" mobile projects still live and die on the boring build pipeline.