I don't see what your code would fix or change, other than creating an extra variable. It also changes the program behaviour, because now the variable created in if let index is never used. I should also specify that I was never able to reproduce this crash myself.

Such an elegant solution. There is potential for a data race, so that must be it. Thank you. (It's strange that Google doesn't show that other topic even when searching for the assertion name. Only this topic is found, on this website and on another website vmhkb.mspwftt.com. Do you know what that is?)

I just tried to upload the app to App Store Connect, but the upload failed with this error: Unsupported Platform. The extension bundle myApp.app/PlugIns/myApp iOS QuickLook.appex is not supported for this platform. Please refer to the App Extension Programming Guide at http://developer.apple.com. (ID: 5df7bb8c-0216-4845-af78-c83d9a94de21) So I ended up creating a completely separate target for visionOS without the QuickLook extension.

Thanks for your help. I tried dynamically calculating the font size with the following code, but didn't get any noticeably better results. It sets a starting font size of 0.05 times the viewport height, then measures the width of a string containing the letter M repeated 40 times and adjusts the font size until the difference is less than 0.1, or the loop was repeated 10 times already (sometimes it would jump back and forth between two font sizes). let viewport: CGSize var fontSize = viewport.height * 0.05 for _ in 0..<10 { let stringSize = String(repeating: "M", count: 40).size(withAttributes: [.font: NSFont.systemFont(ofSize: fontSize)]) let newFontSize = fontSize * viewport.width / stringSize.width if abs(newFontSize - fontSize) < 0.1 { break } fontSize = newFontSize } I could resize the text with pixel perfection using an image, but then I would need to render it at a very high resolution to make it sharp enough for all possible viewport sizes. I'm not sure that's worth the effort in my case. It just occurred to me that WebKit is open source: https://github.com/WebKit/WebKit/tree/main Is the font scaling (e.g. font-size: 20vh) done at the WebKit level (can anybody point me to the source file?), or is it delegated to the operating system? By the way, I created FB20195868.

Thanks for your input. I had a look at your link but got lost quite quickly, though I may get back to it if I get really desperate. The user had mentioned that they use a non-admin account, but I had discarded that fact as irrelevant. After your mention of "take a URL provided from an open panel and launder it through a bookmark before use" I felt inspired to create a non-admin test account and I was actually able to reproduce the issue. I originally wrote that when scanning a folder selected in an open panel it doesn't resolve any bookmark, but looking at the code again it turns out I was already doing that "URL laundry". What's even more interesting, I tried skipping the laundry (which would resolve the bookmark to a URL whose path property is /.nofollow) and when scanning the URL returned from the open panel directly (whose path property is /), the issue doesn't happen! Can someone at Apple confirm whether this is expected behaviour or what I have to do so that scanning a URL resolved from bookmark data behaves the same as scanning a URL returned from an open panel?

So to summarize: 26.0 shipped with a bug, which evolved to an even more annoying bug in 26.1 which is supposedly fixed in 26.2 beta. I wish Apple considered issuing a fast patch rather than waiting for months until the next minor release, because this is affecting many users already, and we're only 1 week into 26.1 official release. So I'll have to reply to emails by frustrated users for another couple months...? Unfortunately users of my different apps also started reporting another issue that could be related: paths on an external volume, such as one mounted by "NTFS for Mac", or a path on a Synology volume, are "converted" to / (Macintosh HD) after going through laundry. Could someone at Apple confirm whether this is also a known issue? I wasn't sure if I should report this here or in my recent post.

[quote='865462022, DTS Engineer, /thread/798402?answerId=865462022#865462022'] I'm not sure. [/quote] Luckily one of those users is a programmer and already ran a test project for me, confirming that the issue is related to bookmark resolution. Is there anything I can ask them to do to understand this issue better? I opened TSI 16931637 in case it helps.

Just for the record, I've opened a separate post about the issue I mentioned above: Security-scoped bookmarks to external volumes are resolved to /

While this issue is extremely annoying, I have no hope that it will ever be fixed. More than 5.5 years have passed since I filed my bug.

A user of my app just reported the .nofollow issue and they have macOS 15.7.2. Until now this issue seemed to be related to macOS 26. Do you know if a fix is planned for macOS 15 as well?

I created FB21290658.

I don't have a bug number. I only got an email from a user who said they have this issue on macOS 15.7.2, that's all.

Another user of my apps just reported the same issue again on macOS 15.7.2.

Recently two users of my apps reported the same issue happening on macOS 15.7.2. Will it be fixed on both macOS 26 and 15?

I created FB9832605 in January 2022 titled "Dragging folder onto Simulator causes permission error", but after answering some initial questions it never went forward. Though it displays "Recent Similar Reports: Less than 10".