Building your macOS application

For macOS applications, there are platform-specific requirements that change the build process. Also, some digital distribution services that can host macOS applications have different requirements. For example, the Mac App Store doesn’t require you to notarize your application because the upload process includes similar content validation to notarization. If you are targeting a specific digital distribution service with your build, check the documentation for that Digital distribution service first to check if the requirements differ.

Target architecture

Before you build an application for macOS, be aware of the chipset differences between Apple devices. Some Apple devices use Intel chipsets and others use Apple silicon. You can use Unity to create both architecture-specific builds and builds that target both Intel and Apple silicon. The available target architectures are:

• Intel 64-bit: Creates a macOS build for Apple devices that use Intel chipsets.
• Apple silicon: Creates a macOS build for Apple devices that use Apple silicon architecture.
• Intel 64-bit + Apple silicon: Creates a macOS build that works on both Intel chipsets and Apple silicon. Note: This results in a build that is larger than the individual architecture-specific builds. This impacts overall application size.

Building

To build your Unity application:

1. Open the Build Settings window (menu: File > Build Settings).
2. In the Platforms list, select PC, Mac & Linux Standalone.
3. Set Target Platform to macOS. If macOS isn’t an option, add the Mac Build Support module to your Unity Editor install. For information on how to install modules, see Add modules.
4. Set Architecture to the architecture type you want Unity to build your application for. For more information about target architecture for macOS, see Target architecture.
5. If you want to create an Xcode project for your application, enable Create Xcode Project.
6. Click Build.

Information property list file

macOS applications require an information property list file called Info.plist that contains metadata and configuration information for the application. The file is organized as a list of key-value pairs. For more information about information property list files, see About Information Property List Files. For more information about the Info.plist in particular, see About Info.plist Keys and Values.

When Unity builds your application, it creates the Info.plist file. Unity stores this file at ApplicationName.app > Contents > Info.plist. Unity displays required Info.plist configuration properties in the Player SettingsSettings that let you set various player-specific options for the final game built by Unity. More info
See in Glossary window that you can set before building the application. These properties are in the Other Settings > Mac App Store Options section.

There are additional keys that you can add to your Info.plist file. To add them, build the application and use a text editor to edit the file. For information about the available keys, see About Info.plist Keys and Values.

Entitlements

macOS applications require entitlements to specify permissions and restrictions that allow or prevent your application from taking specific actions. At a minimum, your application must include entitlements that result in a Hardened Runtime. These entitlements protect your application from code injection, hijacking of dynamically linked libraries, and memory tampering.

To define entitlements, macOS applications use an xml file with the .entitlements file extension. macOS applications then use the code signing process to bind the entitlements to an application.

If your application uses plug-insA set of code created outside of Unity that creates functionality in Unity. There are two kinds of plug-ins you can use in Unity: Managed plug-ins (managed .NET assemblies created with tools like Visual Studio) and Native plug-ins (platform-specific native code libraries). More info
See in Glossary that perform macOS platform-specific actions, you might need to add entitlements to allow those actions. For more information on what actions require entitlements, see Apple Developer Entitlements.

Code signing

A code signature summarizes the content of an application at the time when the developer creates the code signature. Apple devices use an application’s code signature to detect changes made since the developer created the code signature. This guarantees the integrity of applications and safeguards against tampering. If an application doesn’t have a code signature, the device warns the end user before they open the application. The process of creating a code signature for an application is called code signing. For more information about the technical details of code signing, see macOS Code Signing in Depth.

Unity automatically code signs any application it builds for macOS, regardless of the platform you develop on. This guards against tampering and allows your application to run without warnings, but doesn’t identify you as the developer. This is sufficient to run the application, but to not to notarize it. Norarization requires you to sign the application with a developer or organization ID. When you sign an application with an ID, the digital signature includes a fingerprint of your application as well as a cryptographic signature that identifies you as the developer. Unity doesn’t sign the code it builds with cryptographic information. To do this, you need to sign the code either manually or using Xcode.

Depending on which method of notarization you use, the steps you perform to code sign an application changes. So, for information about how to code sign your application, see Notarizing your macOS application.

Notarization

A valid code signature guarantees the integrity of an application, but it doesn’t guarantee that the application itself isn’t malicious. Notarization is the process Apple uses to validate that Developer ID-signed applications don’t contain malicious content. If Apple doesn’t detect malicious content, it adds a digital tag to the application which indicates that the application is fit for distribution on Apple devices. The results of notarization are also available online for gatekeeping processes to access. Apple keeps an audit trail of applications distributed using your Developer ID. If your ID is exposed, you can use this trail to revoke the execution rights of unauthorized versions of your application. For more information about noratization, see Notarizing macOS Software Before Distribution.

Digital distribution services often require you to notarize your application before you can distribute the application on their platform. However, some digital distribution services, such as the Mac App Store include similar content validation to notarization. This means that you don’t need to notarize your application to distribute it on certain platforms. For more information about digital distribution-specific information, see Digital distribution services for macOS applications.

To notarize your application to run on macOS 10.15 or later, you must first code sign your application with a Developer ID. If you don’t notarize your application, the device warns the end user before they open the application. You don’t need to notarize an application for distribution through the Mac App Store because the submission process includes similar content validation.

Depending on which platform you develop on, the available notarization methods differ. For information about how to notarize your application, see Notarizing your macOS application.