---
title: "HealthKit errorHealthDataUnavailable: The Device Does Not Support HealthKit"
canonical: "https://aifitnessapi.com/fix/healthkit-health-data-unavailable"
cluster: "Troubleshooting"
primary_query: "healthkit errorhealthdataunavailable"
last_reviewed: "2026-09-04"
description: "Apple says to verify HealthKit support before calling any other method. Why the check belongs at every entry point, and how to degrade instead of erroring."
publisher: "AIFitnessAPI — independent, not sponsored"
cite_as: "\"HealthKit errorHealthDataUnavailable: The Device Does Not Support HealthKit\", AIFitnessAPI, https://aifitnessapi.com/fix/healthkit-health-data-unavailable"
---

# HealthKit errorHealthDataUnavailable: The Device Does Not Support HealthKit

> Apple's documentation states that errorHealthDataUnavailable means the user accessed HealthKit on an unsupported device. Apple's discussion tells you to verify that the current device supports HealthKit before calling any other HealthKit method, because iOS apps can run on devices that do not support it. There is nothing to retry and nothing the user can change, so the only useful response is to detect the condition and hide the feature rather than showing an error. In practice the bug is usually coverage: the availability check exists in your launch path but not in the widget, extension, or background wake-up that actually made the call.

- Canonical: https://aifitnessapi.com/fix/healthkit-health-data-unavailable
- Last reviewed: 2026-09-04
- Publisher: AIFitnessAPI (https://aifitnessapi.com) — independent, not sponsored
- Cite as: "HealthKit errorHealthDataUnavailable: The Device Does Not Support HealthKit", AIFitnessAPI, https://aifitnessapi.com/fix/healthkit-health-data-unavailable

---

Every HealthKit call in your app is failing on one tester's device with `errorHealthDataUnavailable`, and working perfectly on yours. This is not a permissions problem, a signing problem, or a race. Apple's abstract for the case is a single sentence: "The user accessed HealthKit on an unsupported device." The device cannot do HealthKit at all, and no amount of retrying, re-requesting, or reinstalling will change that.

## What Apple documents

Apple's documentation states the abstract above, and the discussion tells you both the cause and the required defence:

> Because iOS apps can run on devices that don't support HealthKit (for example, on an iPad), always verify that the current device supports HealthKit by calling [the availability check] before calling any other HealthKit methods. If HealthKit isn't available on the device, other HealthKit methods fail with an [errorHealthDataUnavailable] error.

The bracketed names are ours: Apple's page links two symbols inline, and those link labels do not survive extraction into plain text. The availability check Apple means is the store's `HKHealthStore.isHealthDataAvailable()`, which is the same guard used in our [HealthKit no data](/fix/healthkit-no-data) walkthrough.

Note precisely what Apple's instruction says, because it is stronger than most teams implement: verify **before calling any other HealthKit methods**. Not before your first query. Not once at launch. Before any of them.

On the iPad point, keep to what the text supports. Apple's example is that iOS apps can run on devices that don't support HealthKit, and iPad is the example given. That is a statement about your app running somewhere HealthKit isn't, not a rule about any particular iPad model or release. Apple's platform list for the error case itself includes iPadOS — but that describes where the symbol exists, not where HealthKit works. Check availability at runtime and you never have to reason about which hardware is on the other end.

## Why the check belongs at every entry point

A modern app is not one process with one launch path. HealthKit code gets reached from places that never run your launch-time warm-up:

| Entry point | Runs your launch-time check? |
| --- | --- |
| Cold app launch into your main UI | Yes |
| Widget or complication timeline reload | No |
| Background delivery wake-up | Not necessarily |
| A watch app launched on its own | No |
| A deep link straight into a detail screen | Sometimes |
| A share or intent extension | No |

Any of those can be the first HealthKit call in the process. If the guard lives only in your launch sequence, the guard is not protecting the calls that matter. Practice: put the check behind one accessor that every HealthKit path goes through, and make the unavailable result a first-class value your feature code has to handle — not an optional early return someone can forget.

## Diagnosis order

1. **Confirm the code.** Log domain and code. `errorHealthDataUnavailable` is device capability. If you are actually seeing a restriction imposed by a management profile, that is a different case with different messaging — see [HealthKit restricted by an MDM profile](/fix/healthkit-data-restricted-mdm).
2. **Check where the failing call came from.** If your app works but your widget or watch extension fails, you have a coverage problem, not a device problem.
3. **Check the target.** A Mac or a simulator target you did not intend to support will produce this class of failure long before a user ever does. Testing strategy for exactly this is in [testing a HealthKit integration](/test/healthkit-integration).
4. **Only then, believe the device.** Once the guard is genuinely universal and still reports unavailable, the answer is that this device does not do HealthKit, and your job shifts from fixing to degrading.

## Degrade, do not error

There is nothing for the user to fix here, so an error dialog is a dead end. What works, as practice:

- **Hide, don't disable.** A greyed-out Health toggle invites a support ticket. On an unsupported device, the Health integration is not a feature that is off; it is a feature that does not exist.
- **Keep the rest of the app whole.** Anything that does not depend on the store — logging a session by hand, browsing plans, camera-based tracking — should still work. An app that refuses to launch because HealthKit is missing is a self-inflicted outage.
- **Have an alternative input path.** If your product's core loop needs body or activity data, manual entry or a connected device is the fallback. Cross-platform teams usually solve this at the source layer instead, which is the shape argued in [Apple HealthKit vs Google Health Connect](/fitness-apis/apple-healthkit-vs-google-health-connect).
- **Log it once, quietly.** It is useful telemetry — how many of your installs cannot use the feature at all — and useless as an alert.

## Do not confuse it with the other silent failures

| What you see | Case | Fixable in code? |
| --- | --- | --- |
| Every HealthKit call fails on one device | `errorHealthDataUnavailable` | No — degrade the feature |
| Every call fails on a managed corporate device | `errorHealthDataRestricted` | No — explain the policy |
| Calls work, queries return empty | Not an error at all | Sometimes — check the query |
| Save fails after the user was asked | `errorAuthorizationDenied` | No — route to system settings |
| Query fails before you ever asked | `errorAuthorizationNotDetermined` | Yes — [request first](/fix/healthkit-authorization-not-determined) |

The first two of those are the pair Apple's own discussions treat as a set: both tell you to run the same availability check before calling anything else. Everything below the line is a state machine problem inside a device that supports HealthKit perfectly well.

## The watch case

Apple lists the case for watchOS too. A watch app is its own process with its own launch, so it needs its own guard rather than inheriting a conclusion the phone reached. The division of labour between the two is set out in [HealthKit on Apple Watch](/watch-apps/healthkit-on-apple-watch).

## Where to go next

The complete enum, with Apple's wording for each case and an honest marker on the cases Apple never described, is the [HealthKit error reference](/healthkit-errors). For the types you can request once you know the device supports them, use the [HealthKit identifier reference](/healthkit-identifiers). And for the setup this error assumes — capability, usage descriptions, request flow — see the [HealthKit integration guide](/integrate/healthkit).

## FAQ

### What does errorHealthDataUnavailable actually mean?

Apple's abstract states that the user accessed HealthKit on an unsupported device. It is a capability fact about the hardware or platform, not a permission decision by the person using it. No retry, reinstall, or new authorization request will change the answer, so your app should treat the Health integration as absent rather than broken on that device.

[Permalink](https://aifitnessapi.com/fix/healthkit-health-data-unavailable#faq-1)

### Where should the HealthKit availability check go?

Apple's discussion says to verify support before calling any other HealthKit method. In practice that means every entry point, not just app launch: widgets, complications, extensions, background wake-ups, deep links, and a watch app all start HealthKit work without running your onboarding. Put the check behind a single accessor that every HealthKit path has to pass through.

[Permalink](https://aifitnessapi.com/fix/healthkit-health-data-unavailable#faq-2)

### Does this error mean HealthKit never works on iPad?

Apple's discussion gives iPad as an example of a device an iOS app can run on that does not support HealthKit. That is an example, not a rule about any particular model or release, so do not hard-code assumptions about hardware. Check availability at runtime and the question never has to be answered in your code.

[Permalink](https://aifitnessapi.com/fix/healthkit-health-data-unavailable#faq-3)