NSFilePresenter primaryPresentedItemURL

There is an API in NSFilePresenter called primaryPresentedItemURL. It is implemented on macOS, but not iOS or Catalyst.

I want to use it to write an XMP sidecar file next to original image files. However, because it’s not implemented on iOS or Catalyst, I cannot do this.

The only workaround I have found is to ask the user for access to the whole folder. This, of course, is bad from a user privacy / security standpoint, especially as it gives the app access not only to the folder contents, but all subfolders. Can you give me a better workaround, or implement the API on iOS and Catalyst? Feedback Number is FB22771292

The only workaround I have found is to ask the user for access to the whole folder. This, of course, is bad from a user privacy / security standpoint, especially as it gives the app access not only to the folder contents, but all subfolders. Can you give me a better workaround?

Unfortunately, no, not really. In terms of the first save/access, you could also present an additional open/save dialog for the specific related file, but that's basically just a more cumbersome alternative.

After that first access, you can use security-scoped bookmarks to preserve access to the "target" which can work well if it fits your app’s general usage "pattern". Xcode is an example of how this can work, with the project file holding the bookmarks for all of the other files it references.

One final note on this— unfortunately, there's a known bug (r.102995804) in iOS that prevents bookmarks from resolving properly across mount/unmount cycles. Bookmarks within the boot volume should work fine, but bookmarks on external volumes will break as soon as the volume is remounted.

or implement the API on iOS and Catalyst?

That's a reasonable request, but all I can really say is that this hasn't changed in iOS 27.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Thanks for the information. I already have code to prompt the user for folder access and to save the bookmark. Yes, I could ask them instead for a save dialog for just the XMP file, but as you point out, that's not better from an experience standpoint. This API has been on Mac since 10.8 and the underlying OS / file system are similar between Mac and iOS, AND the security / privacy benefits of having this API on iOS are clear. Can you provide some insight as to why the API is hard to implement or (perhaps) not important to implement? At least when customers ask me why I have to do this, I can give them a proper answer.

Can you provide some insight as to why the API is hard to implement or

macOS has a very sophisticated and complex system for transferring access between files which basically doesn't exist on iOS. For example, "Sharing file access between processes with URL bookmarks" describes how on app can pass it's "right" to a file to a different, unrelated, process over XPC. There isn't any way to "do" that on iOS. On iOS, the ONLY way your app gets access to a file is:

  1. The object is in a location your app automatically has access to (like your app container).

  2. Your app was handed a file reference through the very "narrow" document access API set (this is the access bookmarks let you preserve).

That's FAR simpler than what macOS provides, which means much of the supporting infrastructure macOS relies on has never been implemented on iOS.

(perhaps) not important to implement?

Certainly, part of this is simply that using files across app is far less common than on macOS.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

NSFilePresenter primaryPresentedItemURL
 
 
Q