Post not yet marked as solved
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.
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
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.
Post not yet marked as solved
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.
Post not yet marked as solved
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!
Post not yet marked as solved
In the above setup (boot Catalina from external disk), not only they are saved on a different volume, but also the different volume is located on a physically different device (internal disk), and the snapshots remain there and are discoverable even when the external startup disk is unmounted and physically ejected.I just tested the "normal" setup, when Catalina is booted from the internal disk. In this case snapshots are saved in /System/Volumes/Data, which is kinda expected.
Post not yet marked as solved
But why are they saved on a different volume, even in a different APFS container? How is this even possible, given how APFS snapshots work?
Post not yet marked as solved
I have made an additional research and I have to correct my question:First, let me explain my testing environment. I have macOS Mojave on my internal SSD, and I installed Catalina beta on an external USB HDD. Beside the APFS container on that USB disk, there are other partitions with other file systems.Now when I boot into Catalina from the external disk, and type the following command:tmutil localsnapshotThe system pauses for a second then says:Created local snapshot with date: 2019-08-26-183151However, when I type this:tmutil listlocalsnapshots /ortmutil listlocalsnapshots /System/Volumes/Datait comes out with nothing, as if the snapshots are not there. However, when I look for snapshots on the internal drive:tmutil listlocalsnapshots /Volumes/Macintosh\ HDI get the output:com.apple.TimeMachine.2019-08-26-183151.localAlso, when I am logged in Catalina, I am able to delete the snapshot (contrary to what I reported previously) using tmutil deletelocalsnapshots 2019-08-26-183151However when I log in back to Mojave, I still can list the snapshots on the startup disk Macintosh HD, but I can no longer delete it using tmutil deletelocalsnapshotsTL;DR It looks like Catalina stores its APFS snapshots on another volume (internal disk), at least when it's booted from an external disk, and those snapshots can only be deleted when booted in Catalina that had created the snapshots. The snapshots stay there even when I unmount and disconnect the external disk!Is it normal? This looks strange to me. I thought APFS snapshots can only exist on the same APFS volume where they were created. Am I wrong? How is it supposed to work under the hood?
Post not yet marked as solved
It's not new, it's existed as long as the snapshot feature of APFS
Post not yet marked as solved
Pardon my ignorance, how do I find where those enhancement requests can be found, could you give me a link?
