Hello Apple Developer Relations and the HealthKit team, I'm a hobbyist developer and recreational swimmer building a personal app to make better use of my own Apple Watch workout data. My goal is training management, post-workout reviews, and long-term summaries of my swimming history. Design goal I would like to create a global map of places where I have swum, similar to the map view in Apple Photos: When zoomed out, group locations by country or region and show the number of distinct swimming places, rather than the number of workouts. When zoomed in, reveal individual places and their associated workouts. Venue or water-body names could be added later where they can be reliably identified. For pool swimming, a single location point is sufficient. A route is not required. For open-water swimming, show the place first, then reveal an individual workout's route when selected. Group repeated visits to the same place while retaining each workout for review. Data requirement The key requirement is read-only access to a location associated with an existing workout, including historical pool workouts recorded using Apple's Workout app. A coordinate linked to the workout would be enough to begin with; I am not expecting HealthKit to identify or name the venue. What I have observed In on-device tests, I can read routes for open-water swimming workouts. For the historical pool workouts I checked, no route was returned, and I did not find usable location coordinates in the public workout, activity, event, or route metadata I inspected. However, Apple Fitness displays a map point for historical pool workouts. The absence of a route therefore does not establish the absence of a recorded location. I have read the DTS response explaining that there is currently no public API for third-party access to indoor workout locations: https://developer.apple.com/forums/thread/827939 Current obstacle Without a supported way to obtain these historical points, the app cannot automatically build a useful map of past pool visits. Recording locations from now on or asking users to assign old workouts manually would not recover the existing history. A computer-backup extraction workflow also would not meet the intended standalone iPhone app experience. Questions and enhancement request Beyond the current HealthKit APIs, is there any supported, user-initiated export or import path that preserves historical indoor workout coordinates and their association with the workout? If there is no supported path today, could Apple consider read-only access to historical workout locations through HealthKit, with explicit user authorization and clear handling of missing or approximate locations? I understand that a formal enhancement request belongs in Feedback Assistant. I am sharing this concrete design and data requirement here to clarify the use case and ask whether a supported alternative already exists. Thank you for considering this request.

After updating my Apple Watch Series 10 to the public release of watchOS 27, Environmental Sound Level measurements became extremely sparse. Before watchOS 27, with Environmental Sound Measurements enabled, my watch recorded environmental sound data approximately every 30 seconds and the coverage was nearly continuous throughout the day. After updating the same Apple Watch to watchOS 27, the behavior changed significantly: Environmental Sound Level samples are much less frequent Large gaps appear between measurements Overall daily temporal coverage is dramatically reduced The same change is visible both in the Health app and through HealthKit using HKQuantityTypeIdentifier.environmentalAudioExposure No relevant settings were changed, and Environmental Sound Measurements are still enabled. This is important for apps that use Environmental Audio Exposure data for time-based analysis. In my case, I use this data for sleep and nap environment analysis. With the much sparser sampling on watchOS 27, it is difficult to reliably evaluate the acoustic environment during a specific sleep period. I have also seen other watchOS 27 users reporting similar behavior: https://www.reddit.com/r/watchOSBeta/comments/1wjrdaq/watchos_27_broke_the_noise_monitoring_app/ I submitted a Feedback Assistant report: FB24837491 Has anyone else observed the same change on watchOS 27? I’m especially interested in whether this is: an intentional change to the sampling or aggregation strategy, a HealthKit write-frequency change, or a regression in watchOS 27. If anyone has compared HKQuantitySample.startDate, endDate, sample duration, and sample interval before and after the watchOS 27 update, that data would be very useful for comparison.

We depend on the Export PDF button in previous Apple Health apps and it seems to have disappeared in 27.2 beta. Merging FHIR results from multiple hospitals, pharmacies and other patient portals is complex. Apple does an excellent job of merging, categorizing, and displaying this information in the app and it used to generate a great human-readable PDF export. Exporting individual categories as a PDF would be fussy and unreliable for a typical user. Is this regression in the beta an oversight or a strategic shift on the part of Apple to deprive users of an easy to use combined patient summary?

