Input before taxonomy
The user describes the meal first. Structuring, matching, and macro resolution happen after expression instead of making database search the front door.
Native iOS · AI nutrition01 / 04
MealRecap
Make food logging feel like telling a friend what you ate.
TYPESPEAKPHOTO
→SERVER-SIDE RESOLUTIONSay what you ate.
→OpenAI · USDA · Open Food Facts
DAILY RECAPCaloriesProteinMacros
ROLE / OWNERSHIP
Product direction · iOS UX · SwiftUI engineering · backend architecture
STATUS
Active product build
TIMELINE
2026
Nutrition logging is usually organized around searching somebody else’s food database. That makes a simple behavior—saying what you ate—feel like clerical work.
Natural human input is imprecise. The product has to accept ordinary language, speech, and photos, resolve that into useful nutrition data, keep external-service credentials off the device, and still feel calm.
KEY DECISIONS
The work behind the screen.
Keep intelligence behind the server boundary
OpenAI and nutrition-service credentials are called through Firebase Functions rather than being embedded in the iOS binary.
Use multiple evidence sources
USDA FoodData Central and Open Food Facts can contribute nutrition resolution while HealthKit can provide optional health context.
Treat monetization as product architecture
StoreKit 2 is part of the product model rather than something bolted on after the interface is finished.
The product intentionally avoids making a giant searchable food database the primary interaction. That creates backend resolution complexity, but preserves a much faster front-door experience.
WHAT THE BUILD PROVES
Evidence, not adjectives.
- Three input modes converge into one meal model
- Service credentials stay out of the app binary
- Nutrition resolution is separated from the calm logging interface
SwiftUIHealthKitSpeechFirebaseCloud FunctionsOpenAIUSDA FoodData CentralOpen Food FactsStoreKit 2
VERIFIABLE EVIDENCE
Inspect the work.
- Natural language, voice, and photo capture are three paths into one meal model.
- Secrets stay server-side instead of shipping inside the app.
- The landing experience is live and the implementation is publicly inspectable on GitHub.
Have something complicated that needs to feel simple?