iOS Binding Library in MAUI

Hi @Aakash Pandey ,

Thanks for your question.

When you include a private class like OPPTransaction in ApiDefinition.cs, the linker fails with the "Undefined symbols" error because the Objective-C class symbol is not exported and therefore not visible to your app. Removing it eliminates the invalid reference, allowing the build to complete successfully.

In the Binding iOS Libraries documentation, the binding workflow is described in terms of parsing header files to map the public API into binding definitions. Because of this, MAUI is not in a supported way to create bindings for the private classes.

I hope this addresses your question. If this response was helpful, please consider following the guidance to provide feedback

Bindings can only be created for APIs that are actually exported by the native framework and visible to the Objective-C/Swift runtime through public headers (or a module map). If a class is not declared in the framework’s public headers (or otherwise exported), it cannot be reliably bound and used from .NET.

Objective Sharpie and .NET iOS bindings work by parsing the framework’s headers and mapping the public Objective‑C API surface into C# (ApiDefinition.cs and StructsAndEnums.cs). The binding project then links against the native framework. If a symbol such as _OBJC_CLASS_$_OPPTransaction is referenced in the binding but is not actually exported by the framework for the target architecture, the native linker fails with errors like:

Undefined symbols for architecture x86_64:
  "_OBJC_CLASS_$_OPPTransaction", referenced from:
      <initial-undefines>
ld: symbol(s) not found for architecture x86_64
clang++: error: linker command failed with exit code 1

This indicates that OPPTransaction is not present (or not exported) in the simulator slice of the xcframework, or it is not part of the public API surface. Removing the binding for that type removes the reference, so the linker succeeds.

In practice:

• Bindings should be created only for types and members that are part of the framework’s public API (i.e., present in the public headers or module map and exported in the binary for the relevant architectures).
• Private or internal classes that exist only in the binary and are not declared in public headers are not supported binding targets. Attempting to declare them manually in ApiDefinition.cs without matching exported symbols will always result in linker errors like the one shown.
• If a type is intended to be used by consumers, it should be exposed by the SDK vendor via public headers (or a public wrapper API). For MAUI, a common pattern is to create a native “wrapper” framework with a simplified, public API surface and then bind that, as described in the Native Library Interop approach.

So, MAUI and the iOS binding mechanism cannot safely or reliably bind to private classes that are not part of the framework’s public, exported API. The SDK vendor would need to expose OPPTransaction (or a suitable public wrapper) for it to be bindable.

References:

• Creating Bindings with Objective Sharpie
• Binding Native Frameworks
• ApiDefinitions & StructsAndEnums Files
• Native Library Interop
• Getting started with Native Library Interop