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">

Has anyone else discovered CoreLocations "NullIsland" print out? I recently came across this easter-egg-esque message printed from my CLLocationManager in simulator and device (iOS 14.4.2) in some of my workout API code. 2021-04-10 08:30:11.547947-0500 AppName[28506:1222419] [Client] {"msg":"#NullIsland Either the latitude or longitude was exactly 0! That's highly unlikely", "latIsZero":0, "lonIsZero":0} I was banking on CLLocationManagers caching/sharing the 'location' property and cheating a little not passing my 'lastLocation' data point from one area of code to another and just doing CLLocationManager().location. Oddly enough, when I am attached with a debugger and then PRINT that object via lldb po location, it is populated with non-zero lat/long. I could refactor my code to pass the location property throughout my code, but if the value isn't really NullIsland, I'm not sure if it is worth the trouble. Anyways, this message feels misleading because lat/log is non-zero. I would expect this message to be printed when returning NullIsland OR when returning nil itself. Here is the gist - https://gist.github.com/edorphy/930dfbe73d4c471d4cd7a9668048b760

I submitted a feedback asking what would be safe prevent MITM attacks against CloudKit web APIs, pinning against the CA was an okay'd implementation. This is the response I got in my feedback: FB9445034 You can pin to the various Apple CA or sub-CA certificates that can be found here: https://www.apple.com/certificateauthority/public/ https://www.apple.com/certificateauthority/ All the certificates for CloudKit and iCloud web APIs have cert chains that point to the certificates listed. I have followed this article Identity Pinning and modified my App Clip info.plist accordingly to pin against CloudKit Web Services (https://api.apple-cloudkit.com). I intentionally mucked up the identity pin to verify my URLSession requests failed. I didn't receive any URLSession errors in my App Clip or Application targets when I had the plist updates in both. In reading these other forum posts I'm curious if the Identity Pinning is supported in App Clips or not. https://developer.apple.com/forums/thread/678081 https://developer.apple.com/forums/thread/681734

In my application initializer, I set a property on ApplicationDelegate. It is a reference to my data controller that manages access to many things (core data model). It gets passed in there to handle launch keys and pushes, and is relied upon as a required dependency to many services--namely push, navigation actions (quick look, Siri intents, etc.). In summary, I want to clean up and move some initialization code from my application initializer (tons of compiler directives for multi targets, watch, app, etc.) to the respective application delegates. BUT this requires an assumption that didFinishLaunching will be called after a property is injected into app delegate. Is this a safe assumption to make? I have observed the didFinishLaunching getting invoked only AFTER the initializer of Application completes. Can this be relied upon in terms of dependency injection? Can this order be assumed? Application init Property assignment on app delegate within app init App delegate init Property is set (didSet fires) App initialization complete, return Delegate fires willFinishLaunching Delegate fires didFinishLaunching Other delegate methods fire accordingly I assume that the implementation of UIApplicationDelegateAdaptor under the hood is similar to the Coordinators in UIViewRepresentable where as soon as you try to access / assign something on it, then it constructs the object and assigns an instance to the property wrapper. Additionally, if it hadn't already been initialized, because it DOES need to call delegate callbacks, the system will invoke it had you not already assigned a property to initialize it.

I've noticed a bug in my app recently, it appears that in watchOS 8.5 (or earlier) that page layout is no longer initializing or awakingWithContext the pages beyond the first index. According to the documentation: In a page-based interface, all interface controllers are initialized up front but only the first one is displayed initially. https://developer.apple.com/documentation/watchkit/wkinterfacecontroller/1619521-init I am simply not seeing this happen anymore. I have logging in all of the lifecycle method of all three of my pages and the second and third controllers don't fire anything (including init) until I swipe to the right. This is when I would expect the willActivate and didActivate methods to be invoked. Instead I get init, awake, willActivate, and then didActivate. :/ This is unfortunate and a bug to the user because the second controller asks to becomeCurrent under some certain conditions that the first detects and fires via NotificationCenter. The automatic programatic switching between pages is totally broken. FB9972047

