Drag-and-Drop from macOS Safari to NSItemProvider fails due to URL not being a file:// URL

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.

Ty @Etresoft, for the answer. Yay comments being borked and not giving a notification is so fun.

So, I comtinued my search. 3rd day on this. As far as I can tell, and I don't know if that's a bug in the latest Beta or always was like that (or a case of it doesn't work on my machine), but it seems the .onDrop SwiftUI operation will only return one single element in passed NSItemProvider. So it's either one or zero representation. I can put everything in the of: [UTType], and it'll coalesce it into a single internal type.

This means, at this point, that unless I do loops and hoops, it's effectively a bug in the SwiftUI behaviour, where it will not allow me to drag and drop from Safari, since the URL is not file-based, and SwiftUI seemingly coded their things for file-based URLs, not web URLs.

That's 100% the opposite of PH photo providers, where it'll happily send me everything. Or the paste operation that's functional because it provides me the NSPasteboard directly through the contextual menu.

Because of that, once I am in the delegate, it's truly "too late" as the contents of the Drag pasteboard already got processed by the system. I tried asking for text, item, data, url, everything, but the only thing the onDrop sends me back is the unretrievable image (even asking for .url returns me the public.jpeg). So I will file a bug report and merely move on.

I'm sure I can do a ViewRepresentation and do the code in Obj-C, and actually retrieve the thing myself, but TBH, I don't mind much, and hope Apple fixes it someday.

I learned the VERY hard way (during SwiftUI's initial developer previews) you have to follow the intents of Apple, not try to do it how you envisioned it. If it's not how they made it to work, it won't work, or you'll have to backtrack the next year's version.

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:

1. Don't use GCD with SwiftUI
2. 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.

(Re: previous answers - skip if you haven't followed the saga) Adding some context for the answer. I added AppKit specifically because it's not UIKit, as I didn't want an answer for iOS or ipadOS, but macOS.

The only SwiftUI line is the onDrag, that I faithfully added to the line as the "caller", but I didn't think I'd have a different DropHandler for macOS and ipadOS, the culprit seemingly being the onDrag SwiftUI part that tries to give me only the "good thing" on macOS, but somehow is unusable. As I repeated, I wanted to quickly iterate and used the hacks instead of trying to use the Async versions, where some versions aren't actually available. The final code will be in Async, thank you.

My first SwiftUI app was with GCD because there wasn't an alternative back then. There's one now. But I'm also butting heads with SwiftData, where models cannot be Sendable, but Async are also required to be sendable, so I've had a lot of "fun" on this topic. With the nearly 200 trials I had to do in order to make it work, I wasn't about to create good code only to suit the taste of Internet good will helpers, I'm sure you'll agree with me.

So. I did another 8 hours on this, and I was able to do it properly!

(/snip)

The answer lies in using the .onDrop with the .image type, where it will magically send me the Drag & Drops where images are accessible. But then, to actually ignore the provider, and do the work yourself from the .drag pasteboard!!

In essence, the previous piece of code (still not asynchronous- that's my next work) got trimmed down on macOS only to do things through the same code I'm using for pasting things.

private func handleItemProviders(_ itemProviders: [NSItemProvider]) -> Bool {
    guard let itemProvider = itemProviders.first else {
        return false
    }

    let registeredContentTypes = itemProvider.registeredContentTypes
    print("ContentTypes: \(registeredContentTypes)")
    guard let contentType = registeredContentTypes.first else {
        return false
    }
#if canImport(AppKit)
    handlePasteboard(NSPasteboard(name: .drag))
#else
    [snip]

And the handlePasteboard operation is a long-winded function that processes whatever the pasteboard has in it. First by optionally getting an URL (file or web)

    var url: URL?
    let urlType = item.availableType(from: Self.supportedPasteboardURLTypes)
    if let urlType,
       let urlString = item.string(forType: urlType) {
        url = URL(string: urlString)

Then by trying to get the data from the pasteboard itself (used in case of a drag-and-drop from Photos or Preview, or even Safari)

    if let imageType = item.availableType(from: Self.supportedPasteboardTypes) {
        guard let data = item.data(forType: imageType) else {

Then, if not functional, by trying to get the image from the URL through a coordinator (used in case of a drag-and-drop of an actual image from a file)

    } else if let url {
        if urlType == .fileURL {
            let queue = OperationQueue()
            queue.underlyingQueue = .global(qos: .utility)

            let intent = NSFileAccessIntent.readingIntent(with: url, options: .withoutChanges)
            let coordinator = NSFileCoordinator()
            coordinator.coordinate(with: [intent],
                                   queue: queue) { error in

Finally, when trying to drag-and-drop an actual link to an image, by trying to retrieve it with a downloadTask (don't forget the incoming network client capability!)

        } else if urlType == .URL {
            let session = URLSession.shared.downloadTask(with: url) { url, response, error in

In the last part, I check for the mime type for image, and download the URL if working.

So this works perfectly on macOS, under all circumstances. For iOS, a piece of code similar to what was written in the original question actually works, since the actual image got retrieved by Safari and the system sends back a local device URL, and not a https link.

So... Problem averted for now! And the code for the pasteboard handling can be reused with .general for a regular paste in SwiftUI.

    .onDrop(of: Self.supportedDropItemUTIs, delegate: self)
    .contextMenu {
        Button(action: onPasteButton) {
            Text("Paste")
            Image(systemName: "doc.on.clipboard")
        }
    }

with

public func onPasteButton() {
    handlePasteboard(.general)
}