Yes, a save panel is a save dialogue. It’s just Apple terminology.

> I don’t quite get the point of dragging a file to a save dialog at all though?

On macOS (since forever) and iOS (since 11), there is a heavy focus on drag. You should be able to drag anything from any app to any other app and something should happen.

This is facilitated both by system-level frameworks (so that all apps can gain correct drag-handling behaviour out of the box) and can be further enhanced by an app’s developer.

That begins with behaviour you might ordinarily expect from most apps: drag a image file from Finder into a Word, it should embed the picture; drag an audio file from iTunes into an open Audacity project, it should add the audio as a new track; or, drag highlighted text from a text field to the desktop and it will create a text snippet file containing that text.

On Windows, apps need to implement this behaviour manually. Figuring out how to deal with certain file types is not built into every app out of the box.

On macOS and iOS, it’s not just built into every app, it’s built into the operating system itself. It’s a fundamental feature of Cocoa, open which all native apps are built, so every app gets the correct behaviour for free. Dragging and dropping is super powered on Apple platforms.

For example, proxy icons: on any given document window (a window for an open document, like a Word document, Photoshop document, Final Cut project, etc), the name of the document is preceded by an icon that represents the document. You can actually drag that icon off the window’s title bar to any other on-screen element that supports receiving dragged objects — an open document, a Finder window, an email, a text field, etc.

I say all of this to cement one point: dragging and dropping is a key interface metaphor on macOS and iOS/iPadOS.

So, imagine I have a browser window open asking me to upload a file. If I have that file open, why should I navigate the directory hierarchy in the open panel? I can just drag the proxy icon for that document straight into the open panel. Bam, the open panel is pointing at the correct location.

Or perhaps I’ve just downloaded an image from the web that I want to share with my friend. Again, I can open up my favourite messaging program, click on the Add Attachment button, and drag the image in from my Dock’s Downloads stack.

(Although, that’s a slightly odd example; I wouldn’t bother with the Add Attachment button, I’d actually just drag the file directly from the Downloads stack on to the app and expect it to figure out what I want to do)

For save panels, I might already have a folder open in Finder where I want my document to be saved. When I save the document for the first time and the save panel appears, I can either drag that folder or its proxy icon from Finder straight into the save panel — bam, the save panel is pointing to the correct place.

Or perhaps I want to save a file into the same place as an open document. Again, I would just drag the proxy icon of an already-open document into the save panel, bam, we’re looking at the right folder.

Notice: these actions are non-destructive. Non-destructive actions follow the principle of least surprise. All I’m doing is telling an open/save panel where I want to be.

> That to me as a Windows user seems alien. I expect it to work as an Explorer window!

Ask yourself what the basic function of an open/save panel is: to select a location for a file (and in the case of a save panel, give it a name). Of the four CRUD operations, only C and R are directly relevant.

Something shouldn’t act as something else, especially if it’s destructive. That, in my opinion, violates the principle of least surprise — an interface to C or R should not U or D.

The only thing I expect to act as an Explorer window is … an Explorer window.