We’ve written a automated workflow / guide to prepare distribution for OSX (from start to finish) in and outside of the Appstore. Based on all the guides & bits ‘n pieces we could find. Together with an extensive full guide that’s (hopefully) accessible for beginners & useful for people who are troubleshooting. We also included DIY if the scripts scare you
We were able to deliver to Apple using this workflow, but for sure there are a lot of other factors that could mess up this process. So if you find missing pieces or mistakes, please let us know.
If anyone wants to become a collaborator please PM me even if its to update the documentation page. Obviously there are not a lot of people developing for OSX but with a bit of help it could be a place to find all info needed on this enigma. We’ve incorporated everything we could find, but for sure there are still many troubleshooting pieces missing.
Also we wrote the words, but rather like a compilation, credit for all the ground work goes to threads/people described in the credits in the readme.
I’d just like to say many thanks to UNSH and their collaborators for their work on this utility. Might have a few questions later, but this is probably going to be a lifesaver for me.
I’m still running into problems with my app being denied network access, even after updating the .entitlements file to include the com.apple.security.network.client key. Is there any way I can check independently that the .app has the required entitlements for network access after signing?
EDIT: I should also mention that “spctl -a MyAppName.app” is giving a ‘rejected’ result, but the SignAndPackage script seems to exit without complaints.
Ok can you elaborate a little bit more. You used a second macbook that didn’t have an old provisioning profile on it and you needed to download it again?
To start off there was a bug about 7 days ago in the build so make sure you have the latest version. The problem was that it didn’t refer to the correct entitlements file so check that first. I’m responsible for UZDW and I’m currently on holiday with only my phone so it’s a bit difficult to delve deep. I updated the git but I can’t test it right now and my collegues are on windows. Also we compiled this workflow based off other peoples input and as an attempt to work together to include all pitfalls, but we are by no means specialists. What the doc describes is what we encoutered, beyond that our experience is little. But I’ll try my best from here.
I can check independently that the .app has the required entitlements for network access after signing?
I don’t think so, you should be able to read the log @ utilities>console and check what errors you get when you open the app. And use that as reference.
Beyond that I think you have to check with the entitlements and figure it out with the Apple docs. There is a reference to the entitlements page in the doc.
Our app downloads from gdrive and we had no problems with the entitlement in the examples. But I don’t know what your game does.
I should also mention that “spctl -a MyAppName.app” is giving a ‘rejected’ result, but the SignAndPackage script seems to exit without complaints.
I don’t believe that the signing checks your entitlements, it just signs with what you provide it.
I’m sorry I can’t be much of a help but I have very little access here.
Okay then, thanks for the feedback UNSH. I think I’m using the latest version (I only bumped into this script on monday or so), but I’ll double-check my results and get back to you.
If I didn’t make any mistakes fixing it on my phone, Monday’s version should be ok. I’m back next monday so then I’ll know for sure and maybe I can help you more. Either way let me know what happens so we expand the documentation of the lost
Hey UNSH- two points I’m confused about. When I look at the final-stage signing script, I notice that the ‘dev’ option (for creating a testable version of the app-store build) doesn’t use the entitlements file during signing, but the ‘outside’ option does? The functioning of my app’s network-calls depends on the correct use of entitlements, so is the ‘outside’ option more useful for testing purposes? (It seems rather counter-intuitive.)
My other question, if you know the answer off-hand: What is the difference between a Unity build with ‘mac app store validation’ set to ‘on’ vs. ‘off’? Is it a change to the binary itself or a permission in the .plist or something else that could be relatively easily tweaked by external scripts?
Hi, as we don’t use any Appstore features I haven’t really tested this beyond checking if the app opens, but it does indeed seem. Honestly I quite literally followed this tutorial (at the bottom of the page), which states you should not add the entitlements for a testing build. So I added the code, but without further testing as we didn’t need it. This workflow is a work in progress and I can only confirm the things crossing my path.
I just checked two builds and I see no difference between the two plist files. It may be possible, but my first guess is you can’t.
There also crept in a mistake in building the test build, I’m fixing it now.
EDIT: Ok so the product build command for dev was not correct so that may very well be it, I’m not sure what I did there but it should be fixed. I tested and it worked for me here. I updated the git so try again to see if it works. If it doesn’t work pm me or mail me so I send you a version to test product build with entitlements.
Thanks UNSH. I was actually able to submit successfully to the app store using the older version of the script last week. The two other questions were largely a matter of curiosity, since I was thinking of rolling up another script to create all 3 versions (dev, store and external) simultaneously.
On that final note- once the signing step for external distribution is completed, should it be possible to create a .dmg from the signed .app, rather than a .zip or .pkg file?
I believe that once its signed your good to go. The zipped file is also just a copy of the signed app file. But again not tested and not 100% sure.
Would you mind telling what the problem was with the denied network access? Also if you want to add to the workflow let me know or just push to the git.
Hey UNSH- sorry for not getting back. The network access denial was simply because of com.apple.security.network.client being missing from the entitlements file- it wasn’t difficult to patch in once I understood the flow.
Thank you so much for this workflow! I has helped me greatly understand the process of what needs to happen for my macOS builds. However, I do have an error that I get after this workflow is complete.
Even if I go through an manually sign the process I still get this error. This happens after I add iCloud to our entitlements. If I remove the iCloud entitlements, the game will launch but crash on the first frame asking for iCloud.
Does anyone have any idea why the iCloud entitlements would brick the build? The provision profile that I am using has them correctly enabled.
Icloud is completely untested (because we didn’t need it) and apparently not working. I’ve been talking to someone who is also having this problem and found there’s this guide from Kitteh Face that describes how they did it. I am now updating the docs and code according to their findings but I can’t really test it. So if you could get the latest git and see if it works and let me know what happens because I am working blind.
Make sure your provisioning profiles were made with iCloud capabilities already configured.
There is a new entitlements file for iCloud development that you need to adjust accordingly
Before you run SignAndPackage (Taken from kittehface.com) Modify the Unity executable to link the CloudKit framework.
Following from the eppz! blog, you need to use the third party tool optool.
Run the command optool install -c load -p “/System/Library/Frameworks/CloudKit.framework/Versions/A/CloudKit” -t “.app/Contents/MacOS/”
This will modify the Unity binary to load the CloudKit framework at startup. We found that without this - even though the CloudKit framework is linked in the Prime31 plugin - actual calls to CloudKit will fail with the error “connection to service names com.apple.cloudd was invalidated”.
