Hey developer community / CloudKit fans, I'm making an application that utilizes CloudKit's identity system to provide my users a 'social' aspect of the app as well as their own identity. When filling out my App Privacy label, I'm torn if I should disclose Contact usage or not. https://developer.apple.com/documentation/cloudkit/ckcontainer/1640421-discoverallidentities Right now, I'm leaning to not specifying Contacts collection. Here are my thoughts: Data Collection defined by Apple, paraphrased, is transmitting data off device for longer than needed for the request. How Apple implements the function of the CloudKit identity lookup is outside of our control as developers, however, it is reasonable to expect that Apple would not save your contact address book in CloudKit and the data does not live in CloudKit longer than it needs to. I don't access the Contacts app or API in the implementation. Apple in fact use your contacts under the hood to service this request according to the documentation, however to the user, there is no contacts permission / access prompt for the application itself. The app doesn't get access to the full contacts db. When you receive a CKUserIdentity, the contacts identifier is just that, a lookup identifier string. I'm not going further than just displaying the information on the user identity. I could back link the identifier to a contacts record, but I don't need to. If I did that, even then I would say no, because the operation all happens locally on device. Does your app use CKUserIdentities? How did you answer the App Privacy question for Contacts? If you have strong feelings one way or another, I'd love to hear your perspective.

I just released my app for pre-order and the message link preview in the Messages app for the listing is somehow using an older screenshot that was provided to App Store Connect weeks ago. I deleted and uploaded new screenshots just this weekend before sending in for review and everything looks correct in App Store Connect. I just confirmed what is showing in link previews does NOT match what was approved in App Store Connect. Has anyone else encountered similar issues when listing their apps for pre-order or just in general? What is really strange is that the image being shown in link previews was approved once, but I developer rejected it. Maybe some caching issue with Apple preemptively propagating the images when it was approved the first time before I chose to release it? Just speculating. FB11257903

I have a simulator named "iPhone 14 Pro" created and booted. The override --time command doesn't appear to take anymore. This worked months ago, but broke somewhere along the road of Xcode 14.x. It is a drag setting the system time to 9:41 for App Store Connect screenshots which is why I used the command in the first place. I cannot seem to successfully set the status bar time of the simulator via the following command anymore: xcrun simctl status_bar "iPhone 14 Pro" override --time "9:41" Is this working for anyone else lately? Feedbacks; Created these Dec 7, 2022 FB11859751 - Simulator: iOS simulator not responding to simctl set time FB11859744 - Simulator: watchOS simulator not responding to simctl set time

I'm trying to get the ASK Sample to discover and connect to a device using a 16-bit uuid. In my case, I have a few fitness sensors laying around like heart rate monitors and cycling sensors. Specifically, I've configured the following descriptor to be shown in the picker: private static let heartRateMonitor: ASPickerDisplayItem = { let descriptor = ASDiscoveryDescriptor() descriptor.bluetoothServiceUUID = CBUUID(string: "180D") return ASPickerDisplayItem(name: "Heart Rate Monitor", productImage: UIImage(named: "PolarH10")!, descriptor: descriptor) }() 100% another app on the device using an unfiltered scan can find this device, so I know the phone can see it. Also, the settings app Bluetooth screen sees it too. When the picker is active for this descriptor, in console I see the device is being discovered and it is matching the underlying filter. However the picker doesn't show the device. Received 'start active Unspecified scan' request , without duplicates, duration:unlimited, UUIDs [ E56A082E-C49B-47CA-A2AB-389127B8ABE3 E56A082E-C49B-47CA-A2AB-389127B8ABE4 0x180D ] on 1M PHY from session "com.apple.deviceaccessd-central-727-198" Matched UUID 0x180D for device "D3030A85-BBB9-6C0D-53C4-6697898B2E4B" This is an apparent bug: FB14078940 - AccessorySetupKit: ASDiscoveryDescriptor does not appear to identify 16-bit UUIDs like the Heart Rate Service/Profile UUID After more tinkering, I did discover that if I connect the device in the settings app, and keep it connected, the picker will find the device immediately. I assume it is under the hood it is calling this function or the internal implementation: https://developer.apple.com/documentation/corebluetooth/cbcentralmanager/retrieveconnectedperipherals(withservices:) This is still not expected, a developer should be able to discover and connect an accessory directly in their app. Noteworthy, I also found that ALL apps in the Settings app list the accessory once paired, which is totally not expected: FB14170263 - Settings: Viewing accessories in settings app for all apps show the accessory paired with another application P.S. forum moderators, there is no tag for 'AccessorySetupKit' which is the technology I'd like to tag this with. Last tested with iOS 18 developer beta 2.

