Should I use non-bookmarkdata to store and retrieve the directoryUrl property of a NSSavePanel in mac sandbox ?

My new macOS app will export large files. Often users like to export these files to the same directory. It's standard practice to set the directoryUrl on an NSSavePanel to the directory the user last used. That's different from suggesting the user export precisly the same file path as before, which is what Adobe Illustrator now does, and it drives me nuts.

I could save the security scoped bookmark data to the final output url, and I do that for other purposes for other files. But that doesn't feel like the goal here. I tried the same thing on the parent dir of the output file, and it failed, which I expect is as intended, obviously, since the user did not provide access to the entire directory my app should not be able to access it.


So my backup plan is to save merely the string of the directory, and create the URL for the save panel from that, ignoring everything around secuiryt and bookmarks, assuming the NSSavePanel will do something responsible and intelligent given the input.


Does that seem like the right thing to do, or is the NSSavePanel perhaps already doing a better job of tracking directories that are useful to the user?

Replies

The first thing to do is to verify that you can set the save panel's directory to a URL that's not security scoped (and not for a location that you can write to without user permission).


If that works, then I would suggest you store the location as a normal bookmark. That's because — often — bookmark resolution can resolve to the wanted URL even if the directory is renamed or moved before you next refer to it.


Or, if you don't want that behavior, I'd recommend storing the URL rather than the path. URLs conform to both NSCoding and Codable, so it's easy to convert them to/from Data object for storage.