Apple Health vs CalEye — what the iOS app integration looks like

Apple Health vs CalEye is a misframing that comes up constantly in App Store reviews — people asking why Apple Health doesn’t do what CalEye does, or why CalEye doesn’t just use Apple Health’s built-in nutrition features. The short answer: Apple Health is a data repository, not a tracking app. CalEye is a tracking app that writes to that repository. They are designed to work together, not compete. This article explains exactly what that integration looks like and what it unlocks for iOS users.

For anyone who has opened Apple Health, tapped Nutrition, and wondered why the graphs are empty — this is the article that explains both the gap and how to fill it. If you’re choosing between CalEye and MyFitnessPal, see our 90-day head-to-head comparison.

What Apple Health actually stores

Apple Health on iOS stores health data from multiple sources in a standardised format. The Nutrition category includes 36 nutrient fields: calories (active and resting), protein, total fat, carbohydrates, fibre, sugar, sodium, and individual vitamins and minerals. Apple Health does not capture the data itself — it requires a connected app to write nutrition records.

This architecture is deliberate. Apple Health is a health data aggregator and privacy-controlled record system, not a food database or logging tool. It knows how to store a calorie entry; it doesn’t know how to recognise a dosa or estimate its weight from a photograph.

The HealthKit framework — the underlying API layer — was introduced with iOS 8 in 2014. The Nutrition data type was added in iOS 9 (2015), and the full 36-nutrient schema reached its current form in iOS 11. Since then, the schema has changed very little, which means third-party apps like CalEye, MyFitnessPal, Cronometer, and Lose It! all write to the same standard fields using the same unit conventions (kilocalories for energy, grams for macronutrients, milligrams for sodium).¹

What the empty Nutrition graph in Apple Health means in practice: no app has been granted HealthKit write access for nutrition data, or no app that has been granted access has logged any meals. The graph is not broken — it is waiting for a data source. CalEye is one of those data sources; it writes every logged meal to HealthKit immediately upon log confirmation.

How CalEye connects to Apple Health

When you install CalEye on iOS and grant HealthKit permissions, CalEye writes every logged meal to Apple Health’s Nutrition store as a structured data entry. The permission prompt is explicit: CalEye requests write access to energy consumed (kcal), protein, carbohydrates, dietary fiber, total fat, sugar, and sodium. It requests read access to active energy (exercise calories), resting energy (BMR estimate), step count, and workout data.

Each confirmed CalEye meal log writes to HealthKit with a timestamp, a data type identifier, and the numerical value in standard units. Within seconds of confirming a CalEye meal log, the data appears in Apple Health under Nutrition → Summary. Each nutrient type appears as a separate data point in the Health timeline.

The write happens in the background after each log confirmation — you do not need to take any additional action. If you log three meals and two snacks in a day, five separate write transactions occur, each tagged with the timestamp of the meal event. Apple Health aggregates these into daily totals for its summary views, and also retains the individual meal-level timestamps for any app that queries the timeline with a finer time resolution.

CalEye also reads activity data from Apple Health (active calories, step count, workouts) to adjust net calorie targets, if the user grants read permissions. This is the same permission model used by MyFitnessPal and Lose It! on iOS — bidirectional data flow that allows intake and expenditure to be calculated together rather than in two separate siloed systems.¹

What the integration unlocks

Once CalEye is writing to Apple Health, every app that reads Apple Health nutrition data gains access to your meal logs without any additional action on your part. This includes third-party health monitoring apps, medical-grade clinical apps used by healthcare providers, and any future Apple health features that may read nutrition data.

For users with a continuous glucose monitor that writes to Apple Health — Dexcom G7 and Abbott FreeStyle Libre 3 both have iOS apps that write interstitial glucose readings to HealthKit — the co-location of glucose data and CalEye meal data in the same Health timeline creates a retrospective correlation view.²³ Apple Health’s correlations dashboard will show glucose excursions alongside meal events when both data types are present in the timeline. The timing relationship between a CalEye-logged meal (timestamp of logging) and the subsequent CGM glucose trace (15-minute resolution) is visible in the Health timeline export, though Apple Health’s native interface does not currently visualise this correlation automatically.

The Apple Watch integration adds a third data stream. Apple Watch records active calories (exercise energy expenditure) and resting calories (BMR approximation) continuously, writing to HealthKit every 10 minutes. CalEye reads these values to compute net calories for the day: food calories logged minus active calories burned equals net caloric intake relative to the resting metabolic baseline. This three-way integration — CalEye for food intake, Apple Watch for activity output, HealthKit as the central data store — provides a more complete energy balance picture than any single application produces alone.

What Apple Health does not do

Apple Health has a basic nutrition summary view showing daily calorie totals and macro breakdowns as horizontal bar charts. It is useful for confirming that data is flowing and for seeing weekly summary trends. It does not:

