How to fix sandboxing problem in macOS Mojave?

It's an urgent problem, that is hopefully a bug and not a conceptual change of Apple. Even, if the user allows access to the user's home directory, the Library folder is excluded.

The app can still find files in the Library with the Spotlight API, but it can't access these files, for example to show a quicklook preview. Because emails and attachements are located in the Library, read access is essential for our information retrieval app.

This will be a problem for all information retrieval and disk utility apps in the store, in particular for those developers, who use the payment feature of the store for their business model, because they can't just offer a download somewhere else as a solution.

Some ideas?

Because emails and attachements are located in the Library, read access is essential for our information retrieval app.

If you’re trying to access the user’s mail database then, yes, there have been changed in 10.14. These are explained in WWDC 2018 Session 702 Your Apps and the Future of macOS Security.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

In the future, pay closer attention to developer betas. Mojave has been available to developers since early June. If this is critical to your app, then you may want to consider pulling the app from the store and releasing a version on your own web site with the necessary changes.

Access to these locations is now controlled by System Preferences > Security & Privacy > Privacy > Full Disk Access. You will have to provide a button that opens this preference pane inside your app. Then, once the user provides access, System Preferences will have to close your app. Then, after restarting, it will have access to the necessary locations.

That is pretty easy to do programatically. Most importantly, it is necessary for your app to have access to those directories in Mojave - regardless of whether your app is sandboxed or not.

If you are distributing via the App Store, getting it past App Review will be the challenge. There are many apps in the store that apparently need full disk access to function, as far as I can tell. Perhaps Apple was very lenient in the past with this. They certainly aren't now, or at least, haven't been in my experience. Just having a visible button was enough to reject my app. And I don't even need it. It just added about 4% more information. I had to bury the setting in preferences before App Review would approve it. Now I seem to be on the App Review slow train. Even my metadata rejections are taking days to review. Perhaps Apple was a bit embarrased at having sold all that spyware in the app store for so long so they need to add more hoops for honest developers to jump through.

Thanks for your helpful posting.

Unfortunately, I couldn't find a solution to call the the specific system setting. Maybe it works with NSWorkspace, but I don't know wich parameter I could use. Any suggestion?

Unfortunately the video doesn't help, although I learned, that the easiest solution would be pre-approval of the app by the user in the system settings. To find a solution for the best user exoerience, I tried to use the scripting bridge, that we already use in our app. Unfortunately, the scripting bridge doesn't work any more in our app.

Here is a ver simple example:

SBApplication *mail = [SBApplication applicationWithBundleIdentifier:bundleId];
SBElementArray *selection = [mail valueForKey:@"selection"];

It doesn't work for the Preview app either, if our app asked for the open and visible document.

Until High Sierra we used the entitlement com.apple.security.temporary-exception.apple-events with an array of the bundle identifers. For Mojave we activated Apple Events in the Hardened Runtime capabalities. I realized, that com.apple.security.automation.apple-events appears in the entitlements now.

Maybe some business logic is mossing. Unfortunately I don't understand slides 25ff of the linked lecture. It's clear on the conceptual level, but not, what we have to implement, to make this working.

I’m not sure what you are asking. This is not something that can be fixed programatically. The best you can do is open the Security pane in System Preferences. Then you have to rely on the user to do the rest. And that is just to make it work in Mojave. Attempting to force the user to do that, or even merely leading the user to it, is an automatic rejection in the Mac App Store.

Thanks for your response. You have rephrased in your third sentense, what I mean: How can the app open the system preferences with the security settings to grant an application access to the user's data. Of course, the has to add our app manually afterwards. Or we can decide to do nothing, of course. With NSWorkspace I know, how to open apps, but I don't know how to open specific system settings.

macOS 10.14 introduces user approval for Apple events as well. That’s reasonably well covered in the WWDC session I referenced but it does miss one crucial detail: If you app is linked with the 10.14 SDK then you must include the

NSAppleEventsUsageDescription

Info.plist

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

I recommend against hard coding paths to system features like this. The location of the Security pref pane is not considered API.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Are you saying System Preferences is going to be replaced by a Marizpan port of the iOS Settings app? Good to know.

I'm well aware that any macOS app needs to be tested against any new build, major or minor. Hopefully the OP realizes this now too.

Are you saying System Preferences is going to be replaced by a Marizpan port of the iOS Settings app?

No, I’m saying exactly what I said, that is, the location of the Security pref pane is not considered API. It could change in the future, in which case this technique will break.

I'm well aware that any macOS app needs to be tested against any new build, major or minor.

True, but that’s not the whole story here. If you use unsupported techniques then you increase the risk of compatibility problems down the pike. You can choose to take on that risk for yourself - that’s a business decision for you to make — but I think it’s unfair to suggest unsupported techniques to others without outlining the associated risks.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

I'm just kidding with the Marzipan joke. Mostly.

The important point here is that the OP's app stopped working. That didn't happen because they used unsupported techniques. They were good citizens. They used security scoped bookmarks. Their app was in the store. And it stopped working anyway.

Could you suggest an official API to use instead of opening the preference pane directly? I tried using a bundle ID, but that didn't work. It is pretty kludgy as it is. It only gets the user halfway there. Some users won't be able to get the rest of the way on their own, even with instructions.

Could you suggest an official API to use instead of opening the preference pane directly?

No. If you want a supported way to do this, you (well iQser_Developer) should file an enhancement request along those lines.

I should have suggested that earlier, but I’m concerned that it won’t go anywhere. If Apple wanted to make it easy to adjust this setting in situ, we could (we do exactly this for Apple events). The fact that there’s no equivalent UI for Full Disk Access is not accidental. macOS Engineering is making a security / usability trade-off here.

Then again, if you think they’ve erred too far on the side of security then an enhancement request is the right option.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

eskimo wrote:

If you want a supported way to do this, you (well iQser_Developer) should file an enhancement request along those lines. I should have suggested that earlier, but I’m concerned that it won’t go anywhere.

That would be my concern with an enhancement request as well.

It is really unfortunate that iQser didn't notice the problem during the beta. At this point, a conversation like this doesn't serve any useful purpose. What's done is done. iQser's app is dead. That's the cycle of life, isn't it?

I'm well aware of Apple's design goals with respect to the future of macOS. I'm not about to waste my time or any Apple engineer's time with enhancement requests, temporary exceptions, or App Review appeals that I know would be dead in the water.

But I don't see the harm in quick and easy solutions to problems like how to display a specific pane in System Preferences. Is it going to break in a future version of macOS? Well of course it is. Most Mac developers know how this ends. But that doesn't mean we have to let people suffer needlessly. I can help people have a better experience with their Mac this year, and maybe next. In turn, those customers will help fund my post-Mac products. I don't see anyone, including Apple, being hurt. I see everyone, including Apple, gaining in the end.