Version: 2017.4 (switch to 2019.1)
Native plug-ins
Low-level native plug-in interface
Other Versions

Building plug-ins for desktop platforms

This page describes native code plug-ins for desktop platforms (Windows/Mac OS X/Linux).

Building a plug-in for Mac OS X

On Mac OSX, plug-ins are deployed as bundles. You can create the bundle project with XCode by selecting File->NewProject… and then selecting Bundle -> Carbon/Cocoa Loadable Bundle (in XCode 3) or OS X -> Framework & Library -> Bundle (in XCode 4)

If you are using C++ (.cpp) or Objective-C (.mm) to implement the plug-in then you must ensure the functions are declared with C linkage to avoid name mangling issues.

extern "C" {
  float FooPluginFunction ();
}

Building a plug-in for Windows

Plug-ins on Windows are DLL files with exported functions. Practically any language or development environment that can create DLL files can be used to create plug-ins. As with Mac OSX, you should declare any C++ functions with C linkage to avoid name mangling issues.

Building a plug-in for Linux

Plug-ins on Linux are .so files with exported functions. These libraries are typically written in C or C++, but any language can be used. As with the other platforms, you should declare any C++ functions with C linkage in order to avoid name mangling issues.

32-bit and 64-bit libraries

The issue of needing 32-bit and/or 64-bit plug-ins is handled differently depending on the platform.

Windows and Linux

On Windows and Linux, plug-ins can be managed manually (e.g, before building a 64-bit player, you copy the 64-bit library into the Assets/Plugins folder, and before building a 32-bit player, you copy the 32-bit library into the Assets/Plugins folder) OR you can place the 32-bit version of the plug-in in Assets/Plugins/x86 and the 64-bit version of the plug-in in Assets/Plugins/x86_64. By default the editor will look in the architecture-specific sub-directory first, and if that directory does not exist, it will copy plug-ins from the root Assets/Plugins folder instead.

Note that for the Universal Linux build, you are required to use the architecture-specific sub-directories (when building a Universal Linux build, the Editor will not copy any plug-ins from the root Assets/Plugins folder).

Mac OS X

For Mac OS X, you should build your plug-in as a universal binary that contains both 32-bit and 64-bit architectures.

Using your plug-in from C#

Once built, the bundle should be placed in the Assets->Plugins folder (or the appropriate architecture-specific sub-directory) in the Unity project. Unity will then find it by name when you define a function like this in the C# script:-

[DllImport ("PluginName")]
private static extern float FooPluginFunction ();

Please note that PluginName should not include the library prefix nor file extension. For example, the actual name of the plug-in file would be PluginName.dll on Windows and libPluginName.so on Linux. Be aware that whenever you change code in the plug-in you will need to recompile scripts in your project or else the plug-in will not have the latest compiled code.

Deployment

For cross platform plug-ins you must include the .bundle (for Mac), .dll (for Windows), and .so (for Linux) files in the Plugins folder. No further work is then required on your side - Unity automatically picks the right plug-in for the target platform and includes it with the player.

Examples

Simplest plug-in

This plug-in project implements only some very basic operations (print a number, print a string, add two floats, add two integers). This example may be helpful if this is your first Unity plug-in. The project can be found here and includes Windows, Mac, and Linux project files.

Rendering from C++ code

An example multiplatform plug-in that works with multithreaded rendering in Unity can be found on the native plug-in interface page.

Did you find this page useful? Please give it a rating:

Native plug-ins
Low-level native plug-in interface