Yep, can confirm. The crash also happens with https://self-signed.badssl.com and Safari in iOS 18 Simulator as well. ------------------------------------- Translated Report (Full Report Below) ------------------------------------- Incident Identifier: 36B8315F-3E60-42B7-916D-065F086EBD72 CrashReporter Key: 04C62978-9A1D-1A77-A4F6-DFF0BC1DED4F Hardware Model: MacBookPro18,1 Process: com.apple.WebKit.Networking [94891] Path: /Volumes/VOLUME/*/com.apple.WebKit.Networking Identifier: com.apple.WebKit.Networking Version: 8619.1.26.30.5 Code Type: ARM-64 (Native) Role: Foreground Parent Process: launchd_sim [8677] Coalition: com.apple.CoreSimulator.SimDevice.C6C4E44A-C067-4EEB-8AC9-E005CAF2F64D [1737] Responsible Process: SimulatorTrampoline [1296] Date/Time: 2024-10-01 13:17:44.2053 +0200 Launch Time: 2024-10-01 13:16:04.7324 +0200 OS Version: macOS 14.5 (23F79) Release Type: User Report Version: 104 Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Subtype: KERN_INVALID_ADDRESS at 0x0000814185deda10 -> 0x0000014185deda10 (possible pointer authentication failure) Exception Codes: 0x0000000000000001, 0x0000814185deda10 VM Region Info: 0x14185deda10 is not in any region. Bytes after previous region: 899894139409 Bytes before following region: 104172185789936 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL commpage (reserved) 1000000000-7000000000 [384.0G] ---/--- SM=NUL reserved VM address space (unallocated) ---> GAP OF 0x5f9000000000 BYTES MALLOC_NANO 600000000000-600020000000 [512.0M] rw-/rwx SM=PRV Termination Reason: SIGNAL 11 Segmentation fault: 11 Terminating Process: exc handler [94891] Triggered by Thread: 4 Thread 0: 0 libsystem_pthread.dylib 0x10f41e5cc start_wqthread + 0 Thread 1:: com.apple.NSURLConnectionLoader 0 libsystem_kernel.dylib 0x10f2e1570 mach_msg2_trap + 8 1 libsystem_kernel.dylib 0x10f2f2b80 mach_msg2_internal + 76 2 libsystem_kernel.dylib 0x10f2e9798 mach_msg_overwrite + 532 3 libsystem_kernel.dylib 0x10f2e18e8 mach_msg + 20 4 CoreFoundation 0x1096e3b60 __CFRunLoopServiceMachPort + 156 5 CoreFoundation 0x1096de224 __CFRunLoopRun + 1160 6 CoreFoundation 0x1096dd960 CFRunLoopRunSpecific + 536 7 CFNetwork 0x104d37510 +[__CFN_CoreSchedulingSetRunnable _run:] + 372 8 Foundation 0x101be3d6c __NSThread__start__ + 720 9 libsystem_pthread.dylib 0x10f423414 _pthread_start + 104 10 libsystem_pthread.dylib 0x10f41e5e0 thread_start + 8 Thread 2:: JavaScriptCore libpas scavenger 0 libsystem_kernel.dylib 0x10f2e4a70 __psynch_cvwait + 8 1 libsystem_pthread.dylib 0x10f4239cc _pthread_cond_wait + 1216 2 JavaScriptCore 0x118bbd1e0 scavenger_thread_main + 1148 3 libsystem_pthread.dylib 0x10f423414 _pthread_start + 104 4 libsystem_pthread.dylib 0x10f41e5e0 thread_start + 8 Thread 3: 0 libsystem_pthread.dylib 0x10f41e5cc start_wqthread + 0 Thread 4 Crashed:: Dispatch queue: com.apple.NWURLSession 0 libobjc.A.dylib 0x100895f74 objc_autoreleaseReturnValue + 88 1 Network 0x1167f8bc0 -[NWURLErrorUserInfoDictionary objectForKey:] + 112 2 CoreFoundation 0x10977bfc8 -[NSDictionary getObjects:andKeys:count:] + 208 3 CoreFoundation 0x1096ccc8c __NSDictionaryEnumerate + 588 4 CoreFoundation 0x10977dbf8 -[NSDictionary __apply:context:] + 96 5 CoreFoundation 0x10969f95c _CFErrorFormatDebugDescriptionAux + 564 6 CoreFoundation 0x10969fae8 _CFErrorCreateRedactedDescription + 84 7 Foundation 0x101b02638 -[NSError redactedDescription] + 12 8 Foundation 0x101b94794 _NS_os_log_callback + 224 9 libsystem_trace.dylib 0x10f34e8c8 _os_log_fmt_flatten_NSCF + 60 10 libsystem_trace.dylib 0x10f34e154 _os_log_fmt_flatten_object_impl + 164 11 libsystem_trace.dylib 0x10f35d288 _os_log_impl_flatten_and_send + 1892 12 libsystem_trace.dylib 0x10f35cb0c _os_log + 164 13 libsystem_trace.dylib 0x10f35f6d8 _os_log_impl + 20 14 Network 0x1165124d8 -[NWURLSessionTask complete] + 700 15 Network 0x11650d900 -[NWURLSessionTask completeTaskWithError:] + 184 16 Network 0x1165137d0 __32-[NWURLSessionTask readResponse]_block_invoke + 456 17 Network 0x116781158 __31-[NWURLLoaderHTTP readResponse]_block_invoke + 3504 18 libdispatch.dylib 0x10e9cb594 _dispatch_block_async_invoke2 + 104 19 libdispatch.dylib 0x10e9bbde0 _dispatch_client_callout + 16 20 libdispatch.dylib 0x10e9c3f60 _dispatch_lane_serial_drain + 956 21 libdispatch.dylib 0x10e9c4a98 _dispatch_lane_invoke + 388 22 libdispatch.dylib 0x10e9c58e4 _dispatch_workloop_invoke + 776 23 libdispatch.dylib 0x10e9cff44 _dispatch_root_queue_drain_deferred_wlh + 276 24 libdispatch.dylib 0x10e9cf5a0 _dispatch_workloop_worker_thread + 440 25 libsystem_pthread.dylib 0x10f41f814 _pthread_wqthread + 284 26 libsystem_pthread.dylib 0x10f41e5d4 start_wqthread + 8 Thread 5: 0 libsystem_pthread.dylib 0x10f41e5cc start_wqthread + 0 Thread 6: 0 libsystem_pthread.dylib 0x10f41e5cc start_wqthread + 0 Thread 7: 0 libsystem_pthread.dylib 0x10f41e5cc start_wqthread + 0 Thread 8: 0 libsystem_pthread.dylib 0x10f41e5cc start_wqthread + 0

