I have a project which when I attempt to build with XCode 16 RC fails with the message "XCBBuildService quit unexpectedly". This occurs 100% of the time, thus I am unable to build the project. It first occurred in Xcode 16 beta 1 and has been present ever since, ever present in every beta; and now as its still present in the RC its highly unlikely it'll be fixed when the RC release becomes the final release. I submitted a ticket for this many weeks ago (FB14062261), but its not been looked at/updated. This is a problem in the short term because my app needs updating to use some iOS 18 specific features, in the longer term, it won't be possible to submit the app to the App Store if it continues to only be buildable with Xcode 15. As its impossible to build the app, I attempted to create a support ticket to get assistance. However I am unable to create a support ticket because the web page won't permit me to proceed raising a ticket unless there is a test Xcode project that recreates the issue. However, the issue does not occur with small simple Xcode projects. The Xcode project which I cannot be build contains dozens of sources files, thousands of lines of code, and many dependences. I can't submit that as the text Xcode project as its larger than that stated minimum requirements to attach to a support ticket. So how can I proceed, I can't build the app, I've raised a feedback ticket which hasn't been looked at, and when I attempt to raise a support ticket, the website won't let me proceed and create one. What can I do to get a support ticket created? What Xcode outputs: Process: XCBBuildService [9024] Path: /Applications/Xcode.app/Contents/SharedFrameworks/XCBuild.framework/Versions/A/PlugIns/XCBBuildService.bundle/Contents/MacOS/XCBBuildService Identifier: com.apple.dt.XCBBuildService Version: 1.0 (23000.1.226) Build Info: XCBuild-23000001226000000~13 (16A242) Code Type: ARM-64 (Native) Parent Process: Xcode [8990] Responsible: Xcode [8990] User ID: 504 Date/Time: 2024-09-09 14:03:16.8948 -0700 OS Version: macOS 14.6.1 (23G93) Report Version: 12 Anonymous UUID: EB8CED5F-F888-D71F-3893-33504A2FE3FD Time Awake Since Boot: 1800 seconds System Integrity Protection: enabled Crashed Thread: 13 Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: Namespace SIGNAL, Code 6 Abort trap: 6 Terminating Process: XCBBuildService [9024] Application Specific Information: abort() called Kernel Triage: VM - (arg = 0x3) mach_vm_allocate_kernel failed within call to vm_map_enter VM - (arg = 0x3) mach_vm_allocate_kernel failed within call to vm_map_enter VM - (arg = 0x3) mach_vm_allocate_kernel failed within call to vm_map_enter VM - (arg = 0x3) mach_vm_allocate_kernel failed within call to vm_map_enter Thread 0:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x1871fcdf4 mach_msg2_trap + 8 1 libsystem_kernel.dylib 0x18720f5e4 mach_msg2_internal + 80 2 libsystem_kernel.dylib 0x1872059c4 mach_msg_overwrite + 476 3 libsystem_kernel.dylib 0x1871fd178 mach_msg + 24 4 CoreFoundation 0x18731d680 __CFRunLoopServiceMachPort + 160 5 CoreFoundation 0x18731bf44 __CFRunLoopRun + 1208 6 CoreFoundation 0x18731b434 CFRunLoopRunSpecific + 608 7 CoreFoundation 0x18739945c CFRunLoopRun + 64 8 libswift_Concurrency.dylib 0x24eabd4e0 swift_task_asyncMainDrainQueueImpl() + 40 9 libswift_Concurrency.dylib 0x24eabd4a0 swift_task_asyncMainDrainQueue + 92 10 XCBBuildService 0x1043b392c main + 84 11 dyld 0x186eb3154 start + 2476 Thread 1: 0 libsystem_kernel.dylib 0x1871fd9b4 read + 8 1 XCBServiceCore 0x104c34688 closure #3 in ServiceHostConnection.resume() + 624 2 XCBServiceCore 0x104c326ed partial apply for closure #1 in Service.registerMessageHandler<A>(_:) + 1 3 XCBServiceCore 0x104c32a55 closure #1 in closure #1 in OS_dispatch_queue.async(group:qos:flags:execute:) + 1 4 XCBServiceCore 0x104c32a55 closure #1 in closure #1 in OS_dispatch_queue.async(group:qos:flags:execute:) + 1 5 XCBServiceCore 0x104c35c21 $sxIeAgHr_xs5Error_pIegHrzo_s8SendableRzs5NeverORs_r0_lTRyt_Tg5TQ0_ + 1 6 XCBServiceCore 0x104c326ed partial apply for closure #1 in Service.registerMessageHandler<A>(_:) + 1 7 libswift_Concurrency.dylib 0x24eabe0f9 completeTaskWithClosure(swift::AsyncContext*, swift::SwiftError*) + 1 Thread 2:: llb_buildsystem_build 0 libsystem_kernel.dylib 0x1872005ec __psynch_cvwait + 8 1 libsystem_pthread.dylib 0x18723e55c _pthread_cond_wait + 1228 2 libc++.1.dylib 0x187163b14 std::__1::condition_variable::wait(std::__1::unique_lock<std::__1::mutex>&) + 28 3 llbuild 0x10531730c (anonymous namespace)::BuildEngineImpl::executeTasks(llbuild::core::KeyType const&) + 4552 4 llbuild 0x105314390 llbuild::core::BuildEngine::build(llbuild::core::KeyType const&) + 580 5 llbuild 0x10532da38 (anonymous namespace)::BuildSystemImpl::build(llbuild::buildsystem::BuildKey) + 208 6 llbuild 0x10532dc14 llbuild::buildsystem::BuildSystem::build(llvm::StringRef) + 260 7 llbuild 0x1053203f4 llbuild::buildsystem::BuildSystemFrontend::build(llvm::StringRef) + 56 8 llbuild 0x1052a6d8c 0x10528c000 + 109964 9 XCBBuildSystem 0x104d8ad1c partial apply for closure #13 in BuildOperation.build() + 28 10 libswift_Concurrency.dylib 0x24ea89a4c TaskLocal.withValue<A>(_:operation:file:line:) + 304 11 XCBUtil 0x1048d8864 closure #1 in closure #1 in static Task<>.detachNewThread(name:_:) + 296 12 XCBUtil 0x1048854ec thunk for @escaping @callee_guaranteed @Sendable () -> () + 28 13 Foundation 0x188bc2e1c __NSThread__block_start__ + 76 14 libsystem_pthread.dylib 0x18723df94 _pthread_start + 136 15 libsystem_pthread.dylib 0x187238d34 thread_start + 8 <snip>

