This has been an ongoing problem in Apple's Developer forums and the Apple Support Community. These two forums seem to share a lot of code. And apparently, they even share releases. These kinds of problems started on both forums in July. Then both were fixed. Now both forums are having the same problems again.

An update: I thought it would be enlightening to write a simple demonstration app. I did that and learned a few things. Apple documentation describes two entitlements that are required for security scoped bookmarks. This document is strange. For one thing, the URL is under video applications. And it's ancient, referring to changes in macOS 10.7.3. It's also wrong. The entitlement "com.apple.security.files.bookmarks.app-scope" is not necessary and has no effect. More importantly, the entitlement "com.apple.security.files.bookmarks.document-scope" is required for security scoped bookmarks with document scope. You'll get an error if you attempt to use them without this entitlement. Unfortunately, they also don't work at all. The entitlement error is straightforward and tells you that you need the entitlement. But then, when you provide it, all attempts fail with error 256 "Item URL disallowed by security policy". It does seem to be modifying the metadata of the reference URL, but then it just doesn't work. That's too bad. I prefer to have data where I can see it. As far as security-scoped bookmarks and URLs, it's just really complicated now. It's impossible to create security-scoped bookmarks for certain URLs. I've only found two paths that are guaranteed failures: / and /System/Volumes/Data. These are kinda the same thing, but also kinda not. Unfortunately, if you allow the end user to select a directory, there's nothing stopping them from selecting these two locations. My recommendation is to wrap a URL in a class that can manage both the start/stopAccessingSecurityScopedResource and when creating a security scoped bookmark, fall back to a standard bookmark (or just an absolute string) on failure and hope that's useable after restart. Maybe this is just a bug in macOS 26 and it'll be fixed before launch. But even if this happens, this is obviously an API that's at risk for breakage.

It's probably related to whatever you are doing with adguard and vaultwarden. I don't know what any of that is, but when I search for your domain, it shows up on a couple of Github domain lists. I also don't know what those domain lists are for. But if you're going to play around with anything even remotely related to "security", you should do that on a burner site. Otherwise, you effectively turn your site into a burner site. There is no differentiation on the internet between legal/illegal, safe or malicious. It's the internet. It's all illegal and malicious, unless proven otherwise. Google and others work hard to hide that from regular folks. But if you fall through the cracks, even by accident, it's your problem to solve. Nobody's going to help. This is a developer support forum. It's a place for questions about SwiftUI, APIs, NSURLSession, etc. You can ask anything you want, but if you're asking about something that isn't developer related, you probably won't get any answer. I can tell you that there is no escalation process. The modern world runs on scripts and automated flows. If you ever need personal support, for any reason, you're in deep trouble. And I'm talking about situations where you've paid money for a service, over several years. Even with that kind of established relationship, trivial support requests that require human intervention will take weeks at best. At even the slightest hiccup, entirely unrelated to you, you'll be dropped and forgotten, and they might even keep your money. The internet's not for the faint of heart.

If you wanted to create a process that created bookmarks but didn't present open/save panels (for example, as a helper process), then you could use it. The only time I imagine this could be executed would be if a helper resolved a bookmark and found it stale. Don't know how I could test that, but I guess this means "com.apple.security.files.bookmarks.app-scope" actually is required. Thanks for the insight. In concrete terms, a bookmark created directly to "/" (hard-coded path) will be able to read "/" (the top level) but will NOT be able to read "/Users/". However, a bookmark created from an open panel WILL be able to read "/Users/". My issue here is the type of bookmark. I cannot create a security-scoped bookmark to / from an open panel. That's what I meant about being lucky. For this app, in this instance, I don't need to read /Users. I just want the size and free space on the volume itself. The app is currently working just by creating whole-volume URLs from the path. Originally, I thought I would need security-scoped URLs. Then they didn't work. Then I figured out I didn't need them at all. But I would still prefer to code defensively. On the Mac, start returning "false" generally means that you don't have access to the file, which generally means you're doing something wrong. That is not the focus of my question here. I think I've seen it return false, and noted it in passing, but didn't have any problems. It could have been on iOS. I have a large cross-platform project on temporary hiatus. That project is where I adopted the practice of checking the result of start. My general advice here is to treat any URL you receive from the system as a "magic" object. In practice, I generally convert it to a bookmark, then resolve the bookmark again, and use that new URL*, discarding the original ("magic") URL. *This ensures that the rest of my app is ALWAYS working with "a URL that came from a bookmark", instead of a "split" flow. But converting certain "magic" URLs always fails, therefore a "split" flow is unavoidable. the better option here is to create your own class which "handles" access to that object and "owns" both the bookmark and any URL. If it has problems, then it just resolves the bookmark again. Yes. That's what I'm going to do, in order to manage this split flow. Your advice makes a lot of sense, especially for this issue. When I get a URL from the system, convert it to a bookmark. First try a security-scoped bookmark. But if that fails (as it will for / and /System/Volumes/Data), then try a standard bookmark, and if that fails just use the path. Then resolve that "persisted resource" to my own URL and use that. I think a better approach than wrapping the URL is just to create a "URLResource" object that will contain a type enum and data. It will handle security-scoped bookmarks, regular bookmarks, and absolute strings. It'll still be sendable too.

