Thanks for your explanations. Is the unmapped memory exception also the reason why the binary image address for my app is 0x0 - 0xffffffffffffffff? I can confirm that the app registers for volume notifications using let workspaceNotificationCenter = NSWorkspace.shared.notificationCenter workspaceNotificationCenter.addObserver(self, selector: #selector(didWake(_:)), name: NSWorkspace.didWakeNotification, object: nil) workspaceNotificationCenter.addObserver(self, selector: #selector(volumeDidMount(_:)), name: NSWorkspace.didMountNotification, object: nil) workspaceNotificationCenter.addObserver(self, selector: #selector(volumeDidRename(_:)), name: NSWorkspace.didRenameVolumeNotification, object: nil) workspaceNotificationCenter.addObserver(self, selector: #selector(volumeWillUnmount(_:)), name: NSWorkspace.willUnmountNotification, object: nil) workspaceNotificationCenter.addObserver(self, selector: #selector(volumeDidUnmount(_:)), name: NSWorkspace.didUnmountNotification, object: nil) The object that registers them also unregisters them in its deinit: NSWorkspace.shared.notificationCenter.removeObserver(self) Admittedly, I'm not sure if the unregistration works or if the deinit is prevented from being called by the notification center retaining the observer. I mainly added that code for "completeness", but in reality the observer is a let property of the app delegate, so it lives as long as the app lives. Besides, the unregistration seems to be superfluous according to the documentation: If your app targets iOS 9.0 and later or macOS 10.11 and later, you do not need to unregister an observer that you created with this function. If you forget or are unable to remove an observer, the system cleans up the next time it would have posted to it. I also wasn't able to reproduce the crash with the tools you suggested, and I don't think I have seen this kind of crash before (my app has been on the App Store for many years). Does this rule out the first most likely cause and shifts "Something has corrupted memory" from suspect number two to number one?

That mapping size 0x0029a000 is 2'727'936 in decimal, so I would say about 2.7 MB? The newest app version contains a Contents/MacOS/MyApp executable of 6’231’472 bytes (I'm assuming that's what you mean by Mach-O image). I just noticed that the crash report only displays three question marks instead of the app version, but the user wrote to me that they started testing the app so I assume they have one of the newest versions, which are all about the same size.

Thanks for your input. I added the following code in the arView.renderCallbacks.postProcess callback: let depthStencilDescriptor = MTLTextureDescriptor() depthStencilDescriptor.pixelFormat = .depth32Float_stencil8 depthStencilDescriptor.width = context.targetColorTexture.width depthStencilDescriptor.height = context.targetColorTexture.height depthStencilDescriptor.usage = .renderTarget depthStencilDescriptor.storageMode = .private renderPassDescriptor.stencilAttachment.texture = device!.makeTexture(descriptor: depthStencilDescriptor) renderPassDescriptor.stencilAttachment.loadAction = .clear renderPassDescriptor.stencilAttachment.storeAction = .dontCare renderPassDescriptor.stencilAttachment.clearStencil = 0 but the app now crashes with error Assertion failed: (destDepthFormat == jet_texture_format_DepthStencil), function create_render_mode, file jet_context_Metal.mm, line 895. VTPixelTransferSession 420f sid 494 (512.00 x 512.00) [0.00 0.00 512 512] rowbytes( 512, 512 ) Color( kCGColorSpaceSRGB, 0x0, (null), (null), ITU_R_601_4 ) => BGRA sid 554 (512.00 x 512.00) [0.00 0.00 512 512] rowbytes( 2048 ) Color( 0x0, (null), (null), (null) ) which again I have no idea what it means.

When running those commands on my M1 Mac I get this: % file /Applications/MyApp.app/Contents/MacOS/MyApp /Applications/MyApp.app/Contents/MacOS/MyApp: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64] /Applications/MyApp.app/Contents/MacOS/MyApp (for architecture x86_64): Mach-O 64-bit executable x86_64 /Applications/MyApp.app/Contents/MacOS/MyApp (for architecture arm64): Mach-O 64-bit executable arm64 and % otool -f /Applications/MyApp.app/Contents/MacOS/MyApp Fat headers fat_magic 0xcafebabe nfat_arch 2 architecture 0 cputype 16777223 cpusubtype 3 capabilities 0x0 offset 16384 size 3190880 align 2^14 (16384) architecture 1 cputype 16777228 cpusubtype 0 capabilities 0x0 offset 3211264 size 3069792 align 2^14 (16384) and ... ==== Non-writable regions for process 14835 REGION TYPE START - END [ VSIZE RSDNT DIRTY SWAP] PRT/MAX SHRMOD PURGE REGION DETAIL __TEXT 10061c000-1008a0000 [ 2576K 2048K 0K 0K] r-x/r-x SM=COW /Applications/MyApp.app/Contents/MacOS/MyApp __DATA_CONST 1008a0000-1008b0000 [ 64K 64K 64K 0K] r--/rw- SM=COW /Applications/MyApp.app/Contents/MacOS/MyApp __LINKEDIT 1008f0000-100928000 [ 224K 80K 0K 0K] r--/r-- SM=COW /Applications/MyApp.app/Contents/MacOS/MyApp ... The range of the __TEXT segment 10061c000-1008a0000 has length 0x0284000 (hex) = 2637824 (decimal). But the crash report mentions the architexture x86_64, which I don't own myself anymore. I don't know if it makes sense to do so, but by using the formula arm64 __TEXT segment size / arm64 Mach-O size * x86_64 Mach-O size we get 2637824 / 3069792 * 3190880 =~ 2’741’873 ... which is about the previously mentioned 2'727'936?

I enabled the option "Open with Rosetta" in the Finder info panel, double clicked the app to open it, and ran the vmmap command again: ==== Non-writable regions for process 18183 REGION TYPE START - END [ VSIZE RSDNT DIRTY SWAP] PRT/MAX SHRMOD PURGE REGION DETAIL __TEXT 10499d000-104c3d000 [ 2688K 628K 0K 0K] r-x/r-x SM=COW /Applications/MyApp.app/Contents/MacOS/MyApp If my calculations are correct, the range length now is 2'752'512 (decimal) (not quite the 2'727'936 from the crash report, but almost).

I just realized I opened the wrong app. I just tried again with the correct one: ==== Non-writable regions for process 18270 REGION TYPE START - END [ VSIZE RSDNT DIRTY SWAP] PRT/MAX SHRMOD PURGE REGION DETAIL __TEXT 10462e000-1048c8000 [ 2664K 348K 0K 0K] r-x/r-x SM=COW /Applications/MyApp.app/Contents/MacOS/MyApp Now the range length is 2'727'936 which is exactly what's mentioned in the crash report.

I was expecting some kind of continuation to this: So memory is mapped at your address but the crash report isn’t able to identify it. Notably, this memory is mapped r-x, suggesting it’s an executable. Does the size of that mapping (so, 0x10852e000-0x108294000 which equals 0x0029a000) match the size of any Mach-O image within this version of your app? Now that the question is answered, how does the original story continue?

Thanks. I wasn't sure what I should use as the load address for the atos command. I used the start address of the __TEXT segment, but I just got the crash address back: % atos -arch x86_64 -o ~/Library/Developer/Xcode/Archives/2026-02-03/MyApp\ 03.02.2026\,\ 13.48.xcarchive/dSYMs/MyApp.app.dSYM/Contents/Resources/DWARF/MyApp -l 0x10462e000 0x10844eb40 0x10844eb40 Although notice that the range of __TEXT 10462e000-1048c8000 doesn't even contain the crash address 0x10844eb40. Unless I'm doing something wrong, it looks to me like the crash is out of my control and I can't really do anything about it, which like you said is kind of confirmed by the weird crash report.

Thanks for sharing your fix. My own fix was to keep a single localized string without a default value, forcing the en.lproj folder to be created. I'd still like Apple to confirm whether this is indeed a bug.

Thanks for confirming. This is unexpected because from the documentation it sounds like only the provided UTIs are allowed by the document picker; there's no mention of the Info.plist types. Is there no way of allowing the user to select only the provided UTIs? On macOS, regardless what document types the Info.plist contains, using the following code only allows to select folders: let openPanel = NSOpenPanel() openPanel.allowedContentTypes = [.folder] openPanel.runModal()

Thanks for the information. The user who reported this issue replied that they weren't able to reproduce it for some time now.

FB22393546

Thanks for your help. Now the app doesn't crash anymore, but the colours of textures shown in SKSpriteNode are a little bit off. To reproduce this, add the below image as a new image resource named "blue" in the Xcode project. It contains a single color RGB = (71, 147, 191). When shown in ARView, it is rendered as RGB = (93, 201, 227), which is visibly different than the original image. When shown in SKView, it is rendered as RGB = (28, 149, 195), which is still slightly different than the original image, but close enough that I didn't notice it before doing this measurement. Why is the colour so different in ARView? (Optional question: why is it also slightly different in SKView?) Also, I'm not sure what I should do in order to not create the texture every frame, since its size is dependent on the size of the postProcess context. Should I store the texture in an instance variable and generate it again when the size of the old one doesn't match the size of context.targetColorTexture? I created FB22541137. import Cocoa import SpriteKit import RealityKit class ViewController: NSViewController { var device: MTLDevice! var renderer: SKRenderer! override func loadView() { let arView = ARView(frame: NSScreen.main!.frame) view = arView // let skView = SKView(frame: NSScreen.main!.frame) // skView.presentScene(createScene()) // view = skView arView.renderCallbacks.prepareWithDevice = { [weak self] device in guard let self = self else { return } self.device = device renderer = SKRenderer(device: device) renderer.scene = createScene() } arView.renderCallbacks.postProcess = { [weak self] context in guard let self = self else { return } let encoder = context.commandBuffer.makeBlitCommandEncoder() encoder?.copy(from: context.sourceColorTexture, to: context.targetColorTexture) encoder?.endEncoding() renderer.update(atTime: context.time) let depthStencilDescriptor = MTLTextureDescriptor() depthStencilDescriptor.pixelFormat = .depth32Float_stencil8 depthStencilDescriptor.width = context.targetColorTexture.width depthStencilDescriptor.height = context.targetColorTexture.height depthStencilDescriptor.usage = .renderTarget depthStencilDescriptor.storageMode = .private let texture = device!.makeTexture(descriptor: depthStencilDescriptor) let renderPassDescriptor = MTLRenderPassDescriptor() renderPassDescriptor.colorAttachments[0].loadAction = .load renderPassDescriptor.colorAttachments[0].storeAction = .store renderPassDescriptor.colorAttachments[0].texture = context.targetColorTexture renderPassDescriptor.depthAttachment.texture = texture renderPassDescriptor.depthAttachment.loadAction = .clear renderPassDescriptor.depthAttachment.storeAction = .dontCare renderPassDescriptor.depthAttachment.clearDepth = 1.0 renderPassDescriptor.stencilAttachment.texture = texture renderPassDescriptor.stencilAttachment.loadAction = .clear renderPassDescriptor.stencilAttachment.storeAction = .dontCare renderPassDescriptor.stencilAttachment.clearStencil = 0 renderer.render(withViewport: CGRect(x: 0, y: 0, width: context.targetColorTexture.width, height: context.targetColorTexture.height), commandBuffer: context.commandBuffer, renderPassDescriptor: renderPassDescriptor) } } private func createScene() -> SKScene { let scene = SKScene(size: CGSize(width: 100, height: 100)) scene.addChild(SKSpriteNode(texture: SKTexture(imageNamed: "blue"), size: CGSize(width: 100, height: 100))) return scene } }

I don't think the environment of the 3D scene has an influence on the 2D scene... or at least I would hope that it doesn't.

Thanks. I converted the image from P3 to sRGB, but I still get the same result: both images produce the exact same color. I updated the feedback to show this.