Finally at last Apple Health supports saving .distancePaddleSports, .distanceCrossCountrySkiing, .distanceRowing, .distanceSkatingSports, and much more. The backstory. In the land of 10,000 lakes, there hasn't been a way to save 'canoe' or 'kayak' distance and I've been asking for it for years. Thank you health team for adding it this year! FB7807993 - Add HKQuantityTypeIdentifier.paddleDistance for canoeing, kayaking, etc type workouts (June 2020) Prior we could just save the totalDistance to a workout, but since the HKWorkout initializers were deprecated we no longer have a supported way to save these distances in our workouts. The iOS 18 / watchOS 11 introduction addresses this. If you want to know more why you can't do this in earlier versions you can check these feedback titles: FB10281482 - HealthKit: Deprecation of totalDistance on a workout session of paddleSports breaks apps that used that to save distance to the workout because there is no "paddleDistance" type available to save as sample data (June 2022) FB12402974 - HealthKit: Deprecation of HKWorkout completely breaks support for third party fitness apps from saving non-standard workout distance (June 2023) Great, so there is new support that solves all of these requests and issues for the new version of the OSes. However, the downside is now that there is not much for documentation. Unlike the .runningSpeed and .runningPower introduced in iOS 16 / watchOS 9, none of the new iOS 18 / watchOS 11 types have documentation, at all. To some degree this is understandable, but types from last year still remain undocumented too. Without this information for the data types introduced in both iOS 17/18 and watchOS 10/11 it makes building and integrating with these new types difficult to say the least. We can't make assumptions about anything. Can we get a documentation update for new (and existing) quantity types for when Apple Watch will automatically generate samples? FB14236080 - Developer Documentation / HealthKit: Update documentation for HKLiveWorkoutDataSource typesToCollect for which sample types are automatically collected by watchOS 10 and 11 (July 2024) FB14942555 - HealthKit / Documentation: App Update Release Issue - HKQuantityTypeIdentifiers are missing documentation describing when the system automatically adds data (today) I know that the behavior has changed from release to release for some of these types, so documentation would be based on OS version. If you didn't catch it, watchOS 11 will now associate .cyclingSpeed for cycling workouts both indoor and outdoor. FB12458548 - Fitness: Connected cycling speed sensor did not save samples to health via cycling workout (June 2023 - received reply that only saved for indoor cycling, but not documented otherwise) FB14311218 - HealthKit: Expected outdoor cycling to include .cyclingSpeed quantity type as a default HKLiveWorkoutDataSource type to collect (July 2024) To the other third party fitness apps out there, how are you managing the knowledge of which devices collect which data types on which versions of the OS? Sure, we could look at the HKLiveWorkoutDatSource and inspect the typesToCollect property across a bunch of devices, but again that is trial by error not 'as documented'. Is the behavior of simulators guaranteed to match the behavior of real devices? Maybe, but also maybe not. Fingers crossed for a nice documentation update to spell out all of the behavioral details. Apple folks / DTS, many of the above feedbacks are addressed and I plan to update or close them after the releases this fall. Some are still outstanding. P.S. I hope that .paddleSports gets deprecated and split into individual activity types like skiing did years ago. Their MET scores are different according to the research on the physical activity compendium site. FB7807902 - Split HKWorkoutActivityType.paddleSports into their own activity types (June 2020)

I'm a big fan of MetricKit. I decided to see how my apps are performing with iOS 18 and well, I'm not getting any metric payloads from those devices. Metric payloads received from my test devices adopting iOS 18 has pretty much bottomed out to zero. Is anyone getting MetricKit MXMetricPayloads from iOS 18 devices? FB15461298 - MetricKit: Production issue / regression with iOS 18 - Significant dropout or metric payloads being generated since 18.0 - nearly no reports To demonstrate the issue, I decided to graph the metric payloads my infrastructure receives for all of my apps across all of my devices over the last 16 months starting with WWDC23 timeframe. This data is grouped by count per month. A trend can easily be seen starting in June 2024 where I started to adopt iOS 18 betas. Zooming in since WWDC24, grouped by week, it is much easier to see the decline. Note, the second screenshot shows data collected from Xcode builds, TestFlight, and App Store. The last data point from today was a manual creation from Xcode's Debug window, so at least that triggering mechanism works and I can confirm all of my code to upload off device works as expected. On the bright side, I guess I will ship this 'payload received over time' feature in my MetricKit payload analyzer app with a scrolling window and group by features that make up these screenshots.

I'm running into an undocumented error coming back from CloudKit operations. Specifically, I'm attempting to save new records via CKModifyRecordsOperation. I'm receiving this error for each of the records in the perRecordSaveBlock callback: <CKError 0x3018ac3c0: "Internal Error" (1/3001); "MMCSEngineCreate failed"> Is anyone else facing this error? It has been happening for several days and I'm finally getting around to reproduction with the Console app and logs. I have 16 records on my device locally that each one gets this error back. FB16547732 - CloudKit: CKModifyRecordsOperation saving new records results in Error <CKError 0x3018ac1e0: "Internal Error" (1/3001); "MMCSEngineCreate failed">

CloudKit CKOperations do not complete when on cellular. When they do its once in a blue moon.I schedule things with allow cellular, and have verified in settings that iCloud allows cellular access. When I add any operation to the public database it will not do anything until I flip my device to wifi. This isn't acceptable as it is taking advantage of the location queries and is an on the go application.Has anyone come up with a workaround? Other posts suggest that it is a reported buy but has been around for a while so I'm not entirely sure.Edit:I have unit tests setup to do everything not only my application. When I run my unit tests with wifi off, they fail (30 second timeout without callback). After running them a few times with wifi (passing) and then switching they all of a sudden work on cellular (4 for 4 runs).I was able to run the app immediately after the successful cellular unit tests once. Its now back to failure.

iOS 13 is requesting Bluetooth permission immediately upon central manager initialization. From the Bluetooth 2019 talk, the presenter illustrated in the didUpdateState method to check the authorization state and appropriately prompt the user (presumably the same way you would with CMPedometer--invoke a instance method). Is this behavior to expected in the GM seed? It is counter intuitive and doesn't conform to the pattern that other frameworks use for their authorization workflow.This permission model seems to be incorrect, most other frameworks have a static method on the corresponding class to get authorization status. For example https://developer.apple.com/documentation/corelocation/cllocationmanager/1423523-authorizationstatus, https://developer.apple.com/documentation/coremotion/cmpedometer/2913743-authorizationstatus. The API signature that has a "notRequested" state, will seemingly never be the case since the prompt happens upon first initialization NOT first usage. CMPedometer initialization does not initiate the privacy prompt, only calling a method to do work does. CLLocationManager has explicit methods to invoke the authorization modal.If we don't have the class func to check authorization, and are dependent on an instance of CBCentralManager to have been initialized with a delegate, we can't design an elegant workflow to prompt the user at the appropriate time.

I have an existing WidgetBundle containing a single widget today that works with iOS 14/15. When I add the ActivityKit widget (aka Live Activities), Xcode naturally complains that this is available iOS 16 only. Adding an #if available(iOS 16.0, *) check inside the WidgetBundle results in an error: "Closure containing control flow statement cannot be used with result builder 'WidgetBundleBuilder'" Would the proper mechanism here be to create a second widget extension that ONLY includes the widget for the Live Activity and then use the available modifier on the entire widget bundle to only include it in iOS 16+? This thinking is based off the following here Typically, you include all your widgets in a single widget extension, although your app can contain multiple extensions. For example, if some of your widgets use location information and others don’t, keep the widgets that use location information in a separate extension. This allows the system to prompt the user for authorization to use location information only for the widgets from the extension that uses location information.

