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.

I had double-checked your original post to ensure you weren't talking about SwiftUI. You specifically tagged AppKit and not SwiftUI. If you are using SwiftUI, then all bets are off. You have to do what SwiftUI dictates. In Perl, the saying goes, "There's more than one way to do it". In SwiftUI, on average, there's about 0.91 ways to do it. I can tell you two things about SwiftUI: Don't use GCD with SwiftUI Look at: https://swiftui-lab.com/companion/ Before I abandoned SwiftUI, that app was very useful. Not being able to use it now is probably my only regret about not using SwiftUI.

What are you trying to do? You said this PDF has geocoordinates. Is this a geospatial PDF? Apple doesn't have any API for georeferencing. You'll have to use a 3rd party framework like PROJ or GDAL. It's not easy. Geospatial data is often very large. Apple APIs are not suitable. Apple APIs are all designed for images that will fit into a single GPU texture. But if you're doing some kind of transform, you'll likely need two of them. So you'll need to keep your images to 4K x 4K at most. For geospatial data, that means you'll be tiling. Again, Apple has little support for tiling. There is some support, but it's horribly complicated and slow.

GDAL is for much more than just extracting coordinates. You would use GDAL to actually warp the image into a new 2D representation, based on your selected projection. And GDAL will do that out of the box (not true), much more accurately than any perspective transform. Any geospatial data is likely going to be much larger than anything Apple supports, especially on iOS. Apple APIs are designed to handle an image generated by the on-board camera. Even the latest iPhones released today are still touting 48 MP images. Your moderate-sized geospatial PDF is over 10 times larger than that. And you're using iOS, which has very limited RAM. Even on macOS, where you can open these large images, it will lock up the UI for any operation. And I'm curious about something. One thing that GDAL doesn't support out of the box is geospatial PDF. It requires one of a few different PDF libraries, each of which is problematic in its own way. Which one are you using?

I can't tell you any more than I already have.

Looks fine here.

That doesn't have anything to do with static libraries. It just can't find an appropriate dynamic library.

The operating system is ready It is not. Xcode barely runs on macOS as it is. Xcode is the single most crash-happy app I have. It crashes on me at least 3-4 times per day, every day. Xcode on iPad would not be a pleasant experience.

Don't use comments to reply. They get lost and no one ever sees them. Freetype is a commonly used library for certain open-source projects. In that context, it could be used as a static library. However, if your case, the dynamic library libsfml-graphics.2.6.2.dylib is trying to load it as a dynamic library.