I'm trying to digest and understand the new set of APIs relating age verification that were released last week. I have say that without some cohesive overview, example app, just a simple diagram showing the relationship of everything, its not at all clear to me what's going on nor what an app developer is expected to do to use these apis (I'm a senior engineer with 15 year's iOS experience, but hey maybe I'm just a bit slow in the head). I have a few questions, but the topic of this post is what is the relationship between age verification i.e. between the declared age range/significant change and Permission Kit? The documentation for the former mentions the Significant Change API/Topic (https://developer.apple.com/news/?id=2ezb6jhj / https://developer.apple.com/documentation/PermissionKit/SignificantAppUpdateTopic). Now the Significant Change Topic is documented as being part of PermissionKit, however the documentation for that (https://developer.apple.com/documentation/permissionkit) States emphatically at the top: "Communication experiences using the PermissionKit framework are only available using iMessage." Meaning you can't use PermissionKit for anything other than iMessage? If it doesn't mean that, then why does it state so? If it does mean that, then how does an app which has nothing to do with iMessage make use of Significant Change - because this documentation:https://developer.apple.com/news/?id=2ezb6jhj Is talking about using significant change for all apps, not iMessage. So there is a contradiction here.

I've been constantly having this problem for the past few months, using the various Xcode 15 betas and the iOS 17 betas, but the problem is still present with Xcode 15 release and iOS 17.0 release (and indeed with 17.1 beta). The issue is Xcode constantly says "Connecting to the phone" when attempting to run an iOS app from Xcode. Once it says this it never stop. Terminating and restarting Xcode doesn't fix it, disconnecting the phone and re-connecting doesn't fix it. If I restart the phone then Xcode will switch to saying "Preparing the phone" and it'll never stop saying that (even though the phone might have been attached for hours and has previously been prepared). I think the problem is actually iOS 17 or iOS 17 in combination with Xcode 15 because I don't have an issue with Xcode 15 and iOS versions less than 17. Nor in 13 years have I ever encountered a similar problem before. So for the past few months I've been avoiding using iOS 17 because of this issue it's literally impossible to develop. But it's becoming harder to avoid using iOS 17. So restarting the phone doesn't fix it, disconnecting the phone from the Mac doesn't fix it, restarting Xcode doesn't fix it. Are there suggestions for something else to try? Apple are there any logs I can get to provide you that will help diagnose this issue?

If Xcode is running lots of endless Socstream messages appear in the console: SocketStream read error [0x10cdb3c80]: 1 54 nw_protocol_socket_reset_linger [C172.1.1:1] setsockopt SO_LINGER failed [22: Invalid argument] SocketStream read error [0x10cc349e0]: 1 54 nw_protocol_socket_reset_linger [C174.1.1:1] setsockopt SO_LINGER failed [22: Invalid argument] SocketStream read error [0x10cd21fb0]: 1 54 nw_protocol_socket_reset_linger [C175.1.1:1] setsockopt SO_LINGER failed [22: Invalid argument] SocketStream read error [0x11b734fd0]: 1 54 nw_protocol_socket_reset_linger [C176.1.1:1] setsockopt SO_LINGER failed [22: Invalid argument] nw_socket_handle_socket_event [C177.1.1:1] Socket SO_ERROR [54: Connection reset by peer] nw_protocol_socket_reset_linger [C177.1.1:1] setsockopt SO_LINGER failed [22: Invalid argument] nw_socket_handle_socket_event [C179.1.1:1] Socket SO_ERROR [54: Connection reset by peer] nw_protocol_socket_reset_linger [C179.1.1:1] setsockopt SO_LINGER failed [22: Invalid argument] SocketStream read error [0x11b71b6b0]: 1 54 <snip> I'm running a React Native app and I think these might be due to the Metro connections. But they're very irritating and clog up the console making it difficult to see the app's own logging. Does anybody know if they can be made to shut up?

I want to observe/capture logging from my iPhone app when its not running via Xcode. However when using either the Mac's console app, or the console functionality within Apple Configurator, after about 2 or 3 seconds the logging disappears off the console. How can it be prevented from doing so?

I received an email from Apple saying the app is using: NSPrivacyAccessedAPICategoryDiskSpace NSPrivacyAccessedAPICategoryFileTimestamp NSPrivacyAccessedAPICategorySystemBootTime I'm not directly calling (afaik) any API that might be involved in getting the disk space, file timestamp, nor system boot time, so presumably these are indirectly originating in a pod whose api I'm using. However I have about 100 pods in the app, how can I know which one these are originating from? (100 seems a lot, but its a React Native app and that alone pulls in dozens and dozens of pods implicitly in addition those specified explicitly in a pod file) I can try and update all the pods to the latest version, but if the offending pod(s) hasn't added a manifest file, then I have no way of knowing which one it is - therefore I can neither contact them to ask when they will release a new version, nor can I attempt to try and remove the pod, because I just don't know which one might be causing the manifest warning. So what are we supposed to do in this situation?

If I run an app with a message filter extension on a phone with iOS 17.N then it works as expected. However if I run the same app (totally unchanged) on a phone with iOS 18 RC then there's multiple problems. I noticed there's no longer any logging from the extension in the Console (while there is for iOS 17 devices) in the messages app the filter sub categories aren't displayed (but they are on iOS 17 devices) if I try to debug the extension and place breakpoints in it, then there's an exception that occurs when the extension is enabled and the OS logs this (this doesn't occur with iOS 17 devices) '/private/preboot/Cryptexes/OS/usr/lib/swift/libswiftIdentityLookup.dylib' (no such file), '/usr/lib/swift/libswiftIdentityLookup.dylib' (no such file, not in dyld cache) I tried running on: iPhone with iOS 17.6 - no problems iPhone with iOS 18.1 beta - has all the above problems iPhone with iOS 18 RC - has all the above problems Was surprised the RC is so broken in this area as its release will be imminent. As things stand, I can't get a MFE to work at all with iOS 18. Anybody else with the same issues?

I experimented a lot with Live Caller ID when it first appeared with iOS 18 Beta. Now I'm starting to pick it up again and have immediately noticed some detrimental differences between the behavior observed when it was in beta status to how it currently behaves with iOS 18.3. The main difference is caching - if a call is made and data from a live call id lookup displayed on the call screen, then if the call is made again immediately then that data is re-fetched from the server. And it takes a long time too, about 5 or 6 seconds before the data is displayed in the call screen (with the beta it took about 3 seconds). In the data set cache_expiry_minutes is set to 50, yet it's not being honored, there's no caching occurring at all. Yet this did used to occur several months ago when the feature was in beta. What's happened to caching, why is it no longer working when it used to? Another change is there used to be a notification displayed when a call was blocked, this no longer is displayed. Is this an intentional change or a bug?

Trying to add some release test notes to a TestFlight build - but after clicking the blue save button nothing happens, nothing is saved. I tried with two different browsers and two different Apple accounts, same thing with both. Anybody else experiencing this issue?

What are guidelines for apps being released in the US App Store in order to comply with The Texas App Store Accountability Act? I mean there's no way to differentiate an app downloaded in Texas from the other states and it would be ridiculous to add location awareness to an app to comply with this, so effectively it means any developer of any app for release in the US must comply with this in case it might be being used in Texas? This new Apple API has zero background, zero context, zero example of usage, zero guidelines about how to use it in practice: https://developer.apple.com/documentation/declaredagerange/

I've got an iOS app with lots of extensions, some of them complex and doing a lot of stuff. After a bug I'd like to be able to use OSLogStore to get a holistic picture of logging for the app and its extensions and send that to a debugging server to retrospectively view logs for the app and its extensions. The constructor is OSLogStore.init(scope: OSLogStore.Scope), however scope only has one value .currentProcessIdentifier. Implying if that is called from within the app it can only get access to logging for its process only. I tried it out to confirm this is the case - if I log something in an extension (using Logger), then run the app with code like this:  let logStore = try! OSLogStore(scope: .currentProcessIdentifier)  let oneHourAgo = logStore.position(date: Date().addingTimeInterval(-3600)) let allEntries = try! logStore.getEntries(at: oneHourAgo)       for entry in allEntries { look at the content of the entry Then none of the entries are from the extension. Is there anyway from within the app I can access logging made within an extension?

This can easily be reproduced from scratch following these steps: Launch Xcode and choose to create a new iOS app. Organization name: com.company, ProductName:experiments. Therefore the bundle id is: com.company.experiments Create a background download target, productName:backgroundDownloadExtension. Therefore the bundle is is: com.company.experiments.backgroundDownloadExtension When Xcode creates the extension it automatically gives it a group capability with id: group.com.company.experiements. Within the signing & Capabilities section for the extension there is the following error: Within the developer portal, go to the Identifiers section, locate the main app bundle com.company.experiements. If not ticked, tick the App Groups capability. Click on edit, select group.com.company.experiments Within the developer portal Identifiers section, locate the extension bundle, com.company.experiments.backgroundDownloadExtension. Ensure the App Groups capability is ticked. Click on edit, select group.com.company.experiments. Like so for both the app and extension: Back in Xcode, for the app add the group capability, tick group.com.company.experiments. Now it matches the extension and will be like this for both of them: Quit and relaunch Xcode because Xcode is so unbelievably sticky and seems to cache everything, e-v-e-r-y-t-h-i-n-g, and millions of problems can be solved just by quitting/relaunching it. In the Signing & Capabilities section for the extension it still displays this: Back in the developer portal, create a provisioning profile for iOS development, choose the com.company.experiments bundle id, download it. Do likewise for the com.company.experiments.backgroundDownloadExtension After downloading, click on them both. Quit and re-lanch Xcode again. Any luck? No its still displaying the provisioning error. Ok, enough of Xcode's automatic management of signing. Let's turn that off and import the the extension provisioning profile that was just downloaded. Still getting this error: The entitlements file's contents are: <key>com.apple.security.application-groups</key> <array> <string>group.com.company.experiments</string> </array> The contents of the downloaded extension profile are: <key>Entitlements</key> <dict> <key>com.apple.security.application-groups</key> <array> <string>group.com.company.experiments</string> </array> <key>application-identifier</key> <string>MV8J9D3236.com.company.experiments.backgroundDownloadExtension</string> <key>keychain-access-groups</key> <array> <string>MV8J9D3236.*</string> <string>com.apple.token</string> </array> <key>get-task-allow</key> <true/> <key>com.apple.developer.team-identifier</key> <string>MV8J9D3236</string> </dict> I give up, how the hell can you create a background download extension without Xcode displaying the error?

A few days ago I uploaded a build to Testflight successfully. Just now I made absolutely no changes whatsoever other than to increment the build number. This latest build doesn't appear in Testflight. Tell me this can't be anything other than a bug with Testflight, if a build from a few days was good enough to appear, then how come with no changes it no longer is.

My app builds fine with Xcode 14, 13 and 12, but when attempting to build it with Xcode 15 there's an "Cycle inside MyApp; building could produce unreliable results." error. The output below isn't giving me any clues that I can see about what the cause of the cycle is nor how to fix it, any ideas? Cycle inside MyApp; building could produce unreliable results. Cycle details: → Target 'MyApp': ExtractAppIntentsMetadata ○ Target 'MyApp': CodeSign /Users/me/Library/Developer/Xcode/DerivedData/ProjectA-frqscjhianktlvbxgbzostesljpn/Build/Products/Debug-iphoneos/MyApp.app/Frameworks/3rdPartyFramework.framework ○ Target 'MyApp' has copy command from '/Users/me/Desktop/Checkouts/MyApp/theApp/MyApp/ios/3rdPartyFramework.framework' to '/Users/me/Library/Developer/Xcode/DerivedData/ProjectA-frqscjhianktlvbxgbzostesljpn/Build/Products/Debug-iphoneos/MyApp.app/Frameworks/3rdPartyFramework.framework' ○ Target 'MyApp' has copy command from '/Users/me/Library/Developer/Xcode/DerivedData/ProjectA-frqscjhianktlvbxgbzostesljpn/Build/Products/Debug-iphoneos/CallExtension.appex' to '/Users/me/Library/Developer/Xcode/DerivedData/ProjectA-frqscjhianktlvbxgbzostesljpn/Build/Products/Debug-iphoneos/MyApp.app/PlugIns/CallExtension.appex' ○ That command depends on command in Target 'MyApp': script phase “Add Git/CI Build Info” ○ Target 'MyApp' has process command with output '/Users/me/Library/Developer/Xcode/DerivedData/ProjectA-frqscjhianktlvbxgbzostesljpn/Build/Products/Debug-iphoneos/MyApp.app/Info.plist' ○ Target 'MyApp' has copy command from '/Users/me/Desktop/Checkouts/MyApp/theApp/MyApp/ios/3rdPartyFramework.framework' to '/Users/me/Library/Developer/Xcode/DerivedData/ProjectA-frqscjhianktlvbxgbzostesljpn/Build/Products/Debug-iphoneos/MyApp.app/Frameworks/3rdPartyFramework.framework' Raw dependency cycle trace: target: -> node: <all> -> command: <all> -> node: /Users/me/Library/Developer/Xcode/DerivedData/ProjectA-frqscjhianktlvbxgbzostesljpn/Build/Intermediates.noindex/ProjectA.build/Debug-iphoneos/MyApp.build/Objects-normal/arm64/ExtractedAppShortcutsMetadata.stringsdata -> command: P0:target-MyApp-2a7e5ca2b3fd2ca0faca1487721e3ae07ceb6b36bcfc2fb90f69ac96de4975d6-:Debug:ExtractAppIntentsMetadata -> node: <target-MyApp-2a7e5ca2b3fd2ca0faca1487721e3ae07ceb6b36bcfc2fb90f69ac96de4975d6--package-copy-files-phase> -> command: P0:::Gate target-MyApp-2a7e5ca2b3fd2ca0faca1487721e3ae07ceb6b36bcfc2fb90f69ac96de4975d6--package-copy-files-phase -> node: <target-MyApp-2a7e5ca2b3fd2ca0faca1487721e3ae07ceb6b36bcfc2fb90f69ac96de4975d6--fused-phase11-copy-files> -> command: P0:::Gate target-MyApp-2a7e5ca2b3fd2ca0faca1487721e3ae07ceb6b36bcfc2fb90f69ac96de4975d6--fused-phase11-copy-files -> node: <CodeSign /Users/me/Library/Developer/Xcode/DerivedData/ProjectA-frqscjhianktlvbxgbzostesljpn/Build/Products/Debug-iphoneos/MyApp.app/Frameworks/3rdPartyFramework.framework> -> command: P0:target-MyApp-2a7e5ca2b3fd2ca0faca1487721e3ae07ceb6b36bcfc2fb90f69ac96de4975d6-:Debug:CodeSign /Users/me/Library/Developer/Xcode/DerivedData/ProjectA-frqscjhianktlvbxgbzostesljpn/Build/Products/Debug-iphoneos/MyApp.app/Frameworks/3rdPartyFramework.framework -> node: <Copy /Users/me/Library/Developer/Xcode/DerivedData/ProjectA-frqscjhianktlvbxgbzostesljpn/Build/Products/Debug-iphoneos/MyApp.app/Frameworks/3rdPartyFramework.framework> -> CYCLE POINT -> command: P0:target-MyApp-2a7e5ca2b3fd2ca0faca1487721e3ae07ceb6b36bcfc2fb90f69ac96de4975d6-:Debug:Copy /Users/me/Library/Developer/Xcode/DerivedData/ProjectA-frqscjhianktlvbxgbzostesljpn/Build/Products/Debug-iphoneos/MyApp.app/Frameworks/3rdPartyFramework.framework /Users/me/Desktop/Checkouts/MyApp/theApp/MyApp/ios/3rdPartyFramework.framework -> node: <target-MyApp-2a7e5ca2b3fd2ca0faca1487721e3ae07ceb6b36bcfc2fb90f69ac96de4975d6--fused-phase10--cp--copy-pods-resources> -> command: P0:::Gate target-MyApp-2a7e5ca2b3fd2ca0faca1487721e3ae07ceb6b36bcfc2fb90f69ac96de4975d6--fused-phase10--cp--copy-pods-resources -> node: /Users/me/Library/Developer/Xcode/DerivedData/ProjectA-frqscjhianktlvbxgbzostesljpn/Build/Intermediates.noindex/ProjectA.build/Debug-iphoneos/MyApp.build/InputFileList-F72A917A68CD9152103DBA60-Pods-MyApp-resources-Debug-input-files-037b34732b45cb31a2dcb00ffdfe9f5c-resolved.xcfilelist -> command: P2:target-MyApp-2a7e5ca2b3fd2ca0faca1487721e3ae07ceb6b36bcfc2fb90f69ac96de4975d6-:Debug:WriteAuxiliaryFile /Users/me/Library/Developer/Xcode/DerivedData/ProjectA-frqscjhianktlvbxgbzostesljpn/Build/Intermediates.noindex/ProjectA.build/Debug-iphoneos/MyApp.build/InputFileList-F72A917A68CD9152103DBA60-Pods-MyApp-resources-Debug-input-files-037b34732b45cb31a2dcb00ffdfe9f5c-resolved.xcfilelist -> node: <target-MyApp-2a7e5ca2b3fd2ca0faca1487721e3ae07ceb6b36bcfc2fb90f69ac96de4975d6--fused-phase9--cp--embed-pods-frameworks> -> command: P0:::Gate target-MyApp-2a7e5ca2b3fd2ca0faca1487721e3ae07ceb6b36bcfc2fb90f69ac96de4975d6--fused-phase9--cp--embed-pods-frameworks -> node: /Users/me/Library/Developer/Xcode/DerivedData/ProjectA-frqscjhianktlvbxgbzostesljpn/Build/Intermediates.noindex/ProjectA.build/Debug-iphoneos/MyApp.build/InputFileList-7E0D6830477C665FCC1083CC-Pods-MyApp-frameworks-Debug-input-files-36820974ee8465975a73448c9644b936-resolved.xcfilelist -> command: P2:target-MyApp-2a7e5ca2b3fd2ca0faca1487721e3ae07ceb6b36bcfc2fb90f69ac96de4975d6-:Debug:WriteAuxiliaryFile /Users/me/Library/Developer/Xcode/DerivedData/ProjectA-frqscjhianktlvbxgbzostesljpn/Build/Intermediates.noindex/ProjectA.build/Debug-iphoneos/MyApp.build/InputFileList-7E0D6830477C665FCC1083CC-Pods-MyApp-frameworks-Debug-input-files-36820974ee8465975a73448c9644b936-resolved.xcfilelist -> node: <target-MyApp-2a7e5ca2b3fd2ca0faca1487721e3ae07ceb6b36bcfc2fb90f69ac96de4975d6--fused-phase8-upload-crashlytics> -> command: P0:::Gate target-MyApp-2a7e5ca2b3fd2ca0faca1487721e3ae07ceb6b36bcfc2fb90f69ac96de4975d6--fused-phase8-upload-crashlytics -> node: <target-MyApp-2a7e5ca2b3fd2ca0faca1487721e3ae07ceb6b36bcfc2fb90f69ac96de4975d6--fused-phase7-upload-debug-symbols-to-sentry> -> command: P0:::Gate target-MyApp-2a7e5ca2b3fd2ca0faca1487721e3ae07ceb6b36bcfc2fb90f69ac96de4975d6--fused-phase7-upload-debug-symbols-to-sentry -> node: <target-MyApp-2a7e5ca2b3fd2ca0faca1487721e3ae07ceb6b36bcfc2fb90f69ac96de4975d6--fused-phase6-crashlytics> -> command: P0:::Gate target-MyApp-2a7e5ca2b3fd2ca0faca1487721e3ae07ceb6b36bcfc2fb90f69ac96de4975d6--fused-phase6-crashlytics -> node: <target-MyApp-2a7e5ca2b3fd2ca0faca1487721e3ae07ceb6b36bcfc2fb90f69ac96de4975d6--fused-phase5-copy-files> -> command: P0:::Gate target-MyApp-2a7e5ca2b3fd2ca0faca1487721e3ae07ceb6b36bcfc2fb90f69ac96de4975d6--fused-phase5-copy-files -> node: <Copy /Users/me/Library/Developer/Xcode/DerivedData/ProjectA-frqscjhianktlvbxgbzostesljpn/Build/Products/Debug-iphoneos/MyApp.app/PlugIns/CallExtension.appex> -> <snip> too large to post all

If you create a CallKit extension with Xcode 15 beta, then add some logging to the template code that gets created and run it on an iOS 17.3 beta phone the logging clearly shows that the OS is running the extension twice when the user turns on the extension in Settings. Run it on any device with < iOS 17 and its only invoked once, as it should be. However, not only does the OS run it twice, but based on the logging the two invocations are in parallel, not serial, suggesting two CallDirectoryHandler instances are being created and run simultaneously.