The fix for #835 is going to involve ffigen generating ObjC code for each block that the user needs. So there's not really any reason to try to avoid having ffigen generate native code anymore. It will be simpler and more efficient to just generate ObjC and Dart bindings for each interface that we want to implement from Dart, rather than having a generic thing like NSProxy that lives in package:objective_c.

The fix for #835 is going to involve ffigen generating ObjC code for each block that the user needs.

How would we solve the bundling of that ObjC code? Am I correct in assuming that if it's a Flutter plugin I presume we write cocoapods code to include it, and if we use native assets, we'd need to have a ObjectiveCCodeAsset as output from hook/build.dart?

Or can the Objective C just be compiled to a dylib and we can output it as a NativeCodeAsset @liamappelbe ?

I'm not sure what the difference is between ObjectiveCCodeAsset and NativeCodeAsset, but the code can be bundled as an ordinary dylib.

I'm not sure what the difference is between ObjectiveCCodeAsset and NativeCodeAsset, but the code can be bundled as an ordinary dylib.

👍 Then we don't need an ObjectiveCCodeAsset.