I’ll try again today. It’s completely possible I did miss something.
1 Like
Update: I also had to add some entitlements (add --entitlements entitlements.plist to the codesign command) for it to work:
<?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>
<key>com.apple.security.cs.allow-jit</key>
<true/>
<key>com.apple.security.cs.allow-unsigned-executable-memory</key>
<true/>
<key>com.apple.security.cs.allow-dyld-environment-variables</key>
<true/>
</dict>
</plist>
1 Like
And is this all confirmed to be working now? I’d like to summarise and put it in a manual.
1 Like
Make sure it’s labeled as for macOS codesign with notarization for non-Mac App Store distribution (such as Steam).
Mac App Store distribution steps still need to be verified working.
Yes, confirmed working. We have builds on Steam done like this. 
1 Like
I have taken a stab at documenting the macOS bundling and distribution process:
I’d appreciate feedback on the document. Is there any step missing? Is something unclear?
1 Like
Hi! For distribution outside of the App Store, you still need to add entitlements for it to run (add --entitlements entitlement.plist to the codesign command). See above for the entitlements I used (you probably don’t need com.apple.security.cs.allow-dyld-environment-variables but I didn’t test without).
One extra note is that the Steamworks SDK, if you use that, requires an extra entitlement: com.apple.security.cs.disable-library-validation.
You probably need similar or different entitlements for the App Store as well, but I didn’t publish anything on the App Store, so can’t speak for sure.
1 Like
Ah, thanks, missed that! Added to the docs now.
I will try this myself when I have some time.
1 Like
As soon as you can get working steps I will submit FSR and FSH to the Mac App Store. 
Where did you get stuck when trying? Did the application loader not accept the game?
No, everything upload wise worked. Apple rejected it because of a sandbox violation? I had the sandbox stuff setup properly as far as I could tell from online guides.
Edit: Looking at the error I got the last time it was this.
“A sealed resource is missing or invalid” - Do you have any filenames containing weird characters?
“Unsealed contents present in the bundle root” - Could this be FMOD banks?
This!!! FMOD banks should be in Contents/Resources, not directly in bundled_resources root on macOS. You can duplicate them for each platform (git probably de-duplicates files, so wouldn’t take too much repo space) or write a script that puts them in the appropriate dir for each platform before bundling (what we do in Interrogation).
3 Likes
I changed it so the folder structure is like so and updated code. Game works with FMOD working when ran before signing.
I followed https://defold.com/manuals/macos/ with some modifications noted below.
I’m able to sign, make pkg, and upload.
What am I doing wrong?
The game launches before I codesign, but after it crashes. This happens only after adding the sandboxing to the entitlements. Without sandboxing, I can run and play fine, but I cannot pkg/upload that to Mac App Store.
Termination Reason: Namespace CODESIGNING, Code 0x1
One difference between the current doc codesign step and one I did before was “3rd Party Mac Developer Application: Your Team Name” does this matter or is it only the identity that matters?
I’m going to submit the build I uploaded today even though it doesn’t run locally and see what happens.
These are the extra steps I am taking:
Before doing codesign edit the Info.plist to add an app category
For example,
<string>public.app-category.card-games</string>
Make sure the Bundle name is the name of your game
Edit the entitlement.plist to add sandboxing
<?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>
<key>com.apple.security.cs.allow-jit</key>
<true/>
<key>com.apple.security.cs.allow-unsigned-executable-memory</key>
<true/>
<key>com.apple.security.cs.allow-dyld-environment-variables</key>
<true/>
<key>com.apple.security.app-sandbox</key>
<true/>
</dict>
</plist>
Then codesign
codesign --force --sign “Developer ID Application: Devname” --options runtime --deep --timestamp --entitlements entitlement.plist “Game.app”
Now you need to create a pkg
Get your developer ID from your Keychain it looks like this: DZ2-------
productbuild --component "Game.app" /Applications --sign DEV_ID_HERE Game.pkg
Now you can upload with Application Loader.
Or rather I will not submit build as it failed with signing. I’ll compare old steps I did before that got past this point…
Edit
Trying to submit with these
codesign --force --sign "3rd Party Mac Developer Application: Name" --entitlements entitlement.plist "Game.app" --deep
productbuild --component "Game.app" /Applications --sign DEV_ID --product "Game.app/Contents/Info.plist" Game.pkg
These ones worked
Already reviewed! And it failed.
Here’s the old failure after submission (the errors I posted previously… I am pretty sure I did move the files into the right folder before but discarded them since they didn’t help with the review only with uploading).
Here’s the message today
Once again… please… someone try this process and see if you can get a build actually approved by Apple to go live. 
I looked at the error again and noticed there was another section on private symbol usage.
Guideline 2.1 - Performance
We discovered one or more bugs in your app when reviewed on Mac running macOS 10.15.2.
The app displays an error message on launch.
Next Steps
Please run your app on a device to identify the issue(s), then revise and resubmit your app for review.
Guideline 2.5.1 - Performance - Software Requirements
Your app uses or references the following non-public APIs:
Found private symbol usage:
__dyld_find_unwind_sectionsThe use of non-public APIs is not permitted on the App Store, because it can lead to a poor user experience should these APIs change.
We are constantly reevaluating and identifying non-public APIs that you may have been using for an extended period of time. You should always use public APIs and frameworks and ensure they are up-to-date to prevent this issue in the future.
Next Steps
If you are using third-party libraries, please update to the most recent version of those libraries. If you do not have access to the libraries’ source, you may be able to search the compiled binary using the “strings” or “otool” command line tools. The “strings” tool can output a list of the methods that the library calls and “otool -ov” will output the Objective-C class structures and their defined methods. These tools can help you narrow down where the problematic code resides.
Continuing to use or conceal non-public APIs in future submissions of this app may result in the termination of your Apple Developer account, as well as removal of all associated apps from the App Store.
Resources
If there are no alternatives for providing the functionality your app requires, you can use Feedback Assistant to submit an enhancement request.
If you are unable to reproduce this issue, ensure you are testing the exact version of the app that you submitted for review, and that you’re doing so in a minimally privileged environment. See Technical Q&A QA1778: How to reproduce bugs reported against Mac App Store submissions.
For information on how to symbolicate and read a crash log, please see Technical Note TN2123 - CrashReporter.
Please see attached screenshot for details.
1 Like
I will make a vanilla engine game soon and submit it to verify nothing else is blocking submission.
1 Like