Thanks for the quick answer.That's why I'm asking it here, I don't want to do anything against the spirit of the documentation. There is however some grey area in it and I want to clarify it for myself.Let me add additional detail following your bullet points.I forgot to mention that it's a Mac app.1. If the app may not write there, this may be a show stopper already. Hmm... But it's not technically enforced, obviously.2. Yes, I'm using FileManager.SearchPathDirectory.applicationScriptsDirectory, so it's ok.3. I think there could be some code-signature check of the script in the shared location before it gets executed by NSUserUnixTask. This would securely prevent malicious modification of the script. Is this foreseen somewhere?4. True, I'm just trying to understand how this shared location for scripts is supposed to work and be safe. Any external script can get modified by any software that has access to that shared folder. So if an app is executing these external scripts, they are basically opaque black boxes for the app, it doesn't know what it's executing. In such case, who is supposed to be responsible for the external scripts' safety? Or am I overthinking it?5. I'm trying to use "tmutil" command-line utility to manipulate APFS snapshots on macOS. I don't know if it's quite innocent from sandbox's point of view, but unfortunately, tmutil seems to have some additional dependencies that are cut off by the sandbox and consequently the tmutil command fails.6. Yes, I understand that sandbox is not the same as compliance with App Review. Is there an alternative way to achieve my goal?Thanks!

Please read the question carefully. The question is not how to let an app enable the full disk access, that would indeed defeat the purpose. The question is how an app could *test* if it has full disk access or not. And if not, give some hints for the user, when necessary. That's a legitimate case.

I also noticed that if I make a copy of my app's binary and launch another instance after one is already running, the second instance launches instantly without any delay or slugglishness.

To answer my own question: The problem was caused by the MTLCreateSystemDefaultDevice() function, that returns the discrete GPU's device by default. The discrete GPU indeed takes a few moments to start up, unless some other apps are already using it. But my app would be totally fine with the integrated GPU, no real need for the more powerful discrete GPU. Once I changed my code to use CGDirectDisplayCopyCurrentMetalDevice(screenNumber) of my view's screen's NSScreenNumber, the launch time has dropped to a really small duration, as desired. More on the subject here: https://developer.apple.com/documentation/metal/gpu_selection_in_macos/selecting_device_objects_for_graphics_rendering?language=objc

The EUR is a little special because the same currency is used in many EU countries, while they have different VAT rates. For countries whose currencies are not supported and which use USD instead, the prices in the same tier vary quite a lot, depending on the local VAT rates. However this is not the case for EUR. Before May 9th, most countries that use EUR had the same price for Tier 10 - €11.99 in most EUR countries, and only for a few of them, like Montenegro, the price ws €9.99 (they have much lower VAT I guess). After May 9th, all EUR countries will be equal to €9.99. To me it looks questionable that for EU countries the burden of taxes is (partially) put on the App Store sellers by Apple without a choice. Moreover, some EU countries, who have higher VAT, therefore get more beneficial terms over other EU countries. The governments are rewarded for and benefitting from making their VAT higher, and we, the sellers in the App Store have to cover their decisions for our own cost, because of the fixed price for all EU countries. I guess this is done to simplify the calculations and end up with nice round numbers, but I would like to hear some deeper explanation.