Filed as FB24834050. Still reproducible on watchOS 27.0.1 (24R365). Posting here in case an Apple engineer can help route it, and to see whether other developers are seeing the same behavior through HealthKit. Minimal reproduction (under 3 minutes, no distance involved) Apple Watch Series 10 (GPS) running watchOS 27.0.1 (24R365), paired to an iPhone 15 running iOS 27. Start an Other workout. Move your arms continuously for about 2 minutes (I use air punches). No treadmill, GPS, or distance calculation involved. End the workout and review the heart rate samples. Result: One heart rate sample at approximately 0:05, then no additional samples for the rest of the workout. Expected: Continuous heart rate sampling every few seconds, which is how the same watch behaved on watchOS 26. This reproduces 100% of the time across every workout type I've tried since updating to watchOS 27.0. It did not occur on watchOS 26 using the same watch, same wrist, and same fit. Key diagnostic: the sensor is working, the workout session path is not. The Heart Rate app reads immediately and continues updating every few seconds, even while a workout is running. Background heart rate sampling outside workout sessions works normally. Active energy for my daily 65-minute session is accurate when no workout is started (405 calories on 9/22/26, consistent with watchOS 26). Recording that same session as an Indoor Walk workout results in roughly half the active calories (typically 185-200 versus high-300s/low-400s before the update). Starting a workout appears to suppress a working measurement path and replace it with one that is failing. Downstream impact A 1:06:13 session has been credited as 9, 35, and 55 exercise minutes on different days. Since exercise-minute credit for walking is heart-rate driven, the lack of heart rate samples appears to directly affect exercise credit. Separate issue in the same build (not the subject of this post) Indoor distance is consistently about 50% low. A 1:06:13 walk at a constant 4.1 mph should be 4.52 miles, but the watch reports roughly 2-3 miles even though step counts are correct. The watchOS 27 User Guide describes a redesigned pedometer model using new machine-learning algorithms for treadmill distance. Series 12 and Ultra 4 owners are reporting the same shortfall with matching step counts, including on clean installs, so this does not appear to be hardware-specific. The heart rate dropout reproduces in the Other workout type, which performs no distance calculation, so the two issues appear to be independent regressions. Already ruled out Health details are correct Wrist Detection enabled Power Saving Mode off on both watch and iPhone Heart Rate and Fitness Tracking permissions enabled Motion Calibration & Distance enabled Watch fit and position unchanged Both devices restarted Fitness Calibration Data reset Full unpair/re-pair Multiple workout types tested Pause/resume mid-workout (heart rate briefly shows "Searching" and then drops out again) FB24834050 includes two sysdiagnoses from watchOS 27.0 and currently shows "Recent Similar Reports: More than 10." Status remains Open with no response. Ask Can anyone from Apple confirm whether this is a known/tracked issue? Also, would a sysdiagnose captured using the watchOS logging profile from the Apple bug-reporting site be useful? I'm happy to install the profile, reproduce the issue in under three minutes, and attach fresh logs. I'm also interested in hearing from developers using HKWorkoutSession. Are you seeing the same heart-rate sample gaps on watchOS 27 in your own apps? That would help determine whether this is specific to the Workout app or a regression in the workout session layer underneath it. Thanks!

Hello, We received a customer report about intermittent missing historical step-count data when using HKStatisticsCollectionQuery on iOS 27 beta. When the query was executed on August 16, only the most recent two days—August 16 and August 15—returned correct step counts. Earlier dates returned nil from sumQuantity() and were consequently treated as zero. However, queries executed on August 14 and August 18 returned the expected data. Therefore, the problem appears to be intermittent rather than consistently reproducible. The customer confirmed that all affected historical step counts were visible in the Apple Health app, including the dates returned as zero by our query. We have not received the same type of customer report from devices running iOS 26 or earlier. Here is a simplified version of our query: guard let stepType = HKObjectType.quantityType( forIdentifier: .stepCount ) else { return } var calendar = Calendar(identifier: .gregorian) calendar.timeZone = TimeZone(identifier: "Asia/Seoul")! let queryStartDate = calendar.startOfDay(for: parsedStartDate) let tomorrow = calendar.date(byAdding: .day, value: 1, to: Date())! let queryEndDate = calendar.startOfDay(for: tomorrow) let datePredicate = HKQuery.predicateForSamples( withStart: queryStartDate, end: queryEndDate, options: .strictStartDate ) let nonUserEnteredPredicate = HKQuery.predicateForObjects( withMetadataKey: HKMetadataKeyWasUserEntered, operatorType: .notEqualTo, value: NSNumber(value: true) ) let predicate = NSCompoundPredicate( andPredicateWithSubpredicates: [ datePredicate, nonUserEnteredPredicate ] ) let anchorDate = calendar.startOfDay(for: Date()) var interval = DateComponents() interval.day = 1 let query = HKStatisticsCollectionQuery( quantityType: stepType, quantitySamplePredicate: predicate, options: .cumulativeSum, anchorDate: anchorDate, intervalComponents: interval ) query.initialResultsHandler = { _, results, error in guard let results, error == nil else { print("Query error: \(String(describing: error))") return } results.enumerateStatistics( from: queryStartDate, to: queryEndDate ) { statistics, _ in let steps = statistics .sumQuantity()? .doubleValue(for: .count()) ?? 0 print(statistics.startDate, statistics.endDate, steps) } } healthStore.execute(query) Observed behavior Query executed on August 14: historical step counts returned correctly Query executed on August 16: August 16 and August 15 returned correctly August 14 and earlier returned nil from sumQuantity() Query executed on August 18: historical step counts returned correctly again No query error was reported All step counts remained visible in the customer's Apple Health app Expected behavior The query should consistently return cumulative daily step counts when matching HealthKit samples exist and are visible in the Health app. Because this was reported through customer support, we do not currently know the exact iOS 27 beta build number. We are also unable to reproduce it consistently on our own test devices. Questions Is there a known intermittent issue with historical .stepCount queries on iOS 27 beta? Can HealthKit temporarily return incomplete statistics while data is being indexed, synchronized, or migrated? Is there a recommended way to detect that the returned statistics are temporarily incomplete? Should applications retry the query when older statistics unexpectedly return nil without an error? We have not received reports of this behavior from customers using iOS 26 or earlier. Thank you.

We are seeing inconsistent results from HKStatisticsCollectionQueryDescriptor on iOS 27. Using the same quantity type, statistics options, anchor date, interval components, and predicate configuration, some date ranges return the expected statistics, while other ranges unexpectedly return empty results or buckets with no quantity. The affected ranges do contain HealthKit samples: HKSampleQueryDescriptor finds samples in the same date range. HKStatisticsQueryDescriptor returns the expected value when run separately for an affected bucket. HKStatisticsCollectionQueryDescriptor returns no quantity for that same bucket. Slightly expanding or shifting the date range may cause the collection query to return data again. A simplified version of the query looks like this: let datePredicate = HKQuery.predicateForSamples( withStart: startDate, end: endDate, options: .strictStartDate ) let descriptor = HKStatisticsCollectionQueryDescriptor( predicate: .quantitySample( type: quantityType, predicate: datePredicate ), options: .cumulativeSum, anchorDate: anchorDate, intervalComponents: DateComponents(day: 1) ) let collection = try await descriptor.result(for: healthStore) collection.enumerateStatistics(from: startDate, to: endDate) { statistics, _ in let quantity = statistics.sumQuantity() print(statistics.startDate, quantity as Any) } Expected behavior Every interval containing matching samples should return the corresponding statistics, regardless of the overall requested date range. Actual behavior Some date ranges produce missing or empty buckets even though matching samples exist and an individual HKStatisticsQueryDescriptor can calculate the expected value. Changing only the date range can make the data appear or disappear. The samples are visible to the app in the affected range, so this does not appear to be explained solely by iOS 27’s Limited History authorization. This behavior was not observed with the same query flow on earlier iOS versions. Is this a known regression in HKStatisticsCollectionQueryDescriptor on iOS 27, or has the expected date-range or predicate behavior changed?

While attempting to read a user’s daily step history spanning backward to the last 7 days, a small but consistent subset of users encounter Error Code 3 with the underlying error description: Error Code 3 "Unable to invalidate interval: no data source available." When this error occurs, we are entirely unable to read their step history. We have received ~10 direct user reports of this within the last couple of weeks.

Health and Workout data stopped syncing from my Apple Watch to my iPhone on 21 September while both devices were on the public releases. The Watch continues recording the data and the missing data remains on the Watch. Activity Sharing also continues to work. I’ve since installed the matching iOS/watchOS developer betas in an attempt to resolve the pre-existing issue, but it remains. And now I cannot get assistance via the usual Apple Support route. I’ve submitted a Feedback Assistant report with both iOS and watchOS sysdiagnoses: FB24923176. Multiple users are also reporting this issue here - https://www.reddit.com/r/AppleWatch/comments/1whu0at/apple_watch_workoutshealth_data_stopped_syncing/ Could someone advise whether this can be reviewed by the appropriate HealthKit/watchOS team? I am deliberately avoiding unpairing the Watch because the unsynced data is currently only stored on the Watch. Thanks so much!

We are an interdisciplinary research team involving Gazipaşa Science High School and Akdeniz University in Türkiye, including student researchers, a project advisor, and a medical researcher. We are conducting a non-commercial scientific research project within the TÜBİTAK 2204-A High School Students Research Projects Competition. As part of the project, we are developing an experimental wrist-based optical monitoring system. We plan to use an Apple Watch Series 9 (A2980, Part Number MR9A3TU/A) as a comparative benchmark during the development and evaluation of our system. In particular, we are interested in accessing Apple Watch photoplethysmography (PPG) data through SensorKit. We intend to use these data to support the iterative development of our optical monitoring system and to evaluate and report how modifications to our system affect its signal characteristics and performance relative to an established commercial wearable optical sensing platform. Apple Watch measurements will be used for comparative research and system evaluation, rather than as a clinical reference or diagnostic measurement. We would therefore appreciate guidance on the appropriate procedure for obtaining SensorKit access and the required entitlement for Apple Watch PPG data for this type of scientific research. To perform a scientifically meaningful comparison, we also need reliable technical information about the optical sensing system of the Apple Watch used in our study. However, we have been unable to find an authoritative and citable Apple source specifying the wavelengths or wavelength ranges of the optical emitters used in the Apple Watch Series 9 (A2980). Could you please direct us to any official Apple documentation, publication, technical specification, or other authoritative resource containing this information? If the exact specifications are not publicly available, we would appreciate guidance on whether such information can be provided for academic research purposes. We would also appreciate recommendations for the appropriate Apple technical support channel, Developer Forum, research contact, or other point of contact for further questions that may arise during the development and research process. Thank you for your time and guidance.

I have 27.2 developer beta running on my iPhone Air and Watch Ultra 4. My wife has an 18 Pro and also Ultra 4 but hers are both running the current public release versions of iOS 27 and watchOS 27. After 2 nights with the Ultra 4's, her sleep score is reporting accurate. Mine is way off. For example, last night we went to bed around 10 PM and woke up at 7 AM. Her scores were in the 90's with 7:36 hours of sleep. Mine is in the 40's with 4:20 hours of sleep. We both slept the same/great last night. Similar results for the night before - hers is accurate; mine are way off.

iOS 27 adds a second stage to HealthKit read authorization. After picking data types, the user chooses "Past 30 Days and Future Data" or "All Recorded Data and Future Data", with Allow disabled until one is selected. Every user of every health app now makes this call, in the first seconds of onboarding, with no real context about what the app needs. I don't think the scale of this has landed yet. A meaningful share of users will pick 30 days. multi-year health trends, month to month comparisons, all-time records: with 30 days these features don't get worse, they stop existing. And it breaks silently. The user sees empty charts and a app that doesn't do what the screenshots promised. They won't connect that to a sheet they tapped through on day one — they'll connect it to the app. That's the reckoning: a wave of one-star reviews and support mail for a decision the developer never saw and can't inspect. Because we can't inspect it .authorizationStatus(for:) deliberately hides read authorization and getRequestStatusForAuthorization only says whether prompting would show UI, so a 30-day grant and a genuinely new Apple Watch user look identical from the query layer. A callback when Health permissions change for a type — even without disclosing the new state — would go a long way here. And we can't route users to the fix. UIApplication.openSettingsURLString opens the app's own Settings page, which has no Health section. The real control sits at Settings › Privacy & Security › Health › — four levels deep, unreachable from any public API. My suggestion is a URL constant scoped to the calling app, the way openNotificationSettingsURLString (iOS 15.4+) and openDefaultApplicationsSettingsURLString (iOS 18.3+) already work. But that's just my idea; if there's a better mitigation, or something already planned, I'd like to hear it. Worth saying the privacy gain looks thin either way: the app keeps all future data indefinitely, so a 30-day grant becomes a full-history grant in thirty days for anyone who keeps the app. The window limits what's readable today, not what accumulates. iOS 27 release is approaching... I think this will cause problems 😞 Filed as FB24398048 and FB24398031