We've consistently been experiencing review times taking excessively long time recently where as colleagues see an app go through review within 1 hour. Our latest submitted update was rejected, then we replied with requested information but there's been no reply since Monday last week. We then requested expedited review Sunday midday, which was confirmed and accepted in the evening but lo and behold... we're still waiting and our deadline was this morning. To say it's frustrating is an understatement. Meanwhile our colleagues in Google land had their app processed and rejected within hours and after explaining the usage of the new feature, got through review and released soon after.

I am experiencing the same... exact same simulator version. Have you created a ticket yet?

The issue (that we were having) seems to be have been fixed with Xcode 13.1. Our build server which is running mac OS 11.5.2, updated Xcode to 13.1 yesterday, and now our .ipa are being properly signed. It would have been nice if the release notes addressed this though...

@meaton I can reproduce the same thing on my end in Big Sur with Xcode 12.5, i.e., the outer iOS signature containing the hashed DER entitlements while the inner signature does not contain these entitlements on the watchOS executable (and possibly the watchOS App Extension Executable). You can work around this by adding the --generate-entitlement-der flag to Xcode build settings for Other Code Signing Flags in the watchOS target(s) ane then building the outer iOS app again in Xcode. Then, if you look through the signatures on the executables, you will see the DER hash slot available. Strange, I have already tried to add --generate-entitlement-der and --preserve-metadata to the xcode project file, so all my targets currently has the params set, but I cannot reproduce your success scenario. The only workaround that has been working for me for now is manually signing. In no case do I get an .ipa where the watch app or extension has the correct signature.

