We've just had a build of our Unity app rejected from the Mac App Store because of an unauthorised read/write open of /usr/share/.mono. After a bunch of testing we've figured out it's GameSparks that is attempting to open the file (disabling GameSparks removes the error, and the old build we had on the Mac App Store wasn't using GameSparks).
Is there any way to get a build of GameSparks that doesn't attempt to open that file? I poked around with the GameSparks C# API, but couldn't nail down exactly where that call is coming from. I'm assuming it's from the GameSparks dll.
The only reference to that file I could find on answers.unity3d.com was http://forum.unity3d.com/threads/unity-2-5-1-mono-issue.30157/
Great, thanks so much! I know this is a trivial little issue, I really appreciate it.
We've replicated the issue and have a proposed solution. This is a mono issue on OSX (that we can't fix) and we're implemented a native plugin to get around this.
We are working through the testing now and hope to have an update shortly.
Unfortunately I can't get a stack trace—the only place that is logging the denied file access is on the OS X Console application. I've made a barebones GameSparks-enabled Unity 4.6 project here: https://www.dropbox.com/s/k808ms8ey33r5u8/gstest.zip?dl=0 which you can boot up to see the problem. If you run it (even through the editor) with the Console app open, you can see the line which Apple doesn't like:
19/11/15 4:45:09.000 PM kernel: Sandbox: Unity(16903) System Policy: deny(1) file-write-create /usr/share/.mono
If the GameSparksUnity component is removed from the scene, that line doesn't come up. As far as I can tell it's occurring just before the GameSparks tells the app that the GameSparks service available.
That log message might not come up on OS X version prior to 10.11, as they only introduced System Integrity Protection with El Capitan.
Do you have a stack trace of when this write is happening?
If you could send us the details of how you have built and how we can reproduce this issue we'll take a look at it.