I'm getting a 404 page when I attempt to interact with the advanced App Clip editor page within App Store Connect. Can anyone else edit their app clip experiences right now, or do you also get a 404? Steps for both released and unreleased apps: Navigate to an app in App Store Connect Scroll to App Clip section Click "Edit Advanced Experiences" button Receive a 404 page Last tested Sunday Aug 14, 2022, @ 9:52 AM CDT. I filed this feedback for this issue: FB11252461 Separately, has anyone integrated with the App Store Connect API for App Clips? Not sure if just the portal is affected or if the API for App Clips is down too.

I've been scratching my head on this one. Out of the blue, part of my 'synchronization' mechanism that copies 'favorites' from device to device has stopped working. A user can save a favorite location and it will propagate to all of their other devices, or repopulate after an uninstall and reinstall. My code in the space hasn't changed for months and I haven't made any schema changes to this type either. Last night I noticed the process wasn't working anymore. My CKQueryOperation result completion is returning this error: <CKError 0x2818a16b0: "Server Rejected Request" (15/2001); "Request failed with http status code 500"; uuid = 2CA523A6-8F39-4538-98AF-E9B7D6CACF73> What is telling to me is that the CloudKit Console also fails with an internal error when I try to query this type in MY private database for two different accounts. I can query another type in the private database but this one won't work for two of the Apple ID's I have tried. Also interesting, if I query this type in the PUBLIC database, even though this type is only saved to the private database, that operation succeeds just fine. I don't want to burn a DTS ticket for a server issue. FB13543186 - CloudKit: Receiving 500 when performing a query operation on the private database CloudKit status page is green on the developer site as of this morning.

I'm building an app based entirely on CloudKit and I'm super excited for technologies like App Clip to make a mini 'menu' version of said app. The main app target allows vendor/site location managers to update their menu in real time and then signed in iCloud users can subscribe to those public record updates. I just discovered in the technology limitations of App Clips that CloudKit is out. It isn't in the list of 'supported capabilities' in the project editor. Additionally, as one would expect, trying to create a CKContainer without the entitlement in the App Clip target crashes with a fatal error due to the lack of that very entitlement. This feels unnecessarily restrictive and excludes developers from supporting App Clips who build their server tech stack on CloudKit. Write capability isn't needed for my concept. Effectively I'd want for each unique venue to be able to continue to manager their menu/venue via CloudKit + Security Roles and allow updating content in the main app--and for users to view/browse with focused location/venue specific menus in the app clip. As recommended, the full app has to be installed for the full experience. I'd rather not attempt to hit the public database via the JS library, or making an API proxy that just invokes CloudKit web tech under the hood. I really think supporting read operations from the public CloudKit database would enable many experiences that are currently restricted due to this limitation. If someone at Apple is watching, I created FB8528010 feature request with a little more details on my new feature concept.

I have several apps that contain extensions. For example an App Clip, Widget, Background Assets extension, etc. In Xcode Organizer Version 15.3 (15E204a), attempting to view crash data for these apps results in a failure. I have explicitly seen this error print out the app clip extension bundle identifier, as well as the background assets extension bundle identifier. It says the following error: An error occurred preventing Xcode from downloading crashes list. "" failed with error: Access Restricted with bundle id: com.example.app-name.extension-name Is anyone else experiencing this? I created a feedback a few weeks ago, it seemed to coincide with the release of Xcode 15.3 and or the new App Store Connect metrics APIs. App IDs and bundle identifiers detailed in the feedback if anyone at Apple wants the info. FB13677615 - Xcode: Cannot download crashes for apps that containg extensions --> "Access Restricted with bundle id:

I'm making a wrapper library to abstract away some of the 'missing platform support' of DeclaredAgeRange until hopefully it expands to additional platforms. When I'm trying to fully enumerate all of the cases of AgeRangeDeclaration, which they all state available starting 26.0 (mysteriously added in Xcode 26.2 beta), the app crashes due to a missing symbol at launch time. This happens both for Xcode 26.1, 26.2 beta 2, and matching Xcode Cloud builds. So I've isolated it beyond "doesn't work on my machine". I just made a handful of crashes and attached a sysdiagnose to a fresh feedback. FB21121092 - DeclaredAgeRange: Eligibility property and new declaration cases unavailable on iOS 26.1 device contradicting documentation - causes runtime symbol not found crash If anyone is curious what these crashes look like I've attached the DiagnosticPayload.jsonRepresentation() generated from one of my favorite frameworks, MetricKit. Very clearly articulated in the diagnostic metadata you can see the symbol not found. "diagnosticMetaData" : { "platformArchitecture" : "arm64e", "terminationReason" : "Symbol not found: _$s16DeclaredAgeRange0bC7ServiceV0bC11DeclarationO14paymentCheckedyA2EmFWC\nReferenced from: <1894EDCB-3263-3604-8938-97D465FF3720> \/Volumes\/VOLUME\/*\/PerformanceOrganizer.app\/PerformanceOrganizer\nExpected in: <B8FD2C23-0CC9-3D94-902D-875900307A7A> \/System\/Library\/Frameworks\/DeclaredAgeRange.framework\/DeclaredAgeRange", "exceptionType" : 10, "appBuildVersion" : "745", "isTestFlightApp" : true, "osVersion" : "iPhone OS 26.1 (23B85)", "bundleIdentifier" : "dev.twincitiesapp.performanceorganizer", "deviceType" : "iPhone18,1", "exceptionCode" : 0, "signal" : 6, "regionFormat" : "US", "appVersion" : "2.0.0", "pid" : 22987, "lowPowerModeEnabled" : false } DiagnosticPayload.json This is the offending code in a type I control and make available on other platforms but leave unused. extension AgeRangeDeclaration { // A factory or initializer that takes the AgeRangeService.AgeRangeDeclaration and maps to the common AgeRangeDeclaration type public init?(platform value: AgeRangeService.AgeRangeDeclaration?) { guard let value else { return nil } switch value { // Xcode 26.1 visible cases case .selfDeclared: self = .selfDeclared case .guardianDeclared: self = .guardianDeclared // Xcode 26.2 visible cases // This is the first culprit, all of the following symbols would crash, this is just the first case .checkedByOtherMethod: self = .checkedByOtherMethod case .guardianCheckedByOtherMethod: self = .guardianCheckedByOtherMethod case .governmentIDChecked: self = .governmentIDChecked case .guardianGovernmentIDChecked: self = .guardianGovernmentIDChecked case .paymentChecked: self = .paymentChecked case .guardianPaymentChecked: self = .guardianPaymentChecked @unknown default: // Apple added new cases in Xcode 26.2 betas that were available in iOS 26.0, // so it is probable that this could happen again. If it does, assert to let developers // bring it to my attention. assertionFailure("Invalid or out of date knowledge of age range declaration \(value)") self = .unknown } } } For what it is worth, the same is also true for isEligibleForAgeFeatures which I suspect was also added to Xcode 26.2 somehow but not made available to real devices running [26.0 - 26.2). As a side note, thank you for this property, it will let me check what states I need to perform extra checks for in a clean way, I just will need it to now not crash my app on 26.0 and 26.1 runtime devices. :) Edit: DTS did confirm on a comment I had in another thread that this is a bug. Now just to wait for an Xcode beta update. https://developer.apple.com/forums/thread/807906?answerId=867205022#867205022 In any case, this is a great example of how MetricKit totally rocks capturing things other off the shelf crash tools might not have a chance to get. I did have to roll back my TestFlight to an earlier build, but MetricKit was there to send me the previous crashes as soon as the app could launch. Thanks MetricKit team!