I'm running into an error in Xcode 16 beta 4 where the compiler can't type check what appears to be a simple @FetchRequest. I have the following Core Data types: Establishment name website etc. locations (relationship, to many, optional) Location name address establishment (relationship, to one, non-optional) In one of my SwiftUI views I have the following @FetchRequest and SortDescriptors. Unwrap required because 'core data' optional types. It looks based on the swift lang key-path expression docs that this should be allowed. Build and run works, but archiving does not. https://docs.swift.org/swift-book/documentation/the-swift-programming-language/expressions/#Key-Path-Expression In practice it won't be nil and validation should prevent it too so I could force unwrap the relationship property, but, defensive coding I want to make it safe as I can. @FetchRequest( sortDescriptors: [ SortDescriptor(\Location.establishment?.name, order: .forward), SortDescriptor(\Location.city, order: .forward), SortDescriptor(\Location.state, order: .forward) ] ) private var locations: FetchedResults<Location> This worked fine with Xcode 15.x, but fails to archive in Xcode 16 beta 4. The compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions When I remove the first sort descriptor it works. When I force unwrap the optional key path property it works. Does anyone know of a documented change that would make this no longer work? FB14515958 - SwiftUI: SortDescriptor cannot archive in Xcode 16 beta 4 but works in Xcode 15.4 For clarity, this archives fine, note the force unwrap. @FetchRequest( sortDescriptors: [ SortDescriptor(\CraftTaproom.brewery!.name, order: .forward), SortDescriptor(\CraftTaproom.city, order: .forward), SortDescriptor(\CraftTaproom.state, order: .forward) ] ) private var taprooms: FetchedResults<CraftTaproom>

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.

I'm trying to download artifacts from some recent Xcode Cloud builds. In both Xcode and App Store Connect I'm getting errors. Xcode says: "Error Fetching Test Results: API Invalid status code: 501. App Store Connect says: "artifacts could not be found." FB13773789 - Xcode Cloud: Service returning 501 in Xcode when trying to view artifacts of successful build from minutes ago I have tried several projects to rule out project specific issues and it is happening to all of my Xcode Cloud enabled projects. Both Xcode 15.3 and 15.4 beta exhibit this behavior. Is anyone else running into this issue? I noticed it yesterday, and it continues into this morning.

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'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'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 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: &lt;CKError 0x2818a16b0: "Server Rejected Request" (15/2001); "Request failed with http status code 500"; uuid = 2CA523A6-8F39-4538-98AF-E9B7D6CACF73&gt; 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.

Hey everyone, From WWDC23 lab conversations, in order to run a fitness app, health tracking apps, etc. on iPadOS 17 that 'requires' health, you actually have to remove the UI Required Device Capabilities for Health. The UIRDC will still prohibit the app from running on iPad this fall even though from a developer lens it is satisfied. I understand this is to allow iPhone apps a chance to upgrade and get ready for iPadOS 17, but there isn't a path forward if an app truly requires HealthKit. Namely for fitness apps that ONLY read and or write data to Health. Sure I could move my target SDK to 17, but that doesn't help my existing users who can't upgrade on iOS < 17. What is the path forward for Apps that want to target something like the following? iOS 14+ watchOS 7+ iPadOS 17+ Socializing the idea of having an App Store Connect feature or checkbox to allow / opt into being available on iPadOS 17+. The same applies for App Clips that also require HealthKit. FB12327957 - Health / App Store Connect: Ability to make HealthKit required on iPadOS and iOS together

I've been getting duplicate visits sent to my CLLocationManagerDelegate. This is new since iOS 16, I did not see this behavior in iOS 15--the observed effect is a quite severe regression in the behavior of CoreLocation. Here is what I'm seeing: The visits have already been delivered When they're sent 'again', they're sent in dozens of callbacks When they're sent 'again', they're sent in batches irrespective of app state I have had a debug app on my phone running since November to capture sysdiagnose for FB12107066. My app simply records data from CoreLocation into a mini Core Data table. Since November 11th, I have had 3808 visits, but when I do some distinct queries on arrival and departure I get a fraction of that. Select distinct arrivalDate: 929 Select distinct departureDate: 799 Select distinct arrivalDate + departureDate: 1172 I wrote some logic to attempt to deduplicate and filter out garbage visits that have already been delivered to me, but my filtering isn't bullet proof. This issue has been happening for me on multiple devices since Nov (iOS 16.2 days?). This happens on an iPhone 13 Pro and an iPad Pro 11-inch (4th gen). This is a real nasty bug as it also keeps waking my app up in the background when I don't expect it to since the OS is delivering me old / replay visits. :/ Has anyone else seen issue with the Core Location Visit API in iOS 16? What deduplication and filtering logic did you come up with? While the issue is affecting me via CoreLocation, I would suspect the same might also occur for anyone using the visits API in SensorKit too.

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

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 would like to socialize the idea of starting a Live Activity while the app is in the background. According to the ActivityKit, documentation, Live Activities can only be started while your app is foreground. I wrote up a really lengthy feedback about this enhanced ActivityKit permission concept but will summarize to share with others here. FB11308611 The idea is this, like CoreLocation, the ActivityKit framework could have the permission model of 'when in use' and 'always'. Apps that the user has granted the 'always' permission for would then be allowed to start an activity from some sort of background execution. I'm looking at the Background Modes defined in Xcode namely: Location Updates, Bluetooth, Remote Notifications, Nearby Interactions, etc. My specific use case is to combine my usage of Core Location Region Monitoring and Visit Monitoring into triggering a Live Activity to the users Lock Screen when they are at a place contextually relevant to my app(s). I can imagine this applies to many other applications too. While the current experience I have will present the user with a local notification gets the job done, the user experience could be so much more engaging. When I saw the Live Activities feature get announced during WWDC22, this was the first thing that came to mind. FB11308699 Some very high level concepts: Live Activity when entering a sport stadium Live Activity when entering a concert venue Live Activity when entering a gym Live Activity when entering a restaurant Live Activity when entering a store Got another use case? Share it! Like a use case in this thread? Comment on it!

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'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 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.