BTW, is there no way to get a more meaningful app name on iOS, like the Files app itself is showing other than this bundleID form? Are you starting from a document? You should be able to get the UTI of a document. If you ask for the localizedDescription, that might be what you're looking for.

Etresoft, I am not sure I follow, please explain. I'm not sure I follow your question either. It seems unrelated to your overall question. I've just been following this thread due to some similar confusion I've had with these APIs on macOS. If you have a URL to a document. You can use the UniformTypeIdentifiers API to get the rich(er) type information for the document. This gives you things like extension, MIME type, and the UTI (public.jpg, public.text, com.adobe.pdf, etc.) You referenced the Files app. The Files app will also give you something like "Pages document", which is another field that developers can specify when they create an exported document type. But then you're asking about apps specifically, so I'm not sure if this is what you're looking for. Apple considers installed apps to be privacy-sensitive. I've heard that there are some methods to get this information, but it puts your app, and you, personally, at risk. I wouldn't recommend going down that path. If you want to get a human-readable description of a document, which may include the app used to create it, the UniformTypeIdentifiers API should do that for you. If you're interested in inspecting other apps on iOS, you're on your own.

I should have said "resolve", not just "create". The use case here is a helper tool/process that's given a URL "target" (for example, through XPC) but something like (like your main app), so the user never actually selects files "for" it. In my current app, it turned out that I don't need bookmarks. But I have apps in development that will need bookmarks for both files and directories. I've seen some recent threads here involving bookmarks. I can't find the exact one, but I remember one in particular that discussed some complicated interactions between processes and bookmarks. In following these threads, bookmarks seem less and less straightforward. the issue here is purely a bug. The word "bug" is a bit of a value judgement. I think it might be better to refer to bugs as simply "behaviour". Apple might be able to differentiate between expected and unexpected behaviour. But for 3rd party developers, it's all just behaviour. The only thing that's important is that said behaviour is documented. Stepping back for a moment, what's your larger goal here? If you're specifically interacting with volumes then the other, often better, option is to move down a level in the system and use DiskArb, which ends up bypassing most of these issues. Currently, it's just a login item that checks volume free space. I had planned on using security-scoped bookmarks just because it seemed to be the standard way to persist URLs in a sandboxed app. I am using Disk Arbitration, as well as IOKit, but that's for collecting additional information about the location referred to by the URL, as a URL for an external volume is not reliable. That being said, I do need to use a URL as a starting point to see if it's the correct volume. bookmarking "/" isn't something you'd normally do anyway. I realize that now. But the issue here is that if I allow the end user to select a URL, which in the Mac App Store, I must do, then I need to handle the location selected, by any means necessary. "/System/Volumes/Data” -> How did you get this? Primarily this is for FSEvents. It's not related to the login item, any security-scoped bookmarks, or any persistence issues. I was poking around to learn more about this unexpected behaviour and this seems related. Basically, the open panel shouldn't be giving you any object you can't bookmark. Again, "shouldn't" is a value judgement. It's my job to write code that works properly with observed behaviour, expected or otherwise. Judgements are out of scope. Note that if you're getting file references from other sources (like navigating the hierarchy yourself), there are lots of objects that can't be bookmarked, but many of those are also in the category of "don't treat this like a file at all" (for example, the contents of /dev/). Exactly! Thankfully, I can't even navigate to /dev in an open panel. But what about other locations? Originally, this would have been a bigger problem. I've avoided that by restricting the user selection to whole volumes. I would prefer not to do this, but "/" is likely to be a popular choice, so I have to support it. If I allow arbitrary paths, then I have to handle both the unbookmarkable / and bookmarks. I might still do that, just not tonight. I would assume that you won't be able to restore access to a resource unless you have a security-scoped bookmark. Yes. That was my assumption too, leading to the catch-22. I think paths and bookmarks should be treated as fundamentally different concepts, not as replacements for each other. A path is a static reference to a precise location in the file system tree, while a bookmark is a persistent reference to an object on a particular file system. Which is why I'd prefer to use bookmarks. For example, a volume name collision can change the target of a path but has no effect on a bookmark. That was one of the reasons I wanted to use bookmarks in the first place. However, I don't think that guarantee is actually documented, so I had always intended to use data from Disk Arbitration and IOKit to double-check. But I think we're going in circles at this point. I wanted to get some clarification and I did. It's a bug new behaviour, which is likely to change in the future. But it's August 29, so macOS 26 is likely to ship with this new behaviour, so I'll need to handle it permanently, and any likely new behaviours. The internals, and public API, is far more complex than I had assumed. But I've learned some strategies to minimize the impact on my code.

That's not an OS crash. It's just Java. Get rid of Homebrew and download Java directly.

You didn't specify what platform you're using. On iOS, you need to use a UIDocumentPickerViewController. On macOS, use an NSSavePanel. Both these methods allow you to export a file from the app sandbox into user-specified locations.

I suspect what you're referring to here is that standard (vs document) scoped bookmarks can only be opened by the executable that created them, which means a bookmark created by your main app can't be resolved by your helper process. Yes. Because of that issue, my original design had a fairly convoluted idea for getting those bookmarks to the helper. But in this limited use case, it turned out that none of that (including bookmarks themselves) was necessary. But since you mentioned document-scoped bookmarks, I should reiterate that I tried those too. They're completely non-functional, for any URL. Code=256 "Item URL disallowed by security policy" I won't need this functionality until a 2.0 version of a later project, so I can't spend any time on it now. That's a totally fair point, but bookmarking "/" WILL work. The fact that it doesn't work now is an unfortunate accident that will be fixed. Yeah, I get it. But released versions aren't like betas. Once a new beta version drops, I don't have to worry about any previous beta behaviour ever again. But any behaviour in any released version is permanent. Even when an API bug like this gets fixed, I'll need an OS version check and only use the new behaviour on a newer OS version that supports it. Neither the Finder nor our open panels present an accurate view of the actual file system. Yes. I'm aware of all that. But end users might not be. Thanks for reminding me about /Applications. I need a special warning if users navigate there. Although it isn't an important location for my storage management app, end users think it is, and they would get confused. I have a number of such end user warnings. DiskImages can make things weird. Thanks for reminding me about that too! I can just disallow those. They're not applicable to my task.

You do have to add "com.apple.security.files.bookmarks.document-scope" to your entitlement file yourself, Already done. The object you're using as the bookmark "anchor" needs to be a file, not a directory, and must be a file you already have full read/write access to. Already done. The object you're targeting needs to be a file as well. That's an important plot point. My current app looks at folders exclusively. So that's all I tested. Document scoped bookmarks are designed to be used to track groups of user files (for example, like an Xcode project), so a small number of directories have been blocked. It sounds like a large number of directories have been blocked - i.e. all of them. Or are these blocked target file prefixes rather than directories? Ah well, such is life. I'm working an an iOS/macOS GUI version of a command-line GIS tool. I had wanted to allow the user to specify a directory to be used as a library. Power users could then use my sandboxed and Metal-powered version of the command line app they are already familiar with in this library folder. When I learned how to actually create a document-scoped bookmark, it seemed like a much better way to go. I could have a little metadata file in my app group directory to host the bookmark. Then, my raster, vector, and AI apps could all use the same library. But that's at least a couple of years out. You'll get this error if the objects aren't files or your target is in a blocked directory. That's better than the error message it throws now. But I'm a bit confused about your object/target nomenclature. But I guess it doesn't matter. Directories can't be used in any way with document-scoped bookmarks. That's all I need to know. Thanks!

I also try to be a good app, and provide asynchronous support. I think that's your problem. It's too difficult to keep up with that. Your asynchronous code is already deprecated and disavowed. First of all, make sure you try using the ClipboardViewer tool. I think it's in Xcode's AdditionalTools as a separate download. I know you're dealing with Drag and Drop, which is not quite the same, but it may be enlightening as most people implement Copy and Paste with the same data. I've never tried dragging from Safari, but I certainly never seen any TIFF conversions. I even support data types that the system doesn't, so there's no way it ever could convert it. Again, I think you're trying too hard. Instead of itemProvider.loadInPlaceFileRepresentation, try just loadItem. That should give you the actual URL. You might run into concurrency problems. I seem to have encountered that myself with these APIs. Unfortunately, there's no easy solution. You definitely don't want to try those old dispatch queues, at least not in the final version. Swift Concurrency is much better. However, you still have to be careful. Find a sweet spot and stick with it. Don't adopt an old technology like dispatch queue that Apple's already abandoned. But also don't jump on the bandwagon. If you start a new project with those beta versions, you'll get the latest Swift 6.2 MainActor concurrency, which you don't want yet. Don't get me wrong. It's a great idea, but it's not quite done yet. I've found Swift 6 to be pretty stable.

First of all, don't use comments to reply. They don't trigger notifications or update the status of a thread, and they're hidden. I haven't looked at this code in some time. After reviewing it, I think see the problem. It looks like you're trying to handle dragging of data, not URLs, from one app to another. There can be valid reasons for this. You may have an app that has an image where you can select part of it and copy/drag. There is no URL in this case. In most cases, the data is going to be converted to and transferred as TIFF data. But this is really an oddball use case. It's pretty rare for any app to support this. I don't have any image or vector apps that do this. Dragging always just moves things around. But I'm pretty sure you are actually trying to support dragging of files. You explicitly said, "I can now support Drag-and-Drop from the Finder". That means you want URLs. At a high level, there are two steps to this. First, use the UTIs that you've already listed as validation for your drop. You want files in all those raster (mostly) formats. There are various way to do this validation, but the key part is that these UTIs are for validating a drop. But then, when you want to access the data being dropped, don't use those UTIs. Instead, coerce the item into a URL. However, when I reviewed my code more closely, it looks like when my model called itemProvider.loadItem, that is only ever executed on iOS. While this API seems to exist on the Mac, I don't use it there. I have one NSViewController subclass that adopts NSDraggingDestination. I override performDragOperation, get the draggingPasteboard from the NSDraggingInfo, and get the pasteboardItems from that. For each pasteboardItem, I get the data of type .fileURL, convert that to a URL via URL(dataRepresentation:relativeTo:) Elsewhere, I'm using an NSOutlineView that has its own drag and drop support via NSOutlineViewDataSource. That gives me the same NSDraggingInfo. On iOS, UICollectionView and UIDropInteractionDelegate seem to require NSItemProvider. I think on the Mac, that might exist only for SwiftUI. For dragging things from Safari, it looks like you would want to add "public.url" to your validation UTIs. That will probably complicate your validation as any file would match. But I just tried Clipboard Viewer and it does support dragging. It look like Safari has a couple of "promise" types at the top. Your NSItemProvider likely expects a lot more logic to handle that. But I bet if you use the older logic that I described above, it will skip over the promises and get whatever data you want. In my one example from Avatar images here in the forum, it has PNG data, TIFF data, and then a public.url later on, in addition to a couple dozen other types.

I'm in the same boat, but a couple of days behind you. From what I understand, you don't get a receipt during development anymore. See this post. I've seen many posts about problems with StoreKit2. Most people seem to just switch to StoreKit1. However, it can be difficult to learn anything from the internet anymore. I should know more in a few days.

Sorry about that, I flipped my terminology mid-post. You were pretty clear that neither of them could be directories. But at least it's good to know this before I write 3 separate apps that can't share data.