iOS Binding Library in MAUI

Aakash Pandey 0 Reputation points

I have a native iOS SDK Library which I have been trying to integrate in my MAUI app for iOS/Android via iOS Binding Project. The iOS SDK xcframework has certain classes in the headers folder which I suppose are public headers. My query is : Can the binding be created only for the classes which are part of public headers or can it also bind to the private classes which actually only in the binary or runtime but not exposed. I have been getting errors whenever I have tried to bind the classes in ApiDefinition.cs (of iOS Binding Project) which are not header files. The error is something like:

clang++ exited with code 1:
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 (use -v to see invocation)

As soon as I remove _OPPTransaction from bindings, this compiles and runs on simulator but eventually I need that class and some of its properties. So before I raise an issue, I wanted to know if MAUI can actually create bindings for the private classes

0 comments No comments
Sign in to comment

2 answers

  1. Nancy Vo (WICLOUD CORPORATION) 6,025 Reputation points • Microsoft External Staff • Moderator

    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

    1. Nancy Vo (WICLOUD CORPORATION) 6,025 Reputation points • Microsoft External Staff • Moderator

      Hi @Aakash Pandey ,

      I wonder if there is any update on this post. If you have any question, feel free to reach out. I'm happy to support you. 

    2. Nancy Vo (WICLOUD CORPORATION) 6,025 Reputation points • Microsoft External Staff • Moderator

      Hi @Aakash Pandey ,
      If you're still interested or have any questions, feel free to reach out whenever it works best for you.

    Sign in to comment

  2. AI answer

    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:

    AI-generated content may be incorrect. Read our transparency notes for more information.
Sign in to answer

Your answer