HealthKit errorRequiredAuthorizationDenied: Clinical Records Are a Separate Class

Authorization succeeded in testing and fails for real users with errorRequiredAuthorizationDenied, and nothing you change in your request set seems to help. This case does not behave like the rest of HealthKit's permission model: it belongs to clinical record types, it is declared in your app's configuration rather than in the request itself, and it fails as a block rather than per type.

What Apple documents#

Apple's documentation states the abstract as: "The user hasn't granted the application authorization to access all the required clinical record types." The discussion is a single sentence:

You can specify required clinical record types using the [required-read-authorization] Info.plist key.

The bracket is ours — Apple links the key by name and that label does not survive extraction to plain text. Apple's platform list introduces the case at iOS 12.0 and watchOS 5.0, later than the original accessing errors, which matches its scope: it exists for the clinical-records feature specifically.

Read the abstract closely, because the load-bearing word is all. This is not a report that a permission was refused. It is a report that the set you declared as required was not granted in full.

Two further points are documented by Apple and quoted in our HealthKit authorization denied guide: Apple says to specify three or more types under that key, and that when authorization fails this way, "the system doesn't tell your app which record types the person denied access to". So you learn that the requirement was not met, and nothing about which part of it failed.

Why this is a separate authorization class#

Ordinary HealthKit permissions are granular and independent. Each type has its own read and share decision, a refusal on one has no effect on another, and — as covered in the authorization guide — refusals on the read side are invisible by design. Required clinical types invert several of those properties at once.

The practical consequence: this key is a hard product requirement expressed in configuration. Whatever you list there, you are declaring that your app cannot function without all of it, and the system enforces that literally.

Diagnosis order#

1. Confirm the case. errorRequiredAuthorizationDenied is not errorAuthorizationDenied and not errorAuthorizationNotDetermined. The first means a required set was incomplete; the second is a refused write; the third means you never asked, and is covered in errorAuthorizationNotDetermined. If your logging collapses them, split it before anything else.
2. Read your own declaration. Open the built app's property list and read the required-types entry as shipped, not as you remember writing it. A list assembled during the build, or inherited from a template, is the usual surprise.
3. Ask whether every entry is genuinely required. This is the real question. Each type you list is another chance for a single refusal to fail the entire authorization for that user.
4. Check Apple's minimum for the key. Per the guidance quoted above, Apple says to specify three or more types.
5. Segment your failures. If the error is concentrated among users of one health system or record source, you are looking at record availability rather than at a code defect.

Scope the requirement, then degrade around it#

The only real lever you have is what you declare. As practice:

• Declare the minimum that makes the app impossible without. If a feature is enhanced by clinical records but not defined by them, those types do not belong in the required set. Requesting them normally means a refusal costs you one feature instead of the whole session.
• Design a non-clinical path. Activity, workout, and body-measurement data flow through the ordinary model, so an app whose core loop rests on those keeps working when the clinical request fails. The types available to you are catalogued in the HealthKit identifier reference.
• Explain, then stop. There is no API to change a permission on someone's behalf, and Apple states you are not told which type was refused, so your message can only be general: the app needs access to all of the requested health records, and that choice is made in the system permission flow. Do not name a specific record type you cannot know was the problem.
• Do not re-prompt in a loop. Once decisions have been made, re-requesting does not re-present the sheet — the documented behaviour is quoted in the authorization denied guide. A button that appears to do nothing is worse than a sentence of explanation.
• Do not infer content from the failure. The error tells you a permission set was incomplete. It tells you nothing about what any record contains, and nothing about the person. Treat the outcome as an access-control fact, full stop.

Handling the data you do get#

Clinical records raise handling questions that ordinary step counts do not. Before you ship, be clear on whether your handling of this data falls under health-privacy rules in your jurisdiction and what your obligations are — the starting points are is fitness data PHI? and HIPAA compliance for a fitness app, and the store-review dimension is in App Store health data rules. Those are engineering and policy questions, not clinical ones; nothing on this page is medical or legal advice.

Symptom to action#

Where to go next#

The full enum with Apple's own wording is in the HealthKit error reference, the permission model this case departs from is in HealthKit authorization denied, and the surrounding setup is in the HealthKit integration guide.