Macronutrient Barcode Scanner with Pie Chart UI

What is the app actually doing between scan and chart?

A lookup, a calculation, and a visualization, and only the last one is yours to design. The flow: scan a barcode, resolve it to a food product with per-100g nutrition data, compute the macros for the portion the user actually ate, and render the protein/carbs/fat split as a pie. The barcode scan feels like the feature, but it is the cheapest step; the honest work is the data source and the portion math.

The data is the genre’s real dependency. Open Food Facts is the open database the indie nutrition app runs on, a crowdsourced catalog that passed 4 million products by 2025, queryable by barcode; the USDA FoodData Central database covers generic and whole foods that have no barcode. The honest caveat that shapes the UI: crowdsourced data is incomplete and sometimes wrong, so a scan can miss, return stale values, or hand back an obviously bad number, and the app has to handle all three gracefully rather than presenting whatever it got as gospel.

How does the scanner and lookup actually work?

Scan with VisionKit’s DataScannerViewController (live barcode detection with a real viewfinder) or AVFoundation for more control, resolve the barcode against the database, and design for the three outcomes:

Scan outcome	What happened	What the UI does
Hit	Barcode found with good data	Show the product, confirm the portion
Found but thin	Product exists, missing macros	Show what is known, let the user fill gaps
Miss	Barcode unknown	Manual search or add-the-product flow, never a dead end

The miss case is not an edge case; with crowdsourced data it is common, so a fast manual-search and a contribute-this-product path are core features, not fallbacks. And the data-quality honesty matters: when a returned value is implausible (a drink logged at 900g of protein), flagging it for confirmation beats logging garbage into someone’s day.

Why is the portion the hard part?

Because nutrition data is per-100g and people eat servings. The label says values per 100g; the user ate “1 bar (45g)” or “half the bag” or “2 cups,” so the app’s real calculation is scaling the per-100g macros to the actual portion, which means a portion picker that speaks human (servings, grams, common household units) and converts honestly. Getting this wrong, logging the per-100g values as if that were the portion, is the silent bug that makes a nutrition tracker quietly useless, because the numbers are plausible but wrong.

The portion UI is where the app earns trust: a sensible default (one serving as the product defines it), quick adjustment, and the macro pie updating live as the portion changes so the user sees the consequence of “actually I had two.”

How should the macro pie be built and framed?

With Swift Charts (SectorMark for the pie/donut), and with honesty about what a pie can and cannot say. The protein/carbs/fat split is genuinely well-suited to a pie because it is parts of a whole, three segments summing to 100% of the macro calories, and a donut with the calorie total in the center is the canonical, readable form. The design rules: label segments with both grams and percent (a pie alone is imprecise), use consistent colors for each macro across the whole app so users learn them, and animate the segments updating as the portion changes.

Two framing honesties keep it useful and legal. Calories from macros (4/4/9 per gram for protein/carbs/fat) is arithmetic the app can show transparently, but the app is a tracker, not a dietitian: no “you should eat” prescriptions, no health claims, just an honest record of what was logged, the same tracker-not-advice line as every health-adjacent build. And HealthKit is the right home for the totals if the user opts in, writing dietary energy and macros so the data lives in one place, the same opt-in health-data discipline as the HealthKit fasting timer ring.

The screens, the scanner, the product confirmation, the portion picker, the macro pie, the daily log, come as a free VP0 design, so an agent builds the lookup and portion math onto a real nutrition UI with the data-miss states already designed. The barcode-scanning craft itself is shared with every scanner build like the barcode scanner viewfinder; the difference here is the portion math and the parts-of-a-whole chart.

Key takeaways: a macro scanner with a pie chart

• Scan is the cheap step; data and portion math are the work: Open Food Facts (4M+ products) by barcode, USDA for generic foods.
• Design for hit, thin, and miss: crowdsourced data is incomplete, so manual search and contribute-product flows are core, not fallbacks.
• The portion is the hard part: scale per-100g values to the real serving; logging per-100g as the portion is the silent useless-tracker bug.
• The pie fits because macros are parts of a whole: Swift Charts SectorMark, labeled with grams and percent, consistent macro colors, live updates.
• Tracker, not dietitian: show the calorie arithmetic, make no prescriptions, and write to HealthKit on opt-in.

Frequently asked questions

How do I build a macronutrient barcode scanner with a pie chart? Scan with VisionKit’s DataScannerViewController, resolve the barcode against Open Food Facts (with USDA FoodData Central for generic foods), scale the per-100g macros to the user’s actual portion, and render the protein/carbs/fat split with Swift Charts SectorMark labeled in grams and percent. A free VP0 design supplies the scanner, portion picker, and macro-pie screens.

Where do nutrition apps get their food data? Open Food Facts, a crowdsourced open database of over 4 million barcoded products, is the common source for indie apps, with USDA FoodData Central covering generic and whole foods that have no barcode. Both are usable, and both require handling incomplete or occasionally wrong entries.

Why is the portion calculation the hard part? Because nutrition data is per 100g while people eat servings, so the app must scale the per-100g macros to the actual portion (a bar, half the bag, two cups). Logging the per-100g values as if they were the portion produces plausible but wrong numbers, the silent bug that makes a tracker useless.

Is a pie chart good for showing macros? Yes, unusually so: protein, carbs, and fat are parts of a whole that sum to 100% of the macro calories, which is exactly what a pie represents well. Use a donut with the calorie total in the center, label segments with grams and percent, and keep consistent macro colors so users learn them.

Can the app tell users what to eat? No: it is a tracker, not a dietitian. Show the calorie arithmetic from the macros transparently, but make no dietary prescriptions or health claims, and write totals to HealthKit on opt-in so the data lives alongside the user’s other health records rather than being siloed.