• Identify food from photos or any other visual input
• Estimate portion sizes using computer vision or any algorithmic method
• Compute glycaemic load or any glycaemic index-derived metric
• Provide meal-level breakdowns versus daily aggregates in any analytical view
• Offer any interface beyond bar charts of daily totals and a timeline of individual data points
• Generate any insights, trends, or recommendations based on the nutrition data it stores

The Health app’s nutrition screen is a data viewer, not a dietary management tool. It confirms data is present; it does not help you interpret it or take action based on it. This is not a design failure — Apple Health’s strength is privacy-controlled data storage and cross-app aggregation, not nutritional intelligence. The intelligence layer is what CalEye provides.

Importantly, Apple Health has no understanding of meal composition, food identity, or portion geometry. A calorie entry in Apple Health is a number with a timestamp — the Health app does not know whether those calories came from an apple or from a burger. CalEye knows, because it identified the food visually or from the user’s selection, and it retains that meal-level detail in its own database (accessible in CalEye’s meal history) independently of what is written to HealthKit.

Limitations of the HealthKit nutrition schema

Apple’s HealthKit nutrition schema does not include a glycaemic load field. HealthKit currently supports 36 nutrient types, but GL is not among them — there is no HKQuantityTypeIdentifierDietaryGlycemicLoad type defined in the HealthKit framework as of iOS 17.¹ CalEye stores GL data in its own database and displays it in the per-meal log view. It cannot write GL values to Apple Health because the receiving field does not exist.

The practical implication: GL history lives only in CalEye’s app data. It is not available to other HealthKit-connected apps and is not included in Apple Health’s standard XML export. If you export your health data from Apple Health (Settings → Health → Export All Health Data), the exported file contains all standard HealthKit nutrient fields but no GL data. GL data requires a CalEye-native export, available via CalEye’s Settings → Export Data → CSV. See our guide on exporting nutrition data to share with your dietitian for the full workflow.

Other nutrients that CalEye tracks internally but that fall outside the HealthKit schema include: glycaemic index per food item, per-meal glycaemic load, confidence interval on estimated portions, and individual food item identification within a composite meal. These are CalEye-proprietary data that live in CalEye’s database and are accessible through CalEye’s own export and reporting tools but not through HealthKit.

Phosphorus, potassium, and magnesium are HealthKit-supported nutrients that CalEye does not currently write, because its food database does not uniformly cover these micronutrients with sufficient completeness. Where micronutrient data is incomplete, writing a zero to HealthKit would be misleading; CalEye omits the write for fields it cannot populate reliably.

Comparing native Apple Watch and iPhone health tracking

Apple Watch tracks active calories using a combination of heart rate, accelerometer data, and a user-specific caloric model calibrated to the user’s height, weight, age, and sex. These values write to the Active Energy category in HealthKit automatically every 10 minutes during activity periods and once per hour during low-activity periods. Apple’s algorithms for active calorie estimation have a reported mean absolute error of approximately 15–20% in validation studies — reasonable for general activity tracking, noisier for structured exercise sessions.

Apple’s Fitness app receives this active calorie data and displays it in the Activity rings interface. The Fitness app does not receive food intake data from any source and provides no net calorie calculation. It is an output-only view of energy expenditure, deliberately separated from dietary tracking. Closing the calorie loop — comparing intake to expenditure — requires a third-party app with HealthKit read access to activity data. CalEye performs this calculation using your logged food intake minus the active calorie data read from Apple Watch via HealthKit.

The combination — Apple Watch for expenditure data, CalEye for intake data, HealthKit as the exchange layer — is more complete than either provides independently. Apple’s own ecosystem deliberately leaves the intake half to third-party apps, reflecting both a design philosophy (Apple health features focus on output and biometrics) and a practical acknowledgment that food identification requires specialized databases and computer vision that Apple has not built natively into the Health platform.

Verdict

Apple Health is infrastructure; CalEye is the tool that makes the infrastructure meaningful for nutrition tracking. On iOS, CalEye’s HealthKit integration is complete and bidirectional for supported data types. The combination gives you:

• Photo-based meal logging with GL data in CalEye
• Macro and calorie records in Apple Health for sharing with connected apps and clinicians
• Activity data from Apple Watch feeding back into CalEye’s net calorie calculation

There is no functional conflict. If you use iOS and are considering CalEye, granting HealthKit permissions is a two-tap decision that makes both apps more useful.

References

1. Apple Inc. HealthKit Framework Reference. developer.apple.com/healthkit. Accessed 2026.
2. Dexcom CGM HealthKit integration documentation. dexcom.com. Accessed 2026.
3. Abbott FreeStyle LibreLink iOS app — HealthKit data types. Abbott Diabetes Care, 2025.