Consuming the generated code directly like this can be tricky – the canonical way to do it is to expose certain classes with @:nativeGen and link against the binary output (add -D dll_link or -D static_link to your hxml generate a binary lib instead of an exe). See the extern-lib and extern-use examples here: hxcpp/test at master · HaxeFoundation/hxcpp · GitHub
When interacting with haxe you have to consider two things: haxe’s garbage collector and haxe’s event loop: When calling into haxe code you first need to initialize haxe’s internal structures with hx::Init() and then need to ‘attach’ the garbage collecting context which you can do with RAII and hx::NativeAttach autoAttach;. If you want things like haxe.Timer to work and haxe multi-threading you must spin the event loop (which I don’t have an example for)
I’ve created a library to handle all this: GitHub - haxiomic/haxe-c-bridge: Easily interact with haxe classes from C with an automatically generated C header
You just add @:build(HaxeCBridge.expose()) to classes you want to be accessible and it generates a dependency-free single C header with all exposed functions alongside the binary output. It makes sure the GC doesn’t kill objects passed outside of haxe-land and haxe code is executed in a separate thread which spins its own event loop, so timers, GC and multithreading will all work. The haxe-thread is synchronized when calling haxe code so you can safely call exposed haxe functions from any thread.
Works with Swift bridging headers so you can interact with your haxe library from Swift when building iOS and mac apps
To compile haxe-code for iPhone/iPad ARM CPUs, you can add this to your hxml
-D iphoneos
-D HXCPP_ARM64
Or
-D simulator
-D HXCPP_M64
for simulator binaries for desktop use
You may also need to set the iPhone SDK:
# leaving SDK empty should map to the default
# if you have errors about missing SDK then explicitly set the SDK version on your system (e.g. -D IPHONE_VER=12.2)
-D IPHONE_VER=
List of hxml flags for compiling to different platforms: