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 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. 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.

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?

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 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).

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?

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.

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 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?

Thanks for your suggestions. When swapping materials, is it possible to do so with an animation? When adding a highlight mesh, is there a preferred way? I tried creating an entity with the same mesh but a slightly larger scale and some opacity, but this doesn't work when the mesh is two-dimensional (e.g. a card), for which an increased scale only moves the vertices away from its center for two out of three dimensions, so the two meshes overlap in the third dimension creating rendering artefacts.

As a note to my future me and other people who might have the same issue: it's important to use either FromToByAnimation<Float>(to: 0, duration: 1, bindTarget: .opacity) or FromToByAnimation(to: Float(0), duration: 1, bindTarget: .opacity) and not just FromToByAnimation(to: 0, duration: 1, bindTarget: .opacity) otherwise the animation won't do anything.

Another strange thing is that when dragging the crash report to the Xcode dock icon, the Xcode console logs this error: User Command: command script import -s lldb.macosx.crashlog User Command: crashlog --interactive --skip-status --no-parallel-image-loading "~/crash.ips" Resolved symbols for 0A35BC69-660D-3BC0-8AB4-3FA8D922EECB /usr/lib/libobjc-trampolines.dylib... Resolved symbols for 79EFE8B6-A212-3E98-B801-C9F2BF18EA68 /usr/lib/dyld... Traceback (most recent call last): File "/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Resources/Python/lldb/macosx/crashlog.py", line 1444, in __call__ SymbolicateCrashLogs(debugger, shlex.split(command), result, True) File "/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Resources/Python/lldb/macosx/crashlog.py", line 1855, in SymbolicateCrashLogs load_crashlog_in_scripted_process( File "/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Resources/Python/lldb/macosx/crashlog.py", line 1557, in load_crashlog_in_scripted_process process.GetScriptedImplementation().set_crashlog(crashlog) File "/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Resources/Python/lldb/macosx/crashlog_scripted_process.py", line 46, in set_crashlog self.threads[thread.index] = CrashLogScriptedThread(self, None, thread) File "/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Resources/Python/lldb/macosx/crashlog_scripted_process.py", line 171, in __init__ super().__init__(process, args) File "/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Resources/Python/lldb/plugins/scripted_process.py", line 271, in __init__ self.get_register_info() File "/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Resources/Python/lldb/plugins/scripted_process.py", line 365, in get_register_info raise ValueError("Unknown architecture", self.originating_process.arch) ValueError: ('Unknown architecture', 'x86_64h')

Thanks. Using AnimationResource.generate(with:) rather than AnimationResource.makeActionAnimation(for:duration:bindTarget:) solves the issue (and setting a material makes sure that the sphere actually fades out and doesn't just disappear at the end). I don't understand the difference though, the two lines of code seem almost identical to me.

I created FB22098456.