@meaton After taking a closer look, I see the same as @sponlingam, except we build on big sur, so I'd expect it to sign the watch properly, since it does it correctly for the iOS app. The watch and extension does not have 6-7 signature.. why though? is this an xcode bug? if so.. when can we expect to see this fixed? This is what the watch signature looks like after archiving through both xcode 12.5.1 and xcode 13: Page size=4096 -5=b913d5b0ef9ff48816f16a42342ab0037740a6153282266b7935458e6f55d9ab -4=0000000000000000000000000000000000000000000000000000000000000000 -3=4f2a93c3945beb4b402e6bcad790b4b4c2cff641a50a758b6f3b37ca28a89e6a -2=516af77f9e299974d68307536ce805fdd9619a4c0cfd8c53d978f6b2bbbce81b Signature size=4821 After I run codesign manually though, it looks correct... so I suspect that Xcode is for some reason not adding all the relevant params to the watch and extension. I even tried to force the same params in xcode and from what I can see, it does the same... Taken from the build log: /usr/bin/codesign --force --sign <redacted> --preserve-metadata --generate-entitlement-der --preserve-metadata=identifier,entitlements /path/to/*.framework Yet the signature is still wrong, however if I paste the exact same into terminal after archiving, then it seems to sign it properly. I guess the next step would be to create a dummy project and see if I can reproduce, so I can make a proper TSI...

I've been following this thread, having a similar issue with our watch extension app that suddenly stopped working when our testers updated their iOS device to iOS 15 and watch to Watch OS 8. So far I've recreated new provisioning profiles, verified that the codesign looks similar to what is suggested, seen that there's a DER-profile entry in the provisioning profile and also tried adding --generate-entitlement-der to build settings. Still, building the app for enterprise and installing it works on the iOS device but the embedded watch app does not. When you try to install it from the iOS watch.app, then it fails with "could not install the app at this time" And the error we get is: 0x170053000 -[ACXInstallQueue _onQueue_deQueueNextOperation]_block_invoke_2: Failed to install app my.test.app (p = N, ui = Y) : Error Domain=ACXErrorDomain Code=17 "Got error 17 in install done from remote side (MI error ApplicationVerificationFailed ; Extended 0xe8008029 ; Desc Failed to verify code signature of /var/installd/Library/Caches/com.apple.mobile.installd.staging/temp.y3l1mI/extracted/Payload/Watch.app : 0xe8008029 (The code signature version is no longer supported.))" UserInfo={SourceFileLine=646, NSLocalizedDescription=Got error 17 in install done from remote side (MI error ApplicationVerificationFailed ; Extended 0xe8008029 ; Desc Failed to verify code signature of /var/installd/Library/Caches/com.apple.mobile.installd.staging/temp.y3l1mI/extracted/Payload/Watch.app : 0xe8008029 (The code signature version is no longer supported.)), FunctionName=-[ACXServerInstallOperation receivedDictionaryOrData:]} Which indicates that the wrong provisioning profile is used but that doesn't seem to be the case. Our page size: Page size=4096 -7=8d48d5d98df3b77ce25ac0b1ad03b1d4f50e23d7e377979e409b107324e18266 -6=0000000000000000000000000000000000000000000000000000000000000000 -5=4146cb67c2b6ce380836b0f27ac5760098b8a1af18608163202fd0a9d961d29d -4=0000000000000000000000000000000000000000000000000000000000000000 -3=e722d3b1b52761052da2177e2b81de694bec9d06dab31ad57519afca738d4e6e -2=4b1957d850c9cd59d4a501d12adc7db5ffc46fd3a68f0f7cb7665edc2be308dd CodeDirectory v=20400 Like I mentioned, the iOS app works fine, it's only the watch extension app that doesn't launch. I've tried to build the app on Xcode 12.5.1 and Xcode 13 and the machine is running Mac OS Big Sur. I am not sure what else to try, any ideas?