Source and binary forms of native iOS plug-ins

Learn about the different forms of native iOS plug-ins you can create for iOS, tvOS, and visionOS.

You can deliver native plug-ins 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 Inspector 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