iOS support

[p-lindberg]

The base library is built for iOS, but I don't believe the current approach works in practice. In my preliminary testing it failed to load the library at runtime (although I should mention this was in a Unity game, where the iOS build pipeline is a bit finicky).

Are you currently verifying the iOS support in any way?

I'm not an iOS developer by trade, but based on what I know from previous experience with integrating native libraries on iOS, in order to properly load a dylib on an iOS device,

• It must be wrapped in a framework (basically a directory named {library_name}.framework, containing the library and an Info.plist file with various metadata).
• The library file itself should not have a file extension (but this might just be convention)
• The library's install name property should be of the form @rpath/{library_name}.framework/{library_name}. This can be set using install_name_tool -id {new_install_name} path/to/library on MacOS (and read using otool -l path/to/library). I'm not 100% sure if the @rpath/ prefix is necessary though, as I don't remember the exact details around it right now.

AFAIK, it is possible to load a "bare" .dylib file, but it only works in development builds and will fail when attempting to build a release archive, specifically due to code signing issues IIRC.

Oh, and the current install name is liblmdb.so (set by the compiler, not updated when the file gets renamed), which is probably why it fails to load right now, even in development builds.

Setting up a proper Xcode build pipeline that outputs a framework directly is probably not too complicated, but I don't have the exact details on hand atm. Another way to do it is to just set up the expected folder structure and Info.plist file manually and use install_name_tool to set the correct install name, but this is a bit more fragile.

Finally, I believe clients also need to register the framework in their Xcode project in order for things to work, so some manual intervention may be necessary in the end.

I will be looking further into this in the coming days, but I'm not sure if I'll be able to allocate enough time to submit a proper PR - I may need to go with the hacky solution of manually creating a framework around the library file for now.

[CoreyKaylor]

Any pointers hacky or otherwise would be appreciated even if you can't get in a PR.

[p-lindberg]

One issue that became apparent when digging further into this is that the library name constant MDB_DLL_NAME needs to be different on iOS: lmdb.framework/lmdb instead of lmdb. This is unfortunate since the library name must be a constant in order to be used in attributes. This likely means that we either need to compile a different version of the DLL for iOS targets, or set up the FFI bindings dynamically using dlopen and dlsym (would be a lot of work though). Thoughts?

[CoreyKaylor]

I'm a little confused, not that I think you're wrong but I'm starting to wonder why the nuget package even supports iOS target native binaries if this is how it has to work. Feels like that would be a wrench in every use-case.

[CoreyKaylor]

Is it possible to call NativeLibrary.Load with that path explicitly on iOS and still have the native methods mapped accordingly with the default name? I suspect it might be possible.

[CoreyKaylor]

I think something like this is probably more promising.

NativeLibrary.SetDllImportResolver(
            typeof(NativeMethods).Assembly,
            (string libraryName, Assembly assembly, DllImportSearchPath? searchPath) =>
            {
                if (libraryName != "lmdb") return IntPtr.Zero;  // Ignore other libs

#if NET6_0_OR_GREATER
                if (OperatingSystem.IsIOS())
#else
                if (RuntimeInformation.IsOSPlatform(OSPlatform.Create("IOS")))
#endif
                {
                    // Load iOS framework path
                    return NativeLibrary.Load("lmdb.framework/lmdb");  // Or "@rpath/lmdb.framework/lmdb" or "Frameworks/lmdb.framework/lmdb"
                }
                else
                {
                    // Default or other platforms
                    return NativeLibrary.Load("lmdb");  // Runtime will add extensions/paths as needed
                }
            });
    }

[p-lindberg]

I'm a little confused, not that I think you're wrong but I'm starting to wonder why the nuget package even supports iOS target native binaries if this is how it has to work. Feels like that would be a wrench in every use-case.

I think the wrench is courtesy of Apple in this instance, with their design choices around frameworks. I find it peculiar that we can't just dlopen("libname") when this is the standard on all other platforms, and instead have to pass in a path that goes inside the framework. The location of the binary inside the framework directory is fixed anyhow AFAIK, which would make the path redundant.

Is it possible to call NativeLibrary.Load with that path explicitly on iOS and still have the native methods mapped accordingly with the default name? I suspect it might be possible.

While I believe this might work, as well as the NativeLibrary.SetDllImportResolver approach you outlined below, the NativeLibrary API is not supported in .NET Standard 2.1 and older as far as I can tell, so an alternative solution is necessary in order to retain backwards compatibility. This would be necessary for my use case, as Unity only supports .NET Standard 2.1. Hopefully there is an equivalent older API that can be used to achieve the same result; otherwise I think it may be necessary to build a platform specific DLL of the managed code just for iOS.

Another thing: it may be more convenient to statically link the library on iOS, as it avoids the need to set up a framework and complicate the build pipeline. May yield better load times for the binary as well, but I don't know if it's significant. In that case, the binding would need to be against __Internal instead. One possibility to avoid divergent platform implementations could perhaps be to use static linking on all platforms, then we'd just have __Internal everywhere. But I'm not sure right now if other platforms have other constraints.

I will experiment some more.

[p-lindberg]

After some more digging I found that static linking and __Internal binding doesn't work on all platforms. It seems to be an iOS / AOT-compilation thing. It does however seem like it may be the most convenient and efficient solution on iOS.

I think a possible solution based on static linking may look something like this:

• Copy the .a file instead of .so file when deploying the compiled library to the runtimes folder for iOS targets
• Add iOS targets to the .csproj file (to build the platform-specific DLLs)
• Use compiler directives to set MDB_DLL_NAME to __Internal when compiling for iOS.
• Add the static library to the LightningDB.targets file so that MSBuild knows how to include it when building the app binary

This would be slightly less work than the dynamic route, as that requires the framework wrapping on top of everything else.

The last step I believe is necessary in order for things to work when building MAUI apps, as the MSBuild pipeline apparently handles the whole build process there (I've never used it myself though). For Unity games, the static library should be added automatically to the Xcode project produced by Unity, as long as one tags the file as an iOS library in the Unity editor. Finally, I think this approach should work with Xamarin apps as well, but not sure how relevant that is.