If these files are usually opened directly by the user (i.e from a Open Panel) then NSFileCoordinator might be what you want. But that is a cooperative API, i.e other processes also need to use FileCoordinator to access the file too.
Give more details on your use case.
I finally got around to trying Profile Manager, but whatever I did, I couldn't get it to upload the configuration plist to the device. I tested pushing other restrictions (e.g enabling and disabling the camera) and that worked, but nothing involving 'App Configuration' seems to work. My plist is pretty simple and the bundle ID is correct:
xml
?xml version="1.0" encoding="UTF-8"?
!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"
plist version="1.0"
dict
keyManagedAppConfigurationVersion/key
string1/string
keyLicenseKey/key
stringabcdef12345/string
keyUserID/key
stringwellington/string
/dict
/plist
Watching the server's Activity Tasks view shows activity for any modification to the 'Restrictions', but setting a new 'App Configuration' doesn't create a task.
Post not yet marked as solved
What happens if you run it from the Home screen with the USB cable connected and the Console app actually displaying that phone's logs (with and without "Include Debug Messages")? I wonder if I'm hitting an observer effect here.
Post not yet marked as solved
You are doing nothing wrong, but have probably hit a bug in Xcode dating back to Xcode 10.1 beta:
"
As of Xcode 10 beta 1, it seems the build settings editor GUI doesn't properly resolve the correct value for variables defined in the xcconfig files, and displays the values as if resolved with the old pre-Xcode 10 behavior.
"
Basically the settings really are being inherited correctly, but Xcode itself doesn't display them as if they are. This had me stumped today until I came across the above on stackoverflow /1393987/how-to-append-values-in-xcconfig-variables.
To be sure, actually do a #if DEBUG .... #endif section in your code and see if the enclosed code gets called at runtime.
It sure would be nice if this were fixed!
Post not yet marked as solved
Did we ever get an answer to this. I find myself in the same situation.
Thanks, I'll look into Profile Manager. In the meantime I went with a free 30 trial of one of the MDM providers.
Post not yet marked as solved
Agreed. Otherwise what is the point in logging private data at all. I can understand Apple's privacy stance, but there still needs to be a way for a developer to get useful logs from users without making everything public. Even if it requires the user to explicitly agree to any diagnostics being sent to 3rd parties before they are.
Post not yet marked as solved
Thanks for the extra info. From the 10.14.5 release notes, the preinstall script has an explicit test for 10.14.5 only:if [[ `/usr/bin/sw_vers -productVersion` == 10.14.5 ]]; then
/usr/sbin/spctl -a -vvv -t install "$PACKAGE_PATH"; fiSo am I correct in assuming that the spctl call really won't be needed in Catalina, nor some possible future 10.14.6 release.
From the responses so far, it seems that running macOS 10.15beta in a VM is not currently possible. Thanks for all the extra info everyone.
Post not yet marked as solved
Hi - I'm trying to provide a detailed description for my bug alongside instructions for using the two sample apps, but I am falling foul of the 'You must include a description of the issue within 3000 characters.' limitation. Should I just add the description as an attachment and say "See the description attachment" instead.I realise that whoever Triages the bug reports doesn't want to read War & Peace, but this limit seems to penalise anyone who is creating a detailed bug report.
Post not yet marked as solved
Thanks - I'll try and knock up a sample DNSProvider and Background downloading app to demonstrate it and post the bug number when done.
Post not yet marked as solved
To answer my own question about notorizing a pkg file that includes a kext. It does indeed now seem to work in that my package file passes notorization. Stapling failed initially until I followed the instructions to use this on 10.13.6:sudo killall -9 trustd; sudo rm /Library/Keychains/crls/valid.sqlite3
Post not yet marked as solved
So for a collection of LaunchDaemons, LaunchAgents, End User apps and kexts that we distribute via a flat pkg file, am I right that the only thing that needs notorizing is the pkg file itself? Trying to do each individual component separately is too much of a burden on our release cycle.Also, for the kexts, will notorization reject us if are using anything non-KPI internally. (Yes, we realise the dangers of going off piste into private kernel stuff.)
> Probably not )-: What are you doing in your MAC policyIn my case I was hoping to use KAUTH_PROCESS_CANSIGNAL to prevent 'unwanted' processes from signalling my security-related daemons, but it seems that has (still) never been implemented. So mpo_proc_check_signal seems the only way to go, unless I've missed another route.