I have a watchOS app that records workouts on a piece of Bluetooth LE fitness equipment. It runs an HKWorkoutSession and, for the length of that session, stays connected to the machine and subscribed to a characteristic that reports step data once a second. Each notification is recorded into the workout's HKLiveWorkoutBuilder. The connection needs to last as long as the workout — typically 20–60 minutes. The watch app declares both: WKBackgroundModes = workout-processing UIBackgroundModes = bluetooth-central This works indefinitely while the app is in the foreground. When the app leaves the foreground — the user lowers their wrist or goes to the watch face — the peripheral disconnects after roughly three minutes, and the workout loses the rest of its data. What we have been able to establish from logs at the moment of the disconnect: The app is not suspended. Notifications arrive at a steady 1 Hz with no gaps right up to the disconnect (271 and 272 consecutive notifications in two separate cases), so the workout session is keeping the app running as expected. centralManager.state is .poweredOn. centralManager(_:didDisconnectPeripheral:error:) is called with error == nil, and the peripheral's state is .disconnected. Nothing in our code calls cancelPeripheralConnection at that point; our own teardown runs afterwards, in response to the disconnect. The user is still using the machine, and the machine is still notifying. Reproducible: two captures roughly three minutes and twenty seconds after the app backgrounded. I understand from Get timely alerts from Bluetooth devices on watchOS (WWDC22) that background Bluetooth on watchOS is intended for timely alerts, with a limited number of background runtime opportunities, and that periodic data collection should use Background App Refresh instead. Our data arrives once a second for the whole workout, so I assume we are well outside what that mode is budgeted for, and that the disconnect is the system reclaiming the link. My questions: Does a running HKWorkoutSession grant any exemption from the background Bluetooth limits? workout-processing clearly keeps the app executing — we receive notifications for minutes after backgrounding — but the connection is still torn down. Is Bluetooth's background budget independent of the workout runtime, and is that the intended behaviour? Is there a supported way to hold a BLE connection for the duration of a workout session? Reading a fitness machine's telemetry for an entire workout seems like a mainstream use of both frameworks together, but I cannot find a configuration that survives the app leaving the foreground. Would a longer connection interval change this? The session recommends at least 150 ms. If the disconnect is driven by connection-event volume rather than notification count, a slower interval or a lower update rate may be the answer — and if so, is there a documented threshold to aim for? error == nil on disconnect. The documentation says a nil error means the disconnect was requested locally via cancelPeripheralConnection, which we do not call here. Should a system-initiated reclaim of the link be reported this way, or is there a more specific error we should be looking for? We now log the error on peripheral(_:didUpdateValueFor:error:) to catch LeGattNearBackgroundNotificationLimit and LeGattExceededBackgroundNotificationLimit, but have not yet observed either before a disconnect. Is there any entitlement path for this? We are aware of com.apple.developer.bluetooth-central-background and that it is limited to continuous glucose monitoring. Is there an equivalent route for fitness equipment, or is foreground-only the expected design for this class of app? If continuous background Bluetooth is simply not available here, I would like to know that clearly, so I can design around the disconnect — reconnecting mid-workout rather than treating a dropped link as the end of the session.

I'm writing a Watch app where we have an in-built protocol for measuring resting heart rate. The user taps start and the heart rate is measured for 30 minutes while they're lying down. It works well, but because I'm using HKWorkoutSession to do this, the green exercise ring is advancing by 30 minutes even though the user is not exercising. So, any way to get continuous heart rate measurements without using HKWorkoutSession?

I have a watchOS app with a connected iOS app using Swift and SwiftUI. The watchOS app should read heart rate date in the background using HKOberserQuery and enableBackgroundDelivery(), send the data to the iPhone app via WCSession. The iPhone app then sends the data to a Firebase project. The issue I am facing now it that the app with the HKObserverQuery works fine when the app is in the foreground, but when the app runs in the background, the observer query gets triggered for the first time (after one hour), but then always get terminated from the watchdog timeout with the following error message: CSLHandleBackgroundHealthKitQueryAction scene-create watchdog transgression: app<app.nanacare.nanacare.nanaCareHealthSync.watchkitapp((null))>:14451 exhausted real (wall clock) time allowance of 15.00 seconds I am using Xcode 16.3 on MacOS 15.4 The App is running on iOS 18.4 and watchOS 11.4 What is the reason for this this issue? I only do a simple SampleQuery to fetch the latest heart rate data inside the HKObserverQuery and then call the completionHandler. The query itself takes less than one second. Or is there a better approach to read continuously heart rate data from healthKit in the background on watchOS? I don't have an active workout session, and I don't need all heart rate data. Once every 15 minutes or so would be enough.

I'm trying to understand the exact rules the Health app uses to reconcile (deduplicate/merge/discard) overlapping sleep samples, and I'm hoping an Apple engineer can clarify the behavior. Background: My Apple Watch wrote sleep samples to HealthKit twice within the same day, and the two writes overlap substantially: Same stage, overlapping in time — e.g., two "Core" sleep samples that overlap each other in time. Different stages, overlapping in time — e.g., Deep and Core overlap, and Core and REM (Rapid Eye Movement) also overlap. Observation: Even though the raw samples contain these overlaps, the Health app ultimately displays non-overlapping data (i.e., it has reconciled the overlaps somehow). I'm confused about the exact reconciliation rules the Health app applies to such overlapping data. To make the problem clearer, I've visualized the raw HealthKit samples. In the attached chart, you can see the same stage was written multiple times at different timestamps, shown in chronological order. However, the data ultimately displayed by the Health app differs significantly from the raw data — samples appear to have been reconciled, dropped, and merged in various ways. Question: What are the detailed rules the Health app uses to reconcile overlapping sleep samples? Specifically: When samples of the same stage overlap in time, how is the overlap resolved? When samples of different stages overlap in time, which stage takes precedence, and how are the boundaries adjusted? Are samples merged, truncated, or discarded entirely? Under what conditions? Any clarification from the HealthKit team would be greatly appreciated. Appendix 1 — Raw data visualization. All sleep samples as shown in the Health app (source: the complete sleep dataset in the Health app). Appendix 2 — Final presentation. How the Health app presents the data after reconciling the raw samples. Note — Comparing Appendix 2 with Appendix 1, the following differences are clearly visible: 1.A portion of Deep sleep was discarded. 2.Four awake segments were discarded. 3.Multiple REM segments were also discarded. 4.Core sleep was partially merged.

Hello, I’m requesting assistance with an urgent issue concerning my Apple Developer Program membership. I recently paid for a new subscription/membership, but I still cannot access my Apple Developer account or the related Apple connector account. When I sign in, I receive the following message: “Developer Program Membership Expired Your membership has expired, and your apps have been removed from the App Store until you renew your membership. To renew, a user with the Account Holder role must sign in and renew the membership on the Apple Developer website.” I have already completed the payment for the new membership, but the account continues to appear as expired. I am therefore unable to access the necessary developer services and manage my apps. Could someone please advise me on the following? • How can I confirm that my payment has been correctly associated with the Apple Developer team? • Does the renewal need to be completed by the Account Holder specifically? • How long should it take for the membership status and app availability to be restored? • What should I do if the payment was made with a different Apple Account? • How can I regain access to my Apple connector account? Payment info is from: 22 August 2026 I understand that Apple may require some processing time after renewal, and I appreciate your assistance. However, this issue is urgent because it is affecting access to my apps and development services. Thank you in advance for your help.

I'm building a native macOS app (deployment target macOS 14.0) that uses HealthKit. The App ID (com.ryanegli.Vantage, team RWGMA3VG99) has HealthKit enabled and saved under Capabilities. However, no provisioning profile generated for this App ID — automatic (Xcode-managed) or manually created/regenerated via the Developer Portal — ever includes the com.apple.developer.healthkit entitlement. The profile's "Review Provisioning Profile" page on the portal consistently lists only "In-App Purchase" under Enabled Capabilities, never HealthKit, even immediately after editing and regenerating the profile. Environment: Xcode 26.6, macOS 26.5 SDK Deployment target: macOS 14.0 Account role: Account Holder (sole owner of team) Steps to reproduce: Create a macOS app target with com.apple.developer.healthkit and com.apple.developer.healthkit.access in its entitlements file, App Sandbox enabled. Enable HealthKit on the App ID via developer.apple.com → Certificates, Identifiers & Profiles → Identifiers → [App ID] → Capabilities → HealthKit → Save (confirmed saved: Save button greys out afterward). Build with Xcode automatic signing, or manually create/download a "macOS App Development" provisioning profile for this App ID via the portal. Inspect the resulting profile (security cms -D -i profile.provisionprofile, or the portal's "Review Provisioning Profile" page). Expected: Profile includes com.apple.developer.healthkit. Actual: Entitlement is absent from every profile generated, across multiple regeneration attempts over several hours. Additional notes: Xcode's "+ Capability" picker in Signing & Capabilities does not list HealthKit at all for macOS targets (only appears for iOS/watchOS/etc.), suggesting Xcode's own capability catalog may not yet be updated for HealthKit-on-macOS. The App ID's "App Services" and "Capability Requests" tabs show no separate HealthKit-related entry that might explain a gating requirement (only clinical-records-specific sub-capabilities like "HealthKit Access (Verifiable Health Records)" appear there, which we don't need). Any suggestions, help, or input would be welcome. Thanks!

My app has been stuck in “Waiting for Review” status since August 6th, over a week now. I’ve submitted multiple expedited review requests and haven’t received any response or update on any of them. This delay is holding up my launch and affecting my ability to plan around it. I understand expedited review isn’t guaranteed, but getting no reply at all, even a decline, makes it hard to know whether the request was seen or if something else is holding up the review. Could someone look into my case and let me know what’s going on? Best regards, App Name: Ratiō - AI Calorie Tracker Apple ID: 6790632661

Hi Apple Developer Community, I’m preparing an iOS app called Titech for App Review. The app is intended for clinic/business users and provides preliminary AI-generated cosmetic analysis and preview guidance based on user-submitted face photos. The app is not intended to provide medical advice, diagnosis, or treatment decisions, and users are told to consult qualified experts before acting on any recommendation. We have received multiple App Review rejections and I would appreciate guidance on whether our current approach is aligned with Apple’s expectations. Current issues raised by App Review: Guideline 2.1 - Information Needed Apple asked for more information about how the app uses face data, including: What face data is collected How it is used, stored, retained, deleted, and shared Whether it is shared with third parties Where this is explained in the privacy policy Exact privacy policy text about face data We updated the app and privacy policy to explain that: Users voluntarily upload front, left-side, and right-side face photos Photos may be sent to our backend and processed by OpenAI through the OpenAI API Face ID/fingerprint data is not collected Uploaded face photos and generated preview images are deleted after the active session ends The app does not sell face data or share it with advertisers/data brokers Guideline 2.1(b) - Information Needed Apple asked about the business model and whether users access paid content. Our app does not currently include paid digital content, subscriptions, credits, or in-app purchases. Access is controlled by a registration code for clinic/business users and App Review only. Guideline 2.3.3 - Accurate Metadata Apple said the screenshots did not show the current version of the app in use. We replaced the screenshots with updated iPhone and iPad screenshots showing: Clinic access Consent and face-data disclosure Photo capture AI-generated analysis Recommendations Side effects page Generated preview flow My questions: For apps using user-submitted face photos with a third-party AI API, is it enough to clearly disclose OpenAI processing in the consent screen and privacy policy, or should this also be repeated elsewhere in the app flow? For face photos that are deleted after the active session ends, what wording does Apple generally expect around retention and deletion? Since the app is clinic/business access only and does not sell digital content, is a registration code acceptable if we clearly explain that it is not a paid digital unlock? Are there any additional App Review notes or privacy policy sections that developers usually include for apps involving face photos and AI-generated preliminary recommendations? For metadata, should the screenshots avoid login/consent screens entirely, or is it acceptable to include them as long as most screenshots show core app functionality? Any advice from developers who have passed review with apps involving user-uploaded face photos, AI analysis, or cosmetic/health-adjacent recommendations would be very helpful. Thank you.

It's fairly well know and stated that the Apple Health / HealthKit data store is unavailable when iPhone is locked. Since Lock Screen Widgets were introduced there's been a feature parity mismatch with Apple's own Fitness app which is able to display updating Activity Rings on the Lock Screen. Third party apps cannot do this and have to rely unlocking their device to then trigger an update. This means they often display stale and wrong Health data. With the release of iOS 18 beta, I see no changes to this... Is there anything I've missed? Currently for requesting the Timeline Updates on my Widget I have to just keep requesting updates as often as possible and hope that each time the iPhone might be unlocked.... This is inefficient and a waste of device resources. Even a Widget timeline reload API that let the developer say "Only call update if iPhone unlocked" would be useful.