CareKit: Apple's Swift framework for patient-facing health apps

The gap CareKit fills for patient-facing iOS apps

A health app usually needs the same handful of screens: a task list for today, a chart of a measurement over time, a contact list for a care team. Each of those screens needs to read from a local database, stay in sync with it as the user records new values, and render consistently in light and dark mode. Building that from scratch in UIKit means writing a persistence layer, a query layer, and a binding layer before you write anything specific to your study or your clinic.

CareKit targets exactly that layer. The README describes it as a framework for creating apps that help people better understand and manage their health, and it splits the work into three Swift packages that can be imported separately. The audience is iOS developers working on research studies, clinical programs, or personal health tracking, not end users. If you are not writing Swift against UIKit, nothing here applies to you.

Three packages, and the Combine layer that connects them

The architecture is a stack. CareKitUI supplies the views as open subclasses of UIView with public properties, so you can restyle or subclass them. CareKitStore supplies a Core Data backed store for patient data, and the README notes it also allows a custom store, such as a third party database or API. CareKit sits on top and provides view controllers that tie the two together.

The connection mechanism is Combine. The README states that the view controllers leverage Combine to provide synchronization between the store and the views. Concretely, each card in CareKitUI has a matching view controller in CareKit, and that view controller owns a view synchronizer. The synchronizer knows how to instantiate the view and how to update it when the store changes. The README gives the example of subclassing OCKSimpleTaskViewSynchronizer and overriding makeView() and updateView(_:context:) to customize both ends of that cycle.

That split is the interesting design decision. Because the synchronizer is a separate object you can inject, you can change how a card behaves without touching the view controller or the store. The cost is more types to learn before the first screen renders.

Installing CareKit with Swift Package Manager

The README lists two installation routes. The first is Swift Package Manager: create a new Xcode project, then use File > Swift Packages > Add Package Dependency and enter the repository URL, choosing the main branch and checking off the packages you need. The second is to download the source and drag CareKit.xcodeproj, CareKitUI.xcodeproj and CareKitStore.xcodeproj into your workspace, then embed each framework in the Embedded Binaries section of your target.

The README states the primary framework codebase supports iOS and requires Xcode 12.0 or newer, with a Base SDK version of 13.0. The repository's own badge, by contrast, reads Xcode 16.3+, so check which of the two your project actually needs before you pin a toolchain.

Once the package is linked, the README's own snippet shows the smallest useful setup: create an on-disk store, then hand it to a synchronized view controller that queries a single task for today.

// Create a store to hold your data.
let store = OCKStore(named: "my-store", type: .onDisk)

// Create a view controller that queries for and displays data. The view will update automatically whenever the data in the store changes.
let viewController = OCKSimpleTaskViewController(taskID: "doxylamine", eventQuery: OCKEventQuery(for: Date()), store: store)

What you should see is a view controller that renders the task identified by that task ID and refreshes itself when the underlying store changes. If the store is empty, there is no data to show, so the next step is populating it through CareKitStore rather than adjusting the view controller.

For localization, the README points at the English strings file under CareKitUI and says to add that strings file to your project.

Where CareKit stops and you have to start

The README is explicit that CareKitStore provides the ability to use a custom store, such as a third party database or API. That is a capability, not a service. There is no hosted sync, no account system, and no server component described in the repository. If your study needs data to leave the device, you are implementing the store conformance yourself.

The same applies to the schema. CareKitStore ships a Core Data solution with a defined schema and scheduling model, and the README links to documentation for both. If your data does not resemble tasks, events and contacts, you will be fighting the model rather than using it. A symptom diary or a medication schedule fits. A chat-based coaching product does not.

Platform is the other hard boundary. The README describes the primary framework codebase as supporting iOS. There is no Android, web or server story here. An app that needs a companion web portal for clinicians is two products, and CareKit only helps with one of them.

How CareKit compares to ResearchKit

ResearchKit appears in the README only as a WWDC session title, ResearchKit and CareKit Reimagined, and in the related searches alongside CareKit. The two are aimed at different halves of the same problem. ResearchKit is built around collecting structured measurements from participants, the kind of active tasks and surveys a study runs. CareKit is built around the participant's ongoing care: tasks they perform, values they record, contacts they keep.

The difference shows up in the data model. CareKitStore is organized around tasks, events and contacts with a scheduling layer, which is what you need for a daily routine that repeats. If your requirement is a one-off survey instrument with validated scales, ResearchKit's model is closer to the shape of that problem, and CareKit's synchronized card views are not the part you need. Some projects use both, with one framework handling the study protocol and the other handling the care plan.

Maintenance, releases and the licence question

The last push to the default branch was on 2026-04-03, and the most recent release listed is 4.1.0 on the same date. Before that, 4.0.0 landed on 2025-10-31 and 3.1.7 on 2025-05-13. The repository is not archived. The gap between 3.1.7 and 4.0.0 is roughly five months, and 4.0.0 to 4.1.0 is another five, so major-version upgrades have arrived on a slow cadence that a team can plan around.

Upgrade cost is dominated by the major versions. A 4.x release is where a framework like this is most likely to change the store schema or the view controller APIs, and both of those touch your code directly. The README does not document a migration path between store schemas, so budget time for reading RELEASE-NOTES.md before moving a shipped app across a major version.

The licence is the part to read carefully. The README badge reads BSD, but the repository's licence field is recorded as NOASSERTION, which means the licence could not be classified automatically. Apple frameworks of this kind commonly carry an added patent grant or attribution clause beyond plain BSD. Read the LICENSE file in the repository root before you ship, and get your own legal review rather than relying on the badge.

Editorial conclusion

Adopt CareKit if you are building a native iOS app whose users record symptoms, tasks or contacts over time, and you are willing to supply your own sync backend. Do not adopt it for Android, for a web dashboard, or if you need a hosted service out of the box, because the framework is client-side Swift only. Before writing feature code, verify the Xcode and Base SDK versions your toolchain reports against the README's stated requirements, check whether the main branch or a tagged release is the right dependency for your project, and confirm that the OCKStore schema can express your data model.

Frequently asked questions

Official sources

1. carekit-apple/CareKit on GitHub
2. Issues
3. Project website
4. README
5. Releases