Guidance on HealthKit data storage/sharing practices for App Review (Guideline 5.1.1 / 5.1.3)

Hi all,

I'm preparing to submit a watchOS app that only reads HealthKit heart rate data (HKQuantityTypeIdentifierHeartRate) and I want to make sure my storage and sharing practices won't trigger a rejection under Guidelines 5.1.1 (Data Collection and Storage) and 5.1.3 (Health and Health Research).

Some specifics about my app: it's an Apple Watch app that reads heart rate only via HealthKit. Data is stored locally on the device first, then uploaded to my own backend server. It's not shared with any third parties (no analytics/ad SDKs touch this data). The uploaded heart rate data is displayed back to the user in a front-end heart rate viewer.

My questions:

Does uploading HealthKit heart rate data from local storage to my own backend server automatically raise review scrutiny, or is it acceptable as long as it's disclosed in the privacy policy and App Privacy Nutrition Label?

Since I'm not sharing data with any third parties, does that satisfy Guideline 5.1.3's restriction on using HealthKit data for advertising or data-mining, or are there other requirements around server-side storage of health data specifically (e.g., encryption at rest/in transit, retention limits)?

Is there a preferred way to document this data flow (device to backend) in the app submission, such as App Privacy details, HealthKit usage description, or Health & Fitness disclosures, that reviewers specifically look for to avoid a rejection or follow-up request?

Has anyone had a watchOS app rejected for HealthKit-related data practices recently, and if so, what was the specific issue and how did you resolve it?

I've read the Health & Fitness guidelines and the HealthKit documentation, but I'd appreciate real-world experience from anyone who has shipped a similar app, especially around what reviewers actually flag in practice.

Thanks in advance.

Guidance on HealthKit data storage/sharing practices for App Review (Guideline 5.1.1 / 5.1.3)
 
 
Q