LLDB crash

We are building an installer application to install a dext. Building in Xcode, the installer app launches fine locally and installs the dext. We then try to sign it with the company Developer ID application certificate. However after doing so we cannot launch the application anymore as we get the following crash at launch: Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: CODESIGNING 1 Taskgated Invalid Signature Triggered by Thread: 0 Thread 0 Crashed: 0 dyld_path_missing 0x102e187c0 _dyld_start + 0 Thread 0 crashed with ARM Thread State (64-bit): x0: 0x0000000000000000 x1: 0x0000000000000000 x2: 0x0000000000000000 x3: 0x0000000000000000 x4: 0x0000000000000000 x5: 0x0000000000000000 x6: 0x0000000000000000 x7: 0x0000000000000000 x8: 0x0000000000000000 x9: 0x0000000000000000 x10: 0x0000000000000000 x11: 0x0000000000000000 x12: 0x0000000000000000 x13: 0x0000000000000000 x14: 0x0000000000000000 x15: 0x0000000000000000 x16: 0x0000000000000000 x17: 0x00000000000

Hello, We have been encountering a persistent crash in our application, which is deployed exclusively on iPad devices. The crash occurs in the following code block: let requestHandler = ImageRequestHandler(paddedImage) var request = CoreMLRequest(model: model) request.cropAndScaleAction = .scaleToFit let results = try await requestHandler.perform(request) The client using this code is wrapped inside an actor, following Swift concurrency principles. The issue has been consistently reproduced across multiple iPadOS versions, including: iPad OS - 18.4.0 iPad OS - 18.4.1 iPad OS - 18.5.0 This is the crash log - Crashed: com.apple.VN.detectorSyncTasksQueue.VNCoreMLTransformer 0 libobjc.A.dylib 0x7b98 objc_retain + 16 1 libobjc.A.dylib 0x7b98 objc_retain_x0 + 16 2 libobjc.A.dylib 0xbf18 objc_getProperty + 100 3 Vision 0x326300 -[VNCoreMLModel predictWithCVPixelBuffer:options:error:] + 148 4 Vision 0x3273b0 -[VNCoreMLTransformer processRegionOfInterest:croppedPixelBuffer:options:q

I'm trying to update an old iOS app to use the UIScene architecture, and I've run into a problem I'm hoping somebody can help me fix. When I try to share a file with my app by AirDrop from another device, the URL that I'm getting from the urlContexts argument does not exist on the device. Here's the code I'm using in my SceneDelegate class to get things going: func scene(_ scene: UIScene, openURLContexts URLContexts: Set) { guard let url = URLContexts.first?.url else { os_log(URL in %@ is nil, #function) return } // check that it's the proper file type guard url.pathExtension == fileExtension.replacingOccurrences(of: ., with: ) else { return } ... } When I set a breakpoint after populating the url property, checking its existence in the Xcode Console reveals the enclosing folder does not exist: (lldb) po url.path /private/var/mobile/Library/Mobile Documents/com~apple~CloudDocs/Downloads/Seattle Times 2025-04-30 10.dbsud (lldb) po FileManager.default.fileExists(atPath: URL(filePath: /private/

I am building an application using .NET and Avalonia UI. The application is cross-platform. One of the tasks of the application is to coordinate data collection that is then routed into a Docker container for analysis. Everything works as expected in Windows. Everything works as expected in macOS on the development workstation and before packaging. After I package/codesign into a hardened runtime, I start seeing crashes at the moment when I try to execute the system calls to Docker. I am reasonably confident that this has something to do with an entitlement flag or some other permissions issue. I have been trying to sort this on my own for a while. I am only hoping someone can nudge me in the right direction. Thanks, Kevin

I have been developing an app for some time and tried distributing it via TestFlight to a couple of close friends but was getting crashes. It was an odd SwiftData Predicate thing that only showed up on TestFlight builds and not on builds downloaded from Xcode. Bottom line is I have created a whole bunch of unwanted version numbers thinking (incorrectly) that I needed to advance both the version number and the build number when uploading. The App has never been released so actually not even version 1.0 and I had created a bunch of versions all the way up to 1.11 before I realized my error. Now I am using a version 0.9 and just increasing the build number as I iterate thru external beta versions. The problem I have now is that TestFlight is still offering the version 1.11 build as the latest version to testers and I need to tell them how to ignore that go to the App in TestFlight and navigate to the Previous Builds under version 0.9 and download the latest build from there (this is tedious and confusin

This app will not crash when switching between these two tabs with TabView init(content:) import SwiftUI import SwiftData struct ContentView: View { @StateObject private var highlightManager = HighlightManager.shared @State private var selectedTab: Int = 0 var body: some View { TabView(selection: $selectedTab) { MapView() .tabItem { Label(Map, systemImage: map) } .tag(0) // Annotation Tab AnnotationList() .tabItem { Label(Annotation, systemImage: mappin.and.ellipse) } .tag(1) // Group Tab PeopleList() .tabItem { Label(Group, systemImage: person.and.person) } .tag(2) } .tutorialOverlay() // Apply the overlay to the root view .environmentObject(highlightManager) .toolbar { ToolbarItem(placement: .confirmationAction) { NavigationLink(Help) { NavigationStack { HelpView(selectedTab: selectedTab) } } } } } }

We have a crash on DCDevice.current.isSupported We want to try to make a serial queue to generate tokens but the side effect would be the same token would be used on multiple server API requests that are made within a few ms of each other? Is this safe or will the Apple server immediately reject the same token being reused? Can you share how long tokens are safe to use for? Here is the code we want to try final actor DeviceTokenController: NSObject { static var shared: DeviceTokenController = .init() private var tokenGenerationTask: Task? var ephemeralDeviceToken: Data? { get async { // Re-using the token for short periods of time if let existingTask = tokenGenerationTask { return await existingTask.value } let task = Task { guard DCDevice.current.isSupported else { return nil } do { return try await DCDevice.current.generateToken() } catch { Log(Failed to generate ephemeral device token, error) return nil } } tokenGenerationTask = task let result = await task.value tokenGenerationTask = nil return r

The steps to reproduce this issue are a bit complicated. In my app, previewing View A in Package P works fine, but another view in the same package fails to preview. The error message is shown below. It seems that the memory used for the preview is interfering with the shared memory area. This is reported as FB18519266 Exception Subtype: KERN_PROTECTION_FAILURE at 0x00000003402d8900 Exception Codes: 0x0000000000000002, 0x00000003402d8900 VM Region Info: 0x3402d8900 is in 0x3402c8000-0x340a18000; bytes after start: 67840 bytes before end: 7599871 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL mapped file 3401dc000-3402c8000 [ 944K] r-x/rwx SM=COW Object_id=57e4ac ---> shared memory 3402c8000-340a18000 [ 7488K] rw-/rw- SM=SHM mapped file 340a18000-340f38000 [ 5248K] r-x/rwx SM=COW Object_id=1dc9a049 Termination Reason: ****** 10 Bus error: 10 Terminating Process: exc handler [94787]

Issue Description We're experiencing a new recursive layout crash in UICollectionViewCompositionalLayout on iOS 26 Beta when using estimatedDimension. The same code works perfectly on iOS 18. Environment iOS 18.x: ✅ Works fine iOS 26 Beta: ❌ Crashes with layout feedback loop Crash Details Crash Report Console Log Code Question Is this an intentional change in iOS 26? Are there new best practices for using estimatedDimension in compositional layouts? Temporary Workaround Using absoluteDimension instead of estimatedDimension resolves the crash, but we lose dynamic sizing capabilities.