SensorKit
Choose the exact SRSensor and verify its individual availability. Use
CoreMotion for ordinary motion/activity features and HealthKit for health
records and workouts.
Contents
- Overview and Requirements
- Entitlements
- Info.plist Configuration
- Authorization
- Available Sensors
- SRSensorReader
- Recording and Fetching Data
- SRDevice
- Common Mistakes
- Review Checklist
- References
Overview and Requirements
SensorKit enables research apps to record and fetch sensor data across iPhone and Apple Watch. The framework requires:
- Apple-approved research study -- submit a proposal at researchandcare.org.
- SensorKit entitlement -- Apple grants
com.apple.developer.sensorkit.reader.allowonly for approved studies. - Manual provisioning profile -- Xcode requires an explicit App ID with the SensorKit capability enabled.
- User authorization -- the system presents a Research Sensor & Usage Data sheet that users approve per-sensor.
- Delayed retrieval -- design fetch timing around the canonical Data Holding Period.
An app can access up to 7 days of prior recorded data for an active sensor.
Entitlements
Add the SensorKit reader entitlement to a .entitlements file. List only the
sensors Apple approved for the study. Common entitlement values include:
Load the Entitlement and Usage-Detail Catalog [blocked]
when selecting the exact entitlement string and NSSensorKitUsageDetail key
for each approved sensor. Recheck specialized sensors against their individual
SRSensor pages.
For manual signing, set Code Signing Entitlements to the entitlements file,
Code Signing Identity to Apple Developer, Code Signing Style to Manual,
and Provisioning Profile to the explicit profile with SensorKit capability.
Info.plist Configuration
Three keys are required:
If Required is true and the user denies that sensor, the system warns them
that the study needs it and offers a chance to reconsider.
Use the exact usage-detail dictionary for each requested sensor. Load the Entitlement and Usage-Detail Catalog [blocked] when mapping sensors beyond the motion and ambient-light examples above.
Authorization
Request authorization for the sensors your study needs. The system shows the Research Sensor & Usage Data sheet on first request.
Use one status handler both for the initial check and delegate changes:
Available Sensors
Load the Sensor Catalog [blocked] to map
each SRSensor to its sample type. Request only sensors approved for the study
and recheck the selected sensor's availability and usage-detail key.
SRSensorReader
SRSensorReader is the central class for accessing sensor data. Each instance
reads from a single sensor.
The reader communicates through SRSensorReaderDelegate. Load the
Delegate Method Catalog [blocked]
when wiring the complete authorization, recording, device-fetch, and
sample-fetch lifecycle.
Recording and Fetching Data
Start and Stop Recording
Fetch Data
Build an SRFetchRequest with a time range and target device, then pass it to
the reader:
Receive results through the delegate:
Cast result.sample to the sample shape for the reader's sensor. Some streams
return one object per result, while recorded motion, ECG, PPG, and ambient
pressure streams can return arrays of recorded samples.
Data Holding Period
SensorKit imposes a 24-hour holding period on newly recorded data. Fetch requests whose time range overlaps this period return no results. Design data collection workflows around this delay.
SRDevice
SRDevice identifies the hardware source for sensor samples. Use it to
distinguish data from iPhone versus Apple Watch.
Handle fetched devices through the delegate:
SRDevice Properties
Common Mistakes
DON'T: Attempt to use SensorKit without the entitlement
Obtain Apple's study approval, the sensor-specific entitlement values, and a matching manual provisioning profile before constructing production readers.
DON'T: Expect immediate data access
Apply the Data Holding Period; a fetch overlapping the hold is not proof that recording failed.
DON'T: Forget to set the delegate before fetching
Assign the delegate before startRecording() or fetch(_:); results and
failures arrive through delegate callbacks.
DON'T: Skip per-sensor Info.plist usage detail
Add the exact Info.plist Configuration usage-detail entry for every requested sensor.
DON'T: Ignore SRError codes
Distinguish at least .invalidEntitlement, .noAuthorization,
.dataInaccessible, .fetchRequestInvalid, .promptDeclined, and unknown
future codes. Load the Full Delegate Implementation [blocked]
for the complete switch and callback wiring.
Review Checklist
- Apple-approved research study in place before development
-
com.apple.developer.sensorkit.reader.allowentitlement lists only needed sensors - Manual provisioning profile with explicit App ID and SensorKit capability
-
NSSensorKitUsageDescriptionin Info.plist with clear study purpose -
NSSensorKitPrivacyPolicyURLin Info.plist with valid privacy policy URL -
NSSensorKitUsageDetailentries for every requested sensor -
Requiredkey set appropriately for essential vs. optional sensors - Authorization requested before recording, status checked before fetching
- Delegate assigned before calling
startRecording()orfetch(_:) - Fetch request time ranges account for 24-hour data holding period
-
SRErrorcodes handled in all failure delegate methods -
fetchDevices()used to discover available devices before fetching -
stopRecording()called when data collection is complete -
sensorReader(_:fetching:didFetchResult:)returnstrueto continue orfalseto stop
References
- Extended patterns (delegate wiring, multi-sensor manager, sample type details): references/sensorkit-patterns.md [blocked]
- SensorKit framework
- SRSensorReader
- SRSensor
- SRDevice
- SRFetchRequest
- Configuring your project for sensor reading
- com.apple.developer.sensorkit.reader.allow
