Thoughts, @mit-mit?

Yes, I agree that this page would benefit from some elaboration. cc @dcharkes

Similar issue flutter/flutter#75537.

I presume that dynamic linking is forbidden on iOS and static linking doesn't work on Android? Or something like that? I would be good to explain that.

We have not explored the non-documented ways. They might be possible. If they are, PRs are welcome to update the documentation.

We should update the page to reflect this. @sfshaza2 @mit-mit any suggestions for wording?

@chinmaygarde, do you have any insight into what we could say about this distinction?

There is no magic in the way symbol resolution works for Dart FFI. The symbols need to be resolved from a library using dlsym. dlsym needs a library handle. This handle is obtained by using dlopen with a specified path to a dynamic library. If symbol is already present in the current global scope, RTLD_DEFAULT can be used instead.

In Dart code, DynamicLibrary.open() is used to obtain the handle from a path and DyanmicLibrary.process() for the RTLD_DEFAULT handle.

The specific guidance for iOS and Android differs because of the way the applications are packaged.

On iOS, there is an executable that needs to be built already and it is generally easier to link static libraries into this executable. Once in the executable, DynamicLibrary.process() will work fine. However, there is nothing preventing the user from resolving the symbols from a dynamic library. I created a sample project that demonstrates this https://github.com/chinmaygarde/flutter_dylinkios_sample. Notice that in the Build Phases, I explicitly specified that the library be linked. This way, the symbols from that library are available in the global scope and I can use DynamicLibrary.process. But, I didn't need to do that. I could have skipped that step and loaded the library myself at runtime using DynamicLibrary.open() with the path returned by [NSBundle exectuablePath] for the framework bundle. It would have achieved the same thing. Using static libraries on iOS avoids having to remember to link the library and make sure to embed it in the final bundle, or, figure out some way of finding where the dynamic library exists at runtime. But, as demonstrated, it is supported and works fine.

Now, on Android, there no executable generated (the thing that contains the main entrypoint). So, we have to rely on dynamic libraries only on Android.

Hope this helps clarify things.

Wow, @chinmaygarde, thanks for that detailed answer!

Ah that makes sense. Although isn't Flutter AoT compiled now on Android? Does that not give a binary you can statically link into? I guess maybe it's just too much of a pain to do, and it wouldn't work with hot reload which would kind of suck.

Right, it would be limited to specific modes. Also, the default Flutter workflow for Android doesn't require a native toolchain. So everyone would have to download the NDK or some other toolchain and have that versioned and updated. The assumption is that if you are writing native code, you already have a build system and toolchain in place for it that can generate a dynamic library.