Hardened Runtime for Notarization

Unity Engine
,
1

I’ve got some questions about the support Unity has for notarization and, in particular, the hardened runtime that will be required for notarization past January 2020. Right now Apple have waived a few requirements, which is okay as a temporary measure, but it seems a long term solution for Unity games (especially legacy products) is currently not available.

This is what I have observed right now, in LTS 2018.4.11f1:

When using the legacy .NET 3.5 runtime, an empty Unity project, and codesigning with a hardened runtime (–options runtime), the application crashes at launch. If you execute it from a console, you’ll see the following output:

In this case, it seems that libmono.0.dylib is built against sdk 10.6 (which is below Apple’s minimum requirements for the hardened runtime).

otool output:

When using the .NET 4.x runtime, the same empty Unity project, and codesigning with the same options, the application hangs at launch. If you execute it from a console, you’ll see the following output:

When using IL2cpp on either runtime, with Xcode 11 installed, the build fails (issue reported here ). If you workaround it or use an older version of Xcode, both of these builds run successfully after codesigning with hardened runtime.

All the builds above use the same entitlements:

And the following codesign invocation

And all variations of the build successfully pass notarization when built with the hardened runtime, even though the builds do not actually run. When not hardened, it of course passes as well (see Apple announcement of relaxation of notarization requirements linked at the start of this post), but with the caveat that it won’t very soon.

It seems that the only viable way to produce a notarizable build to Apple’s standards right now is to use il2cpp. We can ship an unhardened product for now, but if we wish to maintain this product past January, that won’t work anymore. All this is potentially infeasible for legacy projects. Is there a roadmap for complete Unity support here? Have I missed something?

2 Likes
2

I’ve reported a bug
https://fogbugz.unity3d.com/default.asp?1201299_jg4lqmsq8vbpiqo0

Can someone of Unity please look into this? It is pretty urgent considering Apple will enforce this in January.

3

Could you re-submit the bug with 2018.4 LTS?

4

Just ended up here after a google search with the same problem. The issue seems to be within the entitlement file not the command to sign itself. I added the following to my entitlements and it works with mono 4.x Unity 2018.4.22f1:

<?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.disable-executable-page-protection</key>
<true/>
</dict>
</plist>

I also see others recommending “com.apple.security.cs.disable-library-validation” although it worked for me without it. Note that there might be safer methods to do this. “disable-executable-page-protection” seems to come with some security issues. See: Disable Executable Memory Protection Entitlement | Apple Developer Documentation

The root issue is likely that apple tries to block just in time compilation similar to what they do on iOS

1 Like