I’m doing more testing on Mojave. I have an app where one can Drag & Drop from the Photos app to my app.
I was surprised to see that this works normally.
However, my app has a Helper app which processes the photos, and it wasn’t until the Helper app tried to access the photos that I got the “This app wants to access your Photos” prompt. Hitting the button to deny access caused my helper app to crash (and then the Xojo IDE crashed too. Separate bug).
I then checked System Preferences / Security & Privacy / Photos and saw that my main app was listed, and was approved. (I had not done that manually).
- if you drag & drop from Photos to your App, Mojave considers this “approved” and automatically gives the app permission.
- if your app has a helper app that also wants to process this data, it’s not approved and triggers the UI prompt.
- the helper app, having crashed when not receiving permission, was not shown at all in the “Allow the apps below to access your photos…” UI inside System Preferences.
- if a Parent app has permission (implicilty) how can we give a Child (Helper) app the same permission?
- if a Helper app crashes, does it not receive permission? Or do helper apps (faceless background apps) not show up in the System Preferneces UI at all?
- is this all documented somewhere?
System Preferences / Security & Privacy / [subarea] has only a list of applications with a checkbox.
This gives three possible states:
- never asked (the app doesn’t show in the list)
- asked and granted
- asked and denied
But, there seems to be no way to revert to the “never asked” state, which is critical for testing.
Currently, I’m fighting with this, too.
Delete the app and it’s gone from Security and Privacy.
Helper apps don’t show up in Security and Privacy. macOS recognises them and doesn’t add an entry. So if your helper app has crashed it doesn’t have anything to do with Security and Privacy.
I was “battling” with the numerous rejection from the AppStore Reviewer over this last week but got that resolved and the app approved. I would think the same issue might apply to the non-AppStore App.
Here is the relevant WWDC 2018 session https://developer.apple.com/videos/play/wwdc2018/702
In the end in my entitlements, I needed to enable this two
To extend this to the helpers, you will need to include the following in the entitlements
And in the info.plist, add this
<string>Describe the purpose of using Photos</string>
Long story short… Security-scoped Bodgemarks.
When your main application has access, via Drag & Drop (or the Open dialog) you create a bookmark (with no security scope or this will fail). Then pass that to your helper application (currently I’m using IPC) and then in your helper application you decode the bookmark (with no security functions) and process the folderitem.
If you’re trying to pass a file that you got from a security scoped bookmark, you request access and then create a non-secure bookmark, send that to your helper and release access, you MUST do this within 90 seconds.
Requesting access from within the helper fails, trying to resolve a security-scoped bodegmark within the helper fails.
So Apple have finally given up trying to force us to use wasteful promised drags.
In the end in my entitlements, I needed to enable this two[/quote]
I love the way how the documentation says that this has been there since 10.7, yet I’ve NEVER ever seen it before and I’ve scored the documentation many times for Sandbox Entitlements.
[quote=408865:@Edwin Lau]To extend this to the helpers, you will need to include the following in the entitlements
Only on the helpers and they should include no other entitlements than to enable the App Sandbox.
Thanks for all the suggestions. This app is non-Mac App Store and Non-Sandboxed.
- For a non-MAS, non-sandbox app, do these entitlements serve any purpose?
- For a non-MAS, non-sandbox app, does the com.apple.security.inherit key do anything for helper apps?
- If it does, does it matter how you launch your helper apps?
There is a way to reset these authorizations for testing (in 10.14 Mojave)
tccutil reset Calendars
tccutil reset Contacts
tccutil reset Reminders
tccutil reset Photos
tccutil reset AppleEvents
tccutil reset Camera
tccutil reset Microphone
tccutil reset All
Good news! I made a bunch of changes, and now it seems to be working.
To recap, this is a Developer ID codesigned (but not sandboxed, and not mac-app-store) app which includes a helper app.
I wasn’t able to get the helper app to read Photo files when the main app was authorized.
Here’s what I changed:
- instead of testing while running both my main and helper apps using remote debugger, I tested in a fully built and code-signed app.
- Added these plist entries to my main app:
NSPhotoLibraryUsageDescription:"This app can read metadata such as picture title and description when you drag & drop images "
- added this plist entry to my helper app:
- Updated to 10.14.1 beta 3 (18B57c)
- when communicating the URL for the file from my main app to helper app, instead of just sending the file URL over IPCSocket, I’m now sending the bookmark data:
bookmarkData = CFBookmarkMBS.CreateBookmarkData(theFolderItem)
dim options as Int32 = 0
dim relativeTo as FolderItem = nil
dim isStale as boolean
theFolderItem = CFBookmarkMBS.ResolveBookmarkData(bookmarkData, options, relativeTo, isStale )
- used tccutil reset All before testing
- deleted all copies (including leftover debug copies) of my app before testing
Some of these steps may not be required.
- this is a 64 bit build using the latest Xojo beta
- the main and helper app have different bundle IDs (of the form com.mycompany.main and com.mycompany.helper)
Under 10.14 the Usage descriptions seem to allow you to customize the OS provided dialog.
Not as far as I know, I mean if you disable the App Sandbox, you disable the main security function right?
Not that I’ve found.
In the past I’ve used the “Pictures” key so that I could have access to the file in the Photo Library, but only read-only.
Glad to hear that it helped.