I have had the same issue. I had previously followed some guidance to create a store configuration file and update my product scheme. When I removed the file and set scheme to none, the subscription service worked with groupID and productIDs. Hope this helps.

Full content of Thread 3: Thread 3 name: com.apple.SwiftUI.AsyncRenderer Thread 3 Crashed: 0 libsystem_kernel.dylib 0x1e274162c _kernelrpc_mach_port_allocate_trap + 8 1 libsystem_kernel.dylib 0x1e2748478 mach_port_allocate + 36 2 QuartzCore 0x192d4552c CA::Context::commit_transaction(CA::Transaction*, double, double*) + 13596 3 QuartzCore 0x192cb8d58 CA::Transaction::commit() + 648 4 QuartzCore 0x192cb8764 CA::Transaction::flush_as_runloop_observer(bool) + 88 5 CoreFoundation 0x19119f894 CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION + 36 6 CoreFoundation 0x19119f3e8 __CFRunLoopDoObservers + 552 7 CoreFoundation 0x1912462c0 CFRunLoopRunSpecific + 664 8 Foundation 0x18fdc8338 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212 9 Foundation 0x18fdc4500 -[NSRunLoop(NSRunLoop) run] + 64 10 SwiftUI 0x195c276d8 specialized static DisplayLink.asyncThread(arg:) + 792 11 SwiftUI 0x195c273a8 @objc static DisplayLink.asyncThread(arg:) + 72 12 Foundation 0x18feb4194 NSThread__start + 724 13 libsystem_pthread.dylib 0x21bcfb7d0 _pthread_start + 136 14 libsystem_pthread.dylib 0x21bcfb480 thread_start + 8

I have a similar issue, it refers to my Thread 3 which is com.apple.SwiftUI.AsyncRenderer which could be something to do with animation?? (CA::Context::commit_transaction(CA::Transaction*, double, double*) + 13596) I have edited out the following two lines of code and will monitor for a few days for repeat crashes. .rotationEffect(.degrees(rotate ? 0 : 360)) .animation(.linear(duration: 40).repeatForever(autoreverses: false), value: rotate) Here's the Thread three stack: Thread 3 name: com.apple.SwiftUI.AsyncRenderer Thread 3 Crashed: 0 libsystem_kernel.dylib 0x1e274162c _kernelrpc_mach_port_allocate_trap + 8 1 libsystem_kernel.dylib 0x1e2748478 mach_port_allocate + 36 2 QuartzCore 0x192d4552c CA::Context::commit_transaction(CA::Transaction*, double, double*) + 13596 3 QuartzCore 0x192cb8d58 CA::Transaction::commit() + 648 4 QuartzCore 0x192cb8764 CA::Transaction::flush_as_runloop_observer(bool) + 88 5 CoreFoundation 0x19119f894 CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION + 36 6 CoreFoundation 0x19119f3e8 __CFRunLoopDoObservers + 552 7 CoreFoundation 0x1912462c0 CFRunLoopRunSpecific + 664 8 Foundation 0x18fdc8338 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212 9 Foundation 0x18fdc4500 -[NSRunLoop(NSRunLoop) run] + 64 10 SwiftUI 0x195c276d8 specialized static DisplayLink.asyncThread(arg:) + 792 11 SwiftUI 0x195c273a8 @objc static DisplayLink.asyncThread(arg:) + 72 12 Foundation 0x18feb4194 NSThread__start + 724 13 libsystem_pthread.dylib 0x21bcfb7d0 _pthread_start + 136 14 libsystem_pthread.dylib 0x21bcfb480 thread_start + 8