Has anyone been successful creating a widget configuration that uses any of the "Measurement" type parameters? I'm running into crashes in the Widget/Home Screen when I try to do so. I am building a widget that provides functionality to 'nearby' points of interest. I just discovered that SiriIntents support specifying a Measurement type now --> Distance. When I have my configuration "nearbyDistance" parameter type set to the measurement type of Distance, adding the widget from the widget gallery crashes it after I hit the add button and it doesn't get added. This works: This crashes the Widget Preview and doesn't add the widget to the Home Screen: Right before I add my widget, things seem to be good: As soon as I tap Add Widget, this happens: I have created a feedback for this and attached some recordings and a sysdiagnose: FB10002319

Hey everyone, I've been experimenting around with the new searchable update to add scope to SwiftUI search bars. I requested this last fall and now I'm looking into it as available with Xcode 14 / iOS 16 (FB9674003). I found two bugs in case others run into them. The search bar's segmented 'scopes' only show if the search binding is a non-empty string. (FB10558607) The selected scope binding is not honored when updated outside of the searchable search bar itself. (FB10558881) It is my assumption that these are both defects. Attached is a sample view that illustrates the two bugs. Additionally, writing this up, I felt it was important to also provide developers the ability to specify the visibility of the segmented scopes within the search bar which is possible in UIKit (FB10558936). Something like .searchableScopeVisibility(.always). import SwiftUI struct ContentView: View {          enum FoodScope: CaseIterable {         case fruit         case veggies                  func scopeText() -> String {             switch self {             case .fruit:                 return "Fruit"                              case .veggies:                 return "Veggies"             }         }     }          private let fruits: [String] = ["Apple", "Apricot", "Banana", "Cantaloupe"]     private let veggies: [String] = ["Asparagus", "Beets", "Broccoli", "Cabbage"]          @State private var searchText: String = ""     @State private var scope: FoodScope = .fruit          private var filteredFood: [String] {         switch scope {         case .fruit:             guard searchText != "" else { return fruits }             return fruits.filter { $0.contains(searchText) }                      case .veggies:             guard searchText != "" else { return veggies }             return veggies.filter { $0.contains(searchText) }         }     }          var body: some View {         NavigationStack {             List {                                  Section {                     ForEach(filteredFood, id: \.self) { food in                         NavigationLink(food, value: food)                     }                 } header: {                     Text("Food")                         .textCase(.none)                 }                                  // FB10558607 - SwiftUI: Searchable "scope" non functional in Xcode 14 beta 2 (scope items not visible when searching)                                  Section {                                      } footer: {                     Text("The 'scopes' provided within the new searchable modifier will only be shown when the searchable text binding is a non-empty string. Try for your self by tapping inside the search. You \"should\" see the scope segments appear right away but they don't. Then type any character and they'll show on screen. FB10558607")                 }                 // FB10558881 - SwiftUI: Searchable 'scope' binding is not honored when updated by another mechamsim outside of the searchable scope picker                 // Create another binding to the selected scope and change it. The picker in the search bar does NOT reflect the state of SwiftUI's @State scope property.                 Section {                     Picker("Scope", selection: $scope) {                         ForEach(FoodScope.allCases, id: \.self) { scope in                             Text(scope.scopeText())                                 .tag(scope)                         }                     }                     .pickerStyle(.segmented)                     .buttonStyle(.plain)                     .listRowBackground(Color.clear)                 } header: {                     Text("Searchable Scope Binding Selector")                         .textCase(.none)                 } footer: {                     Text("Additionally, the scope binding will not update when modified via another mechanism (like another segmented picker). When the segments are visible with the search, change the scope and you'll see the binding to the picker change. But, if you change the scope of the picker below, the scope in the search bar will not react as expected. ")                 }             }             .listStyle(.insetGrouped)             .searchable(text: $searchText, scope: $scope) {                 ForEach(FoodScope.allCases, id: \.self) { scope in                     Text(scope.scopeText())                         .tag(scope)                 }             }             .navigationTitle("FB9674003")             .onChange(of: scope) { newValue in                 print("New scope \(newValue.scopeText())")             }             .navigationDestination(for: String.self) { value in                 Text("You selected \(value)")                     .navigationTitle("Yummy food")             }         }     } } #if DEBUG struct ContentView_Previews: PreviewProvider {     static var previews: some View {         ContentView()     } } #endif

