HealthKit，核心数据和CloudKit

Question

I am building a fitness app with HealthKit integration. Ultimately I would like to use CloudKit as well to a) allow data redundancy, but mainly b) to provide a few social features which require data to be in iCloud at least temporarily.

I would like to be able to rely solely on HealthKit for data within the app, but feel that an alternate data model is necessary to persist data incase HealthKit permissions are revoked or not given in the first place. I have chosen to stick with Core Data for this.

My question is how do I go about keeping my Core Data store and my HealthKit store in sync. I have searched for an example on GitHub and for related questions on here, but cannot find any useful examples.

Ultimately I will be then syncing the data in Core Data with CloudKit, but is the Core Data intermediary really necessary?

With regards to App Store Review Guidelines 27.3

Apps using the HealthKit framework that store users' health information in iCloud will be rejected

I take this to mean that any Health data which was not created by your app cannot be stored in iCloud. There are many apps which store Health data on a third party server (ie RunKeeper). Also, without HealthKit permissions I would be allowed to store health data created by my app in iCloud. If you take third party data from HealthKit and try to put that in iCloud, then you'll be rejected.

Answer 1

There's a couple questions in here, so I'll try to answer them in order.

...how do I go about keeping my Core Data store and my HealthKit store in sync?

So there are two application modes you need to worry about for getting data updates: foreground and background.

When in the foreground, you can utilize HKObserverQuery which provides a decent amount of flexibility in getting the data you need. The usual caveats apply when passing data across thread boundaries (as observer queries run on background queues). Pertinent docs: HKObserverQuery Docs

In the background you have to register for background wakeup using enableBackgroundDeliveryForType(_:frequency:withCompletion:) . This will wake your application at (or close to) the specified frequency, at which point you'll need to jump through whatever necessary hoops to load your Core Data stack and do your updates. Pertinent Docs: HKHealthStore Background Handling Docs

...is the Core Data intermediary really necessary?

No, and in fact using Core Data may be complete overkill for your uses. I generally recommend against implementing Core Data at the outset of an application. There are performance concerns, background wake concerns, schema migration concerns when you change schemas, and iCloud <> Core Data synchronization issues (most of which have been resolved as of iOS 9 but still crop up occasionally).

On top of all that, Apple's "template" for including Core Data in a new project generally doesn't follow best practice guidelines for integrating Core Data. Do some Google searches and take a look at Marcus Zarra's books on the subject.

That all said, not using Core Data means having to write a bunch more code to enable iCloud to synchronize with your data store of choice, so it's tough to offer a suggestion as to the "correct" route to take.

I take this to mean that any Health data which was not created by your app cannot be stored in iCloud.

Incorrect. Take the line at face value. If Apple sees you've requested access to HealthKit and have provisioned iCloud access, you're probably going to get scrutinized and most likely rejected. They are very touchy about user privacy in this regard, and correctly so in my opinion.

Your note about Runkeeper, while accurate, is also flawed as Runkeeper (last I checked) does not use iCloud and so wouldn't be subject to this, so the analogy is flawed. Also, as per Apple's other guidelines, whatever other apps do or don't do has no bearing on your application's review status.

In short, I would steer clear of storing users' health data in iCloud. Use another provider or your own server.