Hi, Thank you for replying. I managed to import the ops file into the device & sim and I think it's converted it into symbolic format. The three most recent crashes all point to the CMAltimeter thread. I will comment out all reference to CMAltimeter and see if the App functions without crash. Reading the link you sent "Crash reports have two common extensions: .crash and .ips. If you have an .ips file, please post that [1]." I have ips and renamed it .json so I could upload it. ExcResource.json , hence the post. Exception Type: EXC_RESOURCE (SIGKILL) Exception Codes: 0x0000000000020000, 0x0000000000000000 Termination Reason: PORT_SPACE 14123288431434006528 (Limit 131072 ports) Exceeded system-wide per-process Port Limit Triggered by Thread: 5 Thread 5 name: Dispatch queue: com.apple.CoreMotion.CMAltimeterInternalQueue Thread 5 Crashed: 0 libsystem_kernel.dylib 0x1e2741788 mach_msg2_trap + 8 1 libsystem_kernel.dylib 0x1e2744e98 mach_msg2_internal + 80 2 libsystem_kernel.dylib 0x1e2744db0 mach_msg_overwrite + 424 3 libsystem_kernel.dylib 0x1e2744bfc mach_msg + 24 4 libxpc.dylib 0x21bd6ef40 _xpc_pipe_mach_msg + 56 5 libxpc.dylib 0x21bd6e3c8 _xpc_pipe_routine + 392 6 libxpc.dylib 0x21bd495ac _xpc_interface_routine + 204 7 libxpc.dylib 0x21bd49cc0 _xpc_look_up_endpoint + 268 8 libxpc.dylib 0x21bd53974 _xpc_connection_bootstrap_look_up_slow + 296 9 libxpc.dylib 0x21bd57bc4 _xpc_connection_init + 1000 10 libxpc.dylib 0x21bd54100 _xpc_connection_activate_if_needed + 452 11 libxpc.dylib 0x21bd55544 xpc_connection_resume + 96 12 LocationSupport 0x1b2a7c970 CLConnection::start() + 76 13 LocationSupport 0x1b2a7f0e8 0x1b2a75000 + 41192 14 libdispatch.dylib 0x198f2d248 _dispatch_call_block_and_release + 32 15 libdispatch.dylib 0x198f2efa8 _dispatch_client_callout + 20 16 libdispatch.dylib 0x198f365cc _dispatch_lane_serial_drain + 768 17 libdispatch.dylib 0x198f37124 _dispatch_lane_invoke + 380 18 libdispatch.dylib 0x198f4238c _dispatch_root_queue_drain_deferred_wlh + 288 19 libdispatch.dylib 0x198f41bd8 _dispatch_workloop_worker_thread + 540 20 libsystem_pthread.dylib 0x21bcfd680 _pthread_wqthread + 288 21 libsystem_pthread.dylib 0x21bcfb474 start_wqthread + 8

Hi, I can confirm that by commenting out the follow lines of code the app no longer crashes... I can only therefore conclude that the CMAltimeter is eating up all the system-wide per-process ports(?). Any ideas why this could be...? if(CMAltimeter.isRelativeAltitudeAvailable()) { altimeter.startRelativeAltitudeUpdates(to: OperationQueue.current!, withHandler: { data, error in if !(error != nil) { DispatchQueue.main.async { appData.recordPressure(value: Double(truncating: data!.pressure) * 10) } } }) }

Hi Quinn, I tried your suggestion overnight with Dispatch and recordPressure lines commented out. But... the app crashed again. Could it be something to do with the use of a CMAltimeter State variable: @State private var altimeter: CMAltimeter = CMAltimeter() I comment this line out too when I comment out the function block. Should CMAltimeter not be held as a State variable, but referenced directly? Thanks, Brendan Here is the relevant crash report: Thread 8 name: Dispatch queue: com.apple.CoreMotion.CMAltimeterInternalQueue Thread 8 Crashed: 0 libsystem_kernel.dylib 0x1e2f90788 mach_msg2_trap + 8 1 libsystem_kernel.dylib 0x1e2f93e98 mach_msg2_internal + 80 2 libsystem_kernel.dylib 0x1e2f93db0 mach_msg_overwrite + 424 3 libsystem_kernel.dylib 0x1e2f93bfc mach_msg + 24 4 libxpc.dylib 0x21c645f30 _xpc_pipe_mach_msg + 56 5 libxpc.dylib 0x21c6453b8 _xpc_pipe_routine + 392 6 libxpc.dylib 0x21c6204e0 _xpc_interface_routine + 204 7 libxpc.dylib 0x21c620c00 _xpc_look_up_endpoint + 268 8 libxpc.dylib 0x21c62a8b4 _xpc_connection_bootstrap_look_up_slow + 296 9 libxpc.dylib 0x21c62eb04 _xpc_connection_init + 1000 10 libxpc.dylib 0x21c62b040 _xpc_connection_activate_if_needed + 452 11 libxpc.dylib 0x21c62c484 xpc_connection_resume + 96 12 LocationSupport 0x1b324e978 CLConnection::start() + 76 13 LocationSupport 0x1b32510f0 0x1b3247000 + 41200 14 libdispatch.dylib 0x1995f9248 _dispatch_call_block_and_release + 32 15 libdispatch.dylib 0x1995fafa8 _dispatch_client_callout + 20 16 libdispatch.dylib 0x1996025cc _dispatch_lane_serial_drain + 768 17 libdispatch.dylib 0x199603124 _dispatch_lane_invoke + 380 18 libdispatch.dylib 0x19960e38c _dispatch_root_queue_drain_deferred_wlh + 288 19 libdispatch.dylib 0x19960dbd8 _dispatch_workloop_worker_thread + 540 20 libsystem_pthread.dylib 0x21c5d4680 _pthread_wqthread + 288 21 libsystem_pthread.dylib 0x21c5d2474 start_wqthread + 8

