Plugin Inspector

Use the Plugin InspectorA Unity window that displays information about the currently selected GameObject, Asset or Project Settings, alowing you to inspect and edit the values. More info
See in Glossary to specify the conditions under which Unity loads and references a plug-inA 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 file. You can also specify various other platform-specific settings for a plug-in.

Select a plug-in file in the Project window to view the Plugin Inspector:

General

The Auto Reference setting controls how a plug-in file is referenced by other assemblies and assembly definitions in the project.

If Auto Reference is enabled, which is the default, then all predefined assemblies and assembly definitions automatically reference the plug-in file. Disable Auto Reference if you want to explicitly declare references to the plug-in instead.

You can declare references to a plug-in file for an assembly definition using the Assembly Definition Inspector window. See Script Compilation and Assembly Definition Files for more information.

When you disable Auto Reference you cannot reference a plug-in from the predefined assemblies created for your project by Unity. These predefined assemblies contain all the scriptsA piece of code that allows you to create your own Components, trigger game events, modify Component properties over time and respond to user input in any way you like. More info
See in Glossary in your project that you have not assigned to another assembly using an assembly definition file. Only code included in an assembly created with an assembly definition file can reference classes, functions, or other resources in a plug-in that has the Auto Reference property disabled.

The Auto Reference option has no effect on whether a file is included in the build. When you disable the Auto Reference option, Unity will not automatically reference the file during compilation. To control Build Settings for plug-ins use Platform settings.

Disable Auto Reference in order to limit the scope in which a plug-in can be referenced by explicitly declaring all references to that plug-in. For example, if only one set of scripts in your project use a plug-in, you could create an assembly definition file for those scripts and create an explicit reference to the plug-in. Because the plug-in is no longer automatically referenced throughout your project, other scripts in your project cannot mistakenly use the plug-in. (More than one assembly can use the plug-in, but all assemblies must explicitly declare the dependency.) Also, if you change the plug-in, only the dependent assemblies must be recompiled, not your entire project.

You can also use explicit references to plug-ins to prevent plug-ins used in an Asset packageA collection of files and data from Unity Projects, or elements of Projects, which are compressed and stored in one file, similar to Zip files. Asset packages are a handy way of sharing and re-using Unity Projects and collections of Assets. More info
See in Glossary from conflicting with other code in a project into which the package is imported.

Select platforms for plugin

Use the Select platforms for plugin setting to define the platforms with which a plug-in file is compatible and should be used on. The list of platforms includes the Editor itself (for Play mode and for any scripts that run at edit time), Standalone, and platforms for which you have installed Unity build support, such as Android, iOSApple’s mobile operating system. More info
See in Glossary, and WebGLA JavaScript API that renders 2D and 3D graphics in a web browser. The Unity WebGL build option allows Unity to publish content as JavaScript programs which use HTML5 technologies and the WebGL rendering API to run Unity content in a web browser. More info
See in Glossary.

You can check Any Platform and, optionally, exclude individual platforms. Or you can uncheck Any Platform and, optionally, include individual platforms.

Platform settings

Once you have selected the platforms, you can specify additional options such as CPU type and specific OS from the separate Platform settings section below. This area of the Inspector window contains a tab for each selected platform. Some platforms have no settings, or just a few (such as CPU and OS selection).

When possible, the Inspector only shows settings that apply to the plug-in type on a specific platform. For example, for a native plug-inA platform-specific native code library that is created outside of Unity for use in Unity. Allows you can access features like OS calls and third-party code libraries that would otherwise not be available to Unity. More info
See in Glossary file with a .dll extension, the Inspector only shows the options that apply to Windows since such a plug-in can only be used on Windows.

Note: Native plug-ins cannot be unloaded. If a plug-in has already been loaded by the Editor, it remains loaded even after you change the settings for that plug-in in the same Editor session. To unload the plug-in, you must restart Unity.

Editor settings

Use the Editor platform settings to specify the CPU architectures and operating systems with which the plug-in is compatible.

Most managed plug-insA managed .NET assembly that is created with tools like Visual Studio for use in Unity. More info
See in Glossary are compatible with any CPU and OS, but native plug-ins are typically only compatible with a single OS and, depending on how they were compiled, might be compatible with only a single CPU architecture.

For instance, if you select CPU X86, Unity loads the plug-in when you run an older, 32-bit version of the Editor, but not when you run a 64-bit version.

Similarly, if you select OS Windows, Unity loads the plug-in when running the Editor on Windows systems, but not on OS X or Linux systems.

Standalone settings

For the Standalone platforms, Windows, OS X, Linux, you can choose the CPU architectures with which a library is compatible. Managed libraries are typically compatible with any OS and architecture unless they access specific system APIs. Native libraries are only compatible with a single OS, but can be compatible with the 32-bit, the 64-bit, or both CPU architectures.

See also: Player settings for Standalone platforms.

Universal Windows Platform

Universal Windows Platform plug-in settings are covered in their own section. For more information, see Universal Windows Platform: Plugins on IL2CPP Scripting Backend.

Android

For plug-in files that are potentially compatible with Android, you can choose the CPU architecture. The chosen architecture must match the architecture for which the library was compiled. Unity does not validate whether you choose the correct setting.

iOS and tvOS

The iOS and tvOS settings allow you to specify which iOS frameworks a plug-in depends upon, if any.

For dynamically loaded libraries, as well as for bundles and frameworks containing dynamically loaded libraries or any assets and resources that need to be loaded at run time, check the Add to Embedded Binaries option. When you check this option, Unity sets the Xcode project options to copy the plug-in file into the final application package.

For plug-in source code files, which must be compiled as part of the build, you can specify any flags needed when compiling in the Compile Flags field.

Define Constraints

Use the Define Constraints setting to specify symbols that must be defined (or undefined) in order for the plug-in file to be used.

Unity only loads and references a plug-in if all the Define Constraints are satisfied. Constraints work like the #if preprocessor directive in C#, but on the assembly level instead of the script level. All the symbols in the Define Constraints setting must be defined for the constraints to be satisfied. You can also specify that a symbol must be undefined by prefixing it with a negating ! (bang) symbol. For example, if you specify the following symbols as your Define Constraints:

the constraints are satisfied when the symbol ENABLE_IL2CPP is NOT defined and the symbol UNITY_2018_3_OR_NEWER IS defined. Or to put it differently, this assembly is only loaded and referenced on non-IL2CPP scripting runtimes for Unity 2018.3 or newer.

You can use any of Unity’s built-in define symbols or any symbols defined in the project’s Scripting Define Symbols Player setting. See Platform dependent compilation for more information, including a list of the built-in symbols. Note that the Scripting Define Symbols settings are platform-specific. Make sure that you define the necessary symbols on all the relevant platforms.

Plugin detection

Unity detects whether a file in your Assets folder is a plug-in by its file extension. It treats files with the following extensions as plug-ins:

• .dll
• .winmd
• .so
• .jar
• .aar
• .xex
• .def
• .suprx
• .prx
• .sprx
• .rpl
• .cpp
• .cc
• .c
• .h
• .jslib
• .jspre
• .bc
• .a
• .m
• .mm
• .swift
• .xib
• .dylib

Unity also treats certain folders as bundle plug-ins. Unity does not look for additional plug-in files within such folders, so everything within the folder is considered a single plug-in. Unity detects whether a folder is a bundle plug-in when it has one of the following extensions:

• .framework
• .bundle
• .plugin

Finally, Unity treats folders found with a parent path matching exactly Assets/Plugins/Android/ as an Android Library plug-in folder. Unity handles such folders in the same way as folders with the special extensions: .plugin, .bundle and .framework.

Default settings

Unity sets defaults for the import settings of a plug-in file according to the folder where the plug-in is located: