When a Diet App Logs Meals but Apple Health and Health Connect Stay Empty

The fastest way to fix a nutrition app that logs meals but never pushes them into the phone's health platform is to stop treating the connection as one switch. It is two switches, and on both iOS and Android they are set separately, per data category. Almost every "connected but nothing appears" report comes down to one of those two switches being off while the app's own settings screen still says the integration is enabled.

Work through this order before touching anything else:

1. Open the platform's own permission screen — not the diet app's — and confirm the write permission for the nutrition category is on.
2. In the same screen, confirm the read permission for whatever the app pulls back (activity, weight, workouts) is on as a separate item.
3. Log one new meal after doing the above, then check the platform. Do not judge the fix by whether old entries appear — on Android they are governed by a different rule entirely, covered below.

The rest of this article explains where each of those steps can fail, using only behaviour that Apple and Google document publicly.

The grant runs in one direction at a time

Apple states the model plainly in its HealthKit documentation: "HealthKit requires fine-grain authorization. You need to request permission to both read and share each data type before your app attempts to use the data." Sharing, in Apple's vocabulary, means writing into the store. Reading is a separate request, and the two are not bundled.

Health Connect works the same way on Android. Every data type carries a matched pair of permission strings. For meals and macros the type is NutritionRecord, and the two permissions are android.permission.health.READ_NUTRITION and android.permission.health.WRITE_NUTRITION. Granting one does nothing for the other.

This matters for troubleshooting because the failure is asymmetric. A missing write permission means meals never leave the app. A missing read permission means the app shows an empty dashboard while the platform is full. Those look like the same complaint — "it isn't syncing" — and they have opposite fixes.

On iPhone: the Health app decides, not the diet app

Apple's support instructions for reviewing app access are short and specific. Open the Health app, tap the profile picture in the upper corner, then under Privacy tap Apps. That lists the compatible apps that have requested access. Tapping one shows the health categories, each with its own toggle.

Two details from that screen are worth knowing before assuming a bug:

• Apple's developer documentation notes that "after prompting for HealthKit authorization, your app appears in the Health app's Sources tab, even if the person didn't allow permission to read and share data." The app being listed proves only that it asked. It is not evidence that anything was granted.
• Apple's own support wording adds a step people skip: "You might need to open the app and adjust its settings to allow it to share data with Health." Permission at the system level and the integration toggle inside the diet app are two different flags, and both have to be set.

Why the app can look connected and still show nothing

This is the part that makes iOS troubleshooting counter-intuitive, and it is deliberate policy rather than a defect. Apple's privacy documentation states: "To prevent possible information leaks, an app isn't aware when the user denies permission to read data. From the app's point of view, no data of that type exists."

The authorization article repeats it in stronger terms: "your app doesn't know whether someone granted or denied permission to read data from HealthKit. If they denied permission, attempts to read data from HealthKit return only samples that your app successfully saved to the HealthKit store."

The practical consequences are worth stating flatly. A diet app cannot display an accurate "read access denied" warning on iOS, because it is not told. Any app that appears to do so is inferring it from an empty result, which is a guess. And a support agent asking whether the app reports an error is asking a question the platform makes unanswerable. The only reliable check is the Health app's own toggle list.

There is one narrow exception. Apple added a second permission screen that lets a person grant either a recent window of history or their full history, and an app can call getEarliestAuthorizedSampleDate(for:) to learn the earliest date it may read. Apple describes the boundary precisely: "HealthKit intentionally prevents your app from distinguishing between full access and denied access to specific types; both cases return no entry in the result dictionary. Limited authorization is the only authorization state your app can positively identify."

Writing is different — and it does produce errors

Writes are not silent. Apple documents that an attempt to save before permission has been requested fails with HKError.Code.errorAuthorizationNotDetermined, and an attempt to save after permission was refused fails with HKError.Code.errorAuthorizationDenied. So when a diet app does surface a specific sync error on iOS, it is far more likely to concern writing meals out than reading anything back.

A locked iPhone can stall reads but not writes

One more documented behaviour explains sync that catches up only after the phone is picked up. Apple states that the device encrypts the HealthKit store when locked, and as a result an app "may not be able to read data from the store when it runs in the background. However, your app can still write to the store, even when the phone is locked. HealthKit temporarily caches the data and saves it to the encrypted store as soon as the user unlocks the phone."

If figures land correctly but arrive in a clump minutes after the phone is unlocked, that is the documented design, not a broken connection.

On Android: check Health Connect, not Google Fit

A large share of stale advice still tells Android users to reconnect a diet app to Google Fit. That target is being retired. Google's own developer page for Fit carries the notice: "The Google Fit APIs, including the Google Fit REST API, will be deprecated in 2026. As of May 1, 2024, developers cannot sign up to use these APIs." The Health Connect documentation restates the deadline from the other side — "Google Fit APIs will be supported until the end of 2026" — and points developers to a migration guide.

The replacement is Health Connect, which Google documents as compatible with "Android SDK version 28 (Pie) and higher." Where it lives depends on the release:

• Android 14 and later. Health Connect is part of the system. Google's user instructions give the path as Settings ▸ Security and privacy ▸ Privacy controls ▸ Health Connect. Manufacturer skins rename these menus, so search the Settings search box for "Health Connect" if the labels do not match.
• Android 13 and earlier. Health Connect is a separate app from the Play Store. Google's instructions are to install it, then reach it through Settings ▸ Apps ▸ All apps ▸ Health Connect ▸ Open.

Inside Health Connect, apps are listed with their own permission sheets. Google's user guidance describes the flow as turning on the apps to sync, selecting the data permissions to share, and tapping Allow. Nutrition sits in its own category, with the read and write entries listed separately as described earlier.

Practical implication: if a diet app's settings screen still offers "Connect to Google Fit" as its only option, the integration is aimed at a platform on a published retirement path. Check whether the app also offers Health Connect, and prefer it.

The 30-day rule behind "the old entries never came across"

This one produces more confusion than any permission toggle, because the connection genuinely works and the history still does not appear.

Google's developer documentation states the default: "By default, all applications can read data from Health Connect for up to 30 days prior to when any permission was first granted." Google's user-facing help describes the same boundary from the other direction — a connected app "can access data from the last 30 days and any new data written after that," and notes that "the 30-day limit doesn't apply to health records."

Reaching further back requires an additional permission, android.permission.health.READ_HEALTH_DATA_HISTORY. Google is explicit about what happens without it: "without this permission, an attempt to read records older than 30 days results in an error."

There is a version split on top of that. Google documents that on Android 14 and higher there is "no historical limit on an app reading its own data" but a "30-day limit on an app reading other data," while on Android 13 and lower the 30-day limit applies to reading any data.

So a freshly connected app on an Android 13 phone showing only the past month of another app's data is behaving exactly as documented. Re-granting permission does not widen the window retroactively; the window is anchored to when permission was first granted.

Reinstalling clears the grant — and so does not opening the app

"Delete and reinstall" is the standard advice for a stuck app, and it is unusually disruptive here because it discards the permission state.

Google's Health Connect documentation acknowledges the reinstall case directly, noting that an app that previously wrote records can read them back, and that this applies "for scenarios in which the app needs to resync with Health Connect after the user has reinstalled it." That recovery path exists precisely because reinstalling breaks the connection.

Separately, Android resets permissions for apps that sit idle. Google documents that for apps targeting Android 11 (API level 30) or higher, if a person does not interact with the app "for a few months," the system places it in hibernation and its runtime permissions are reset — with the same effect as the person setting access to Deny. Google is explicit that this is not undone automatically: when the app leaves hibernation the system does not "re-grant your app's runtime permissions. The user must re-grant these permissions for your app."

A diet app used heavily in January, ignored through spring, and reopened in the summer can therefore have lost its Health Connect access without anything visibly changing. On iOS the equivalent point is Apple's statement that a person "can change the permissions for your app at any time using either the Settings or Health app," so the toggle list is always the authority, whatever the app remembers.

What the documentation does not settle

Being honest about the limits keeps this from turning into guesswork:

• How often a given commercial diet app syncs. Third-party apps do not generally publish an interval, and inventing one would be worthless. Treat "log a new entry and check within a few minutes" as the test, not a claimed schedule.
• How Apple Health picks a winner when two apps write the same figure. The Health app groups contributors under Sources, but HKSource — the object that identifies which app or device wrote a sample — exposes only a bundle identifier and a name. There is no public priority value for a third-party app to read or set, so any claim about a fixed ranking rule is not verifiable from Apple's published API.
• The exact idle period before Android hibernation. Google says "a few months" and does not publish a number.
• Menu wording on non-Pixel Android phones. The paths above are Google's wording. Manufacturer skins relabel and reorder Settings, so use the Settings search field rather than assuming the path is missing.

When This Doesn't Apply

This diagnosis is about permissions and platform read windows. It does not fit these situations:

• The account, not the phone, is the link. Some nutrition services sync through their own server account rather than the on-device health store. If the data has to travel between two phones, or appears on the web dashboard but not the phone, the problem is account-side and no permission toggle will move it.
• The platform itself is unavailable. Apple's framework requires a check that health data is available on the device at all; Health Connect on Android 13 and earlier is an installable app that may simply not be present. On such devices there is nothing to grant permission to yet.
• The app never integrated in the first place. Plenty of food-logging apps have no HealthKit or Health Connect integration. If the app has no health-platform screen in its own settings, the phone's permission list will never show it, because Apple's documentation notes an app appears in the Sources list only after it has prompted for authorization.
• Only nutrition is missing while everything else flows. That points at the category toggle for nutrition specifically, not the connection. Both platforms treat nutrition as its own type with its own pair of permissions.
• Android with a shared or work profile. Managed profiles apply their own policy layer to permissions, and this walkthrough assumes a single personal profile.

Concrete framework

1. Identify the platform, not the brand. On Android, confirm the app offers Health Connect. If it offers only Google Fit, note that Google's own page states the Fit APIs will be deprecated in 2026 and closed to new developer signups since 1 May 2024.
2. Open the platform's permission list. iOS: Health ▸ profile picture ▸ Privacy ▸ Apps ▸ the app. Android 14+: Settings ▸ Security and privacy ▸ Privacy controls ▸ Health Connect. Android 13 and earlier: the Health Connect app from the Play Store.
3. Read the two columns separately. Confirm write for nutrition and read for whatever the app displays back. Do not assume one implies the other.
4. Set the matching toggle inside the diet app. Apple explicitly warns that the app's own sharing setting may still need to be enabled.
5. Test with a new entry only. Log one item, unlock the phone, and wait. On iOS a locked device can defer reads while still accepting writes.
6. Judge history separately. On Android, missing entries older than 30 days are the documented default, not a fault. Reaching further back requires READ_HEALTH_DATA_HISTORY, which is the app developer's decision, not a user setting.
7. Treat reinstalling as a last resort. It resets the grant and, on Android 13 and earlier, restarts the 30-day read window from the new grant date.
8. If reads still fail on iOS, do not wait for an error message. The platform is designed never to produce one. Verify by toggling the category off and on in the Health app and re-testing.

Two switches, per category, on the platform's screen rather than the app's — that single distinction resolves the majority of these cases, and the 30-day window explains most of the rest.