Source and binary forms of native iOS plug-ins

Learn about the different forms of native iOS 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 you can create for iOS, tvOS, and visionOS.

You can deliver native plug-insA 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 for iOS, tvOS, and visionOS as source files or precompiled binaries.

Note: When you build your project, Unity copies these assets into the generated Xcode project if their plug-in InspectorA Unity window that displays information about the currently selected GameObject, asset or project settings, allowing you to inspect and edit the values. More info
See in Glossary window settings match the build target. Xcode then compiles and links them into the final application.

Source files

You can provide plug-ins as source files written in Swift, Objective-C, Objective-C++, C, or C++.

The advantages of using source files are as follows:

• Universal compatibility: Works on any device, simulator, architecture, or platform.
• Easy modification: You can easily inspect and change the code.
• Improved debugging: You can debug into the source code directly from Xcode.
• Swift considerations: If you use Swift, the Swift runtime must be embedded into the final app, which can slightly increase the app’s size. This isn’t a concern for visionOS, where the runtime is already included.

Precompiled binaries

You can provide your plug-ins as precompiled binaries. This approach packages your code for distribution and protects your intellectual property by hiding the source code.

Supported binary types include:

• Static libraries (.a).
• Dynamic libraries (.dylib).
• Frameworks (.framework) and XCFrameworks (.xcframework).

Important: Dynamic libraries (.dylib) are for use in the simulator only. Apple doesn’t permit publishing applications that contain .dylib files.

For distributing binaries that support multiple platforms and architectures, the recommended best practice is to use XCFrameworks.

Additional resources

• Initialization paths for native iOS plug-ins
• Conditional compilation behavior for native iOS plug-ins