Thanks, I'll check explicitly for the combination of NSCocoaErrorDomain and NSFileReadNoSuchFileError then. For anyone ending up in this thread, note that NSFileNoSuchFileError is not the same error as what's being reported by checkResourceIsReachableAndReturnError. The error is: Domain=NSCocoaErrorDomain Code=260 "The file “write-single-file.txt” couldn’t be opened because there is no such file." UserInfo={NSURL=file:///Users/torarne/write-single-file.txt, NSFilePath=/Users/torarne/write-single-file.txt, NSUnderlyingError=0xa83590c90 {Error Domain=NSPOSIXErrorDomain Code=2 "No such file or directory"}}

[quote='856443022, DTS Engineer, /thread/797469?answerId=856443022#856443022'] No, I'm talking about "withoutImplicitStartAccessing". We explicitly say it does not apply to security-scoped bookmarks: [/quote] "This option causes an implicit call to startAccessingSecurityScopedResource() on the returned URL when it’s ready to use the resource." The way this is written makes it sound like there will be a call to startAccessingSecurityScopedResource somewhere, so that a subsequent pair of explicit startAccessingSecurityScopedResource and stopAccessingSecurityScopedResource will still leave access at 1, leaking kernel resources. It his not the case? Is this consistent across macOS and iOS? "This option isn’t applicable to security-scoped bookmarks." The documentation phrasing isn't clear about whether it's talking about NSURLBookmarkResolutionWithSecurityScope specifically (which is only available on macOS), or if it also applies to iOS (where all bookmarks are security scoped AFAIU from your earlier messages). Can you clarify this point? I think a lot of the confusion in this area is that there are differences between how macOS and iOS behaves, and differences in which APIs are available, and for people like me who's trying to write cross platform code, and account for any differences, we need to know those subtle differences to account for them, to give a consistent behavior out to our users. A clear guide that incorporates both OSes would be very much appreciated 🙌🏻 (e.g. https://developer.apple.com/documentation/security/accessing-files-from-the-macos-app-sandbox is great, but is specifically about macOS)

[quote='856443022, DTS Engineer, /thread/797469?answerId=856443022#856443022'] In any case, relying on this mechanism is a mistake. The right approach here is to use exactly the same code macOS does. That means: Create with NSURL.BookmarkCreationOptions.withSecurityScope. Resolve with NSURL.BookmarkResolutionOptions.withSecurityScope. Call startAccessing after you resolve. Don't use NSURL.BookmarkResolutionOptions.withoutImplicitSecurityScope. The pattern above is the only pattern that's specifically documented to actually "work". [/quote] And on iOS, what is the equivalent creation and resolve options? The "minimal" variants?

My standard approach would be to try creating the security-scoped bookmark and see if that fails. I’m presuming that you tried that. What went wrong? Thanks Quinn! Yepp, that's the first thing I tried. It produces a console error: Scoped bookmarks can only be created for existing files or directories Type: Error | Timestamp: 2025-11-18 14:10:18.411061+01:00 | Process: tst_manual_sandboxed_file_access | Library: CoreServicesInternal | Subsystem: com.apple.FileURL | Category: scoped | TID: 0xdd7936 and the bookmarkDataWithOptions call fails with an NSError: Error Domain=NSCocoaErrorDomain Code=260 "Scoped bookmarks can only be created for existing files or directories" UserInfo={NSURL=file:///Users/torarne/write-single-file2.txt, NSDebugDescription=Scoped bookmarks can only be created for existing files or directories} Which led me to using [NSURL checkResourceIsReachableAndReturnError:] before saving the bookmark. And in turn this forum topic to determine if that's the right approach to handle this use-case, or if fileExistsAtPath is preferred :) My worry is that fileExistsAtPath might produce false negatives, where checkResourceIsReachableAndReturnError would have returned YES. On the other hand, checkResourceIsReachableAndReturnError is less specific of why it would fail, when it fails.

[quote='866183022, Etresoft, /thread/807373?answerId=866183022#866183022, /profile/Etresoft'] Apparently, they shouldn't be balanced at all anymore. Instead, developers should issue one extra stopAccessingSecurityScopedResource to release the implicit startAccessingSecurityScopedResource. [/quote] That's not my interpretation of that reply at all (in a topic I started, if you notice). Look a the end of the reply, where the exact flow (after creating the bookmark) is: From now on, when you need to use the URL, create it with the bookmark data (init(resolvingBookmarkData:options:relativeTo:bookmarkDataIsStale:), and use start/stopAccessingSecurityScopedResource to access it. So during creation of a bookmark from an incoming URL (file dialog e.g.): start access create bookmark stop access stop access again on macOS to balance implicit access And on use: Load bookmark start access access resource stop access My goal with this topic is to determine the right creation options to ensure that when the creation step is done in phase one there is no additional implicit accesses that leak kernel resources, and that when resolve the bookmark in phase two, and are done with the resource (for now), it's back at zero access counts, and no leak of kernel resources.

For reference, this is my creation code: NSData *bookmarkData = [url bookmarkDataWithOptions: NSURLBookmarkCreationWithoutImplicitSecurityScope #if defined(Q_OS_MACOS) | NSURLBookmarkCreationWithSecurityScope #endif includingResourceValuesForKeys:nil relativeToURL:nil /* app-scoped bookmark */ error:&error]; and resolving code: securityScopedUrl = [NSURL URLByResolvingBookmarkData:static_cast<NSData*>(bookmarkData) options: NSURLBookmarkResolutionWithoutImplicitStartAccessing #if defined(Q_OS_MACOS) | NSURLBookmarkResolutionWithSecurityScope #endif relativeToURL:nil /* app-scoped bookmark */ bookmarkDataIsStale:&bookmarkDataIsStale error:&error];

Thanks Etresoft! My assumption was that NSURLBookmarkCreationWithoutImplicitSecurityScope would create a bookmark that, when resolved via NSURLBookmarkResolutionWithoutImplicitStartAccessing, would ensure that the initial access count of the resource was 0. The goal is to ensure that my own balanced pairs of startAccessingSecurityScopedResource and stopAccessingSecurityScopedResource on the resulting URL will never leak kernel resources due to unbalanced implicit accesses that I've somehow opted in to. Is NSURLBookmarkResolutionWithoutImplicitStartAccessing perhaps independent of how the bookmark is created, and no the resolution-side of NSURLBookmarkCreationWithoutImplicitSecurityScope ? If NSURLBookmarkCreationWithoutImplicitSecurityScope and NSURLBookmarkResolutionWithoutImplicitStartAccessing are not meant to be used for this case, then what would the equivalent of the NSURLBookmark{Creation,Resolution}WithSecurityScope be for iOS? NSURLBookmarkCreationMinimalBookmark + NSURLBookmarkResolutionWithoutUI ? Crossing fingers Kevin Elliott, who seems to have deep knowledge about this area, will jump in with some enlightening clarifications ☺️

I don't mean to hijack the original thread, but as the discussion seems to have moved to include .resolve and .nofollow, I wonder: Is there any public documentation of how these two magic directories work and should be handled? What is the recommended (CF or POSIX) API to resolve a canonical path in the presence of these paths? In Qt we use realpath if the path exists. Testing realpath /.nofollow/Applications in Terminal it doesn't seem to resolve to /Applications (on 26.1). If the path does not exists, and we need a canonical path (for cache key lookup e.g.), are we expected to manually strip .resolve and .nofollow, the same way we might combine/deal with .. and . ?

To give some context to the issue of calling NSApplicationMain or not: In Qt we don't call NSApplicationMain, but we do call [NSApplication run], which bootstraps AppKit's event dispatching and app lifecycle machinery. The function is documented as: After creating the NSApplication object, the main function should load your app’s main nib file and then start the event loop by sending the NSApplication object a run message. So I'd be very surprised if this would stop working without deprecation notices and similar ☺️ Looking at the disassembly of NSApplicationMain it seems to largely be a helper for loading NIBs/storyboards, which we don't use in Qt. Note also that NSApplicationMain never returns, which is not a good fit for being used to implement lower level APIs like QGuiApplication::exec() and more granular event dispatching mechanisms.

[quote='863211022, DTS Engineer, /thread/804886?answerId=863211022#863211022'] I typically do start/stopAccessingSecurityScopedResource on a URL provided by the file pickers [/quote] If I'm reading this guide correctly, the macOS file picker will already have implicitly started accessing the resource on your behalf. So if you do an explicit start/stopAccessingSecurityScopedResource on top of that, the resource is still missing one stopAccessingSecurityScopedResource to balance things out, and the resource access will leak.

[quote='804886021, torarnv, /thread/804886, /profile/torarnv'] From my testing, iOS does not provide the same implicit startAccessingSecurityScopedResource when using UIDocumentPickerViewController. Is this a correct observation/per design? [/quote] The docs at https://developer.apple.com/documentation/uikit/uidocumentpickerviewcontroller does seem to corroborate this observation. One idea I had for making iOS and macOS behave similar in this regard was to explicitly stop accessing any resource from the file diaogs, but according to https://stackoverflow.com/questions/25627628/sandboxed-mac-app-exhausting-security-scoped-url-resources that practice has at some point been discouraged by Apple (unfortunately the original thread seems to have been lost in the forum upgrade). Is this recommendation still valid?

Thanks Albert! I've posted a minimal test case here https://gist.github.com/torarnv/88660ddc67652c588eb57dfdc9259046 (also attached to FB). Pressing most of the typical function keys shows a difference in what charactersByApplyingModifiers reports compared to what the NSEvent comes with "built in": ❯ ./nsevent-charactersByApplyingModifiers.mm chars: '' [U+F729] | ignoring: '' [U+F729] | applying: '' [U+0001] ⚠️ // Home chars: '' [U+F72B] | ignoring: '' [U+F72B] | applying: '' [U+0004] ⚠️ // End chars: ' ' [U+007F] | ignoring: ' ' [U+007F] | applying: ' [U+0008] ⚠️ // Delete chars: '' [U+F728] | ignoring: '' [U+F728] | applying: ' ' [U+007F] ⚠️ // Fwd-delete chars: '' [U+F704] | ignoring: '' [U+F704] | applying: '' [U+0010] ⚠️ // F1 chars: '' [U+F705] | ignoring: '' [U+F705] | applying: '' [U+0010] ⚠️ // F2

As of macOS 26 beta 3 NSOperatingSystemVersion seems to report the major version as 26, even for apps built against the macOS 15 SDK.

I've now learned that this happens because the prev-lang:kbd NVRAM value is somehow not persisted during the initial language choice/installation. This is tracked by FB16623415 As a workaround, to get consistent behavior for automated recovery operations, doing an explicit sudo nvram prev-lang:kbd=en:-8569 before booting into recovery seems to do the trick.

@darkpaw I am a developer, and I'm using developer tools and technologies, specifically Virtualization.framework, to run macOS VMs, automating the OS installation for testing the software I develop. (You are assuming I added tags randomly, which I did not. Thanks).