Hi Quinn, resolved... I can report that removing: @State var altimeter: CMAltimeter = CMAltimeter() ...and referring to CMAltimeter directly has not resulted in a further crash. I'm not sure I fully understand why this would have caused an issue. Is this because CMAltimeter isn't a class that needs to be instantiated but rather a persistent service in its own right. Does this apply equally to CLLocationManager() and CMMotionManager() etc. How do I determine the difference between a persistent service and a structure/class? Thanks, Brendan

Bug FB16534793 reported.

ps - Great support, thank you!

Hi, thanks for the reply, The weird thing is the code used to work until I upgraded to ios26 beta The code is pretty standard: Button(action: { showAlert1 = true }) { HStack { Image(systemName: "arrow.up.square") .resizable() .scaledToFit() .frame(width: 24, height: 24) } } .alert(isPresented: $showAlert1) { Alert( title: Text("Title"), message: Text("Message"), primaryButton: .default(Text("Yes")) { impactMed.impactOccurred() appData.showRoleView = false }, secondaryButton: .cancel() ) }

Hello Engineer, thank you for your helpful reply. we are on the water on a boat near the coast. The sky is clear and there are no obstructions. We (and others) have noticed that the phone location jumps from the gps location to a nearby location, last time this was 144m away with 9m accuracy. We rely on accurate gps location for safety and critical alerts. The incorrect gps location is always on shore. We have determined (old location to new location distance and time hence) speed and if it’s great than 10m/s it’s a false signal and we wait for a good signal. Nothing on the phone appears to change to trigger the jump, nothing physical either.

Hello Engineer, thank you again for your reply. I’ve been travelling so please excuse my delayed reply. yes the boat is floating around very slowly, often 100-400m from shore. im using clservicesession .whenInUse and have not specified an activity type. Is this even possible? if for whatever reason I get no update from clservicesession for more than 30s I trigger a get current location using cllocationmanager .requestLocation using bestForNavigation but haven’t specified an activity type. My log above suggests that it’s this service that has triggered the jump. The hard thing about diagnostic report is catching the jump, the phone can be actively monitoring location as required for 8h then jumps, it could come down to low satellites in orbit, but the phone remains unmoved connected to power in foreground for the duration. i’ll do more research on activity type for clservicesession and clLocationManager and try and get more diagnostics. thank you, Brendan

Hi, Hello, I’ve done two things… 1) connected a garmin glo 2 gps device via Bluetooth. This improves gps accuracy but still we see a bias towards the road in clservicesessio, how do I specify a marine activity type?. See image. And 2) monitored behaviour from other users who also report the same location behaviour across multiple apps including Apple Maps. This is a real problem for safety. Can you help? thank you,

Any update?

Hi Engineer, I also wanted to add that I can confirm that activityType .otherNavigation was always set via: @State var updates = CLLocationUpdate.liveUpdates(.otherNavigation) Recap: The device "jumps" 50 or more meters from the boat to a false location, often on shore giving a false warning. And later jumps back. The jump is also seen on apple apps such as findmy or maps. I have determined a way to detect these jumps by calculating the speed between two consecutive updates... if it's greater than 10m/s then it must be false, and we wait for a return. The device has a clear unobstructed view of the sky and no nearby buildings, and is slowly floating around. The app remains in foreground. Any further ideas would be appreciated. Kind regards, Brendan Thank you for your help again.