Note: My app is in pre-order status for a version approved against Xcode 13.4.1, the below is for submitting an update with iOS/iPadOS 16 support using Xcode 14 RC released today. Is this happening for anyone else? I just downloaded Xcode 14 RC and archived/uploaded a build. When I select the build in App Store Connect to submit to review, it isn't showing my App Clip domains. When I select a build that was created yesterday with Xcode 14 Beta 6 from Xcode Cloud, the domains show, but for obvious reasons (Xcode beta tools) I cannot submit that build. I'm waiting for Xcode Cloud to add RC to their list and try again, but I'm stuck. I think it is just an App Store Connect issue, because my code is literally unchanged between these two builds less the build version. Furthermore, I inspected the archive locally from Xcode 14 RC and in the validation step, confirmed the entitlement lists my two appclips associated domains in both the app target and app clip target. I created a feedback for this here: FB11471066, FB11335182 Has anyone else had this issue? I know that App Clips was having some issues a few weeks ago but this seems like something entirely different: https://developer.apple.com/forums/thread/712372 Finally, to the last of my ability to troubleshoot, running the Diagnostics under App Clips Testing in the Settings app, I get all green checkmarks for both of my domains--so I really just believe this to be a portal issue and that everything actually checks out.

I'm trying to build a developer tools app that can run in the app sandbox and execute commands related to working with DSYM files. The app sandbox is a requirement for publishing it to the App Store. I come from the world of iOS so everything is a sandbox to me and this is new territory. To execute my commands I'm using the Process type to invoke command line. func execute() throws -> CommandResult { let task = Process() let standardOutput = Pipe() let standardError = Pipe() task.standardOutput = standardOutput task.standardError = standardError task.arguments = ["-c", command] task.executableURL = URL(fileURLWithPath: "/bin/zsh") task.standardInput = nil let outHandle = standardOutput.fileHandleForReading let errorHandle = standardError.fileHandleForReading try task.run() let out1 = outHandle.readDataToEndOfFile() let out2 = errorHandle.readDataToEndOfFile() // more code interpreting the pipes I'm trying to perform the following operations: mdfind to locate DSYMs https://developer.apple.com/documentation/xcode/adding-identifiable-symbol-names-to-a-crash-report#Locate-a-dSYM-using-Spotlight dwarfdump to verify UUIDs https://developer.apple.com/documentation/xcode/adding-identifiable-symbol-names-to-a-crash-report#Match-build-UUIDs atos to symbolicate with the found DYSM file https://developer.apple.com/documentation/xcode/adding-identifiable-symbol-names-to-a-crash-report#Symbolicate-the-crash-report-with-the-command-line This all works just fine when I run my Mac app without sandboxing, but as one would expect totally fails when App Sandbox is enabled--the sandbox is doing its thing. Responses like "xcrun cannot be used within an App Sandbox", or simply the output not finding anything because the scope of the process is limited to the sandbox, not where my app DSYM file is. In my readings on the documentation, where it states that I can create a command line helper tool that gets installed alongside the app sandbox app. "Add a command-line tool to a sandboxed app's Xcode project to the resulting app can run it as a helper tool." https://developer.apple.com/documentation/security/app_sandbox Is this the right path to take? Or is there a way to still achieve access to xcrun by asking the user to grant access to other parts of the system via dialogue prompts? I have followed this guide but don't know where to go from here: https://developer.apple.com/documentation/xcode/embedding-a-helper-tool-in-a-sandboxed-app It leaves off at print("Hello World") and no instructions on how to have your app communicate with the helper from what I could find ... :). I know, generally speaking, of XPC services and that I have the ability to make them on macOS, unlike iOS (wait maybe 17.4 allows it? https://developer.apple.com/documentation/xpc anyways). Would creating an XPC helper be allowed to execute commands against xcrun or have access to the ~/Library/Developer/Xcode path to find the debug symbols for the purposes of symbolicating a crash report? I really want to be able to ship my app on the App Store and enable developers to use the tool super easy, but I'm not sure if the App Sandbox will prevent me from achieving what I'm trying to do or not. Any tips, pointers, samples, guidance is much appreciated!

I've recently started working with IPS files, specifically crash reports. According to the documentation there are a number of metadata keys included in these payloads, however, I have found a number that are present in real ips files from device but are not documented. Does anyone know what version of iOS these 'new' metadata keys were introduced? How about if they're expected or if I should treat them as optional. https://developer.apple.com/documentation/xcode/interpreting-the-json-format-of-a-crash-report#IPS-metadata { "app_name":"ApplicationNameHere", "timestamp":"2024-02-15 08:05:05.00 -0600", "app_version":"1.6.0", "slice_uuid":"6b1f9f4e-3025-364f-9847-914fc1fe14d1", "build_version":"800", "platform":2, "bundleID":"reverse.domainname.bundleidentifier", "share_with_app_devs":1, "is_first_party":0, "bug_type":"309", "os_version":"iPhone OS 17.3.1 (21D61)", "roots_installed":0, "name":"ApplicationNameHere", "incident_id":"1CF0B8A1-EB43-46B3-AA9F-CFA8A9259190" } The following keys are not in the documentation: app_name, os_version, slice_uuid, share_with_app_devs, is_first_party, roots_installed I created this feedback to request the documentation be updated with current state. FB13631161 - Developer Documentation: Update IPS metadata to reflect latest values found in IPS Metadata JSON

I created a new index on two record types on Oct 12th. I still cannot query the records using the new queryable index on records that were created before that date. There is no indication in the schema history that the reindexing has started, completed, failed, or still in progress. What is the expectation for new indices being applied to existing records? Well over a week seems unacceptable for a database that has maybe 5000 records across a few record types. When I query my data using an old index and an old record field, I get hundreds of matching results so I know the data is there. FB15554144 - CloudKit / CloudKit Console: PRODUCTION ISSUE - Query against index created two weeks ago not returning all data as expected

I tried to use the Connect app this morning and it said a developer account was needed. On the contrary, I am the account holder, which is what the CTA to fix the issue in the app stated to ask for access from. Then I tried to sign in directly on the website and it also didn't respond there. FB19906255 - App Store Connect: Connect app not responding and neither is App Store Connect portal Aug 26, 8:15 AM Central Posting in case others run into this, I have not seen the developer status page report anything yet: https://developer.apple.com/system-status/

I've been writing about the DeclaredAgeRange a bit on LinkedIn and now it is time to take to the developer forums. In my efforts to prepare my apps for new local requirements, I've run across some rough edges. The DeclaredAgeRange API is missing on several platforms, and extension types. First and foremost, watchOS. An Apple Watch is a clear single user platform and for standalone apps, the DeclaredAgeRange being absent is felt by developers. FB20954931 - DeclaredAgeRange: Framework not available on watchOS making compliance a challenge for watchOS standalone apps In the same vein of thinking, while users on Apple Vision Pro are far fewer numbers than Apple Watch, it is also a miss. The tricky part would be testing on the simulator. So far I haven't gotten the simulator and sandbox testing to work and give real values across any platform. I don't think an Apple Store will let me try my app out via TestFlight on their devices and they're still too expensive to reasonably buy for most developers. Too bad Feedbacks are not a currency that developers can trade in for gear. FB20955020 - DeclaredAgeRange: Framework not available on visionOS making compliance a challenge for visionOS apps I'll recognize that the user model is different on tvOS, and that as a user while I have family group setup, I don't have any children on the account. I have to imagine that child accounts on an Apple TV exist and would be able to account for the sharing of age ranges to apps. Yes, the user could just switch profiles, but, app developers could still integrate the age range into their apps. Maybe it needs more robust system level support but here is the feedback just the same. FB20955029 - DeclaredAgeRange: Framework not available on tvOS making compliance a challenge on tvOS apps And finally, let's not forget about App Clips. While the App Clips might not be 'downloaded' from App Store itself, it is powered by App Store technologies to an extent. I'd rather not bifurcate my code more than it already is for the shared code between my apps and app clips. Rounding out platform support to App Clips, since it is iOS, would close the loop. FB20954846 - DeclaredAgeRange / App Clips: Add support for DeclaredAgeRange framework for App Clip targets - capability exist, Xcode cannot generate entitlement for it Oh wait, actually, not quite. To fully close the loop, make the DeclaredAgeRange work fully on macCatalyst. The documentation says it is compatible, but from my experiments trying to get it to even compile when targeting macCatalyst apps simply doesn't build. FB21117325 - DeclaredAgeRange: API documentation states available on mac catalyst - but fails to compile in Xcode 26.2