[klibertp]

In practice, this is hard. The problem is that you need to either have all the functionality you use written in Haxe - which is rarely if ever possible - or you have externs to equivalent libraries on all platforms. The libraries produced will also need to be interfaced from outside somehow, and for some of the targets you'll have to write additional wrappers for your lib. It's really hard to pull off when targeting more than 2-3 targets.

Another commenter linked to Ammer[1], a universal FFI framework (apparently, it's my first time seeing it) - it might be just the thing needed to make multiplatform Haxe libraries way easier to write and distribute. I'd welcome that :)

[1] https://aurel300.github.io/ammer/

[syntheweave]

Haxe's double-edged sword that it lets you approach cross-platform in an uncompromising fashion where you're really getting as close to the target as reasonably possible, while also abstracting away as much of it as possible, but it also directly exposes you to the high level of engineering effort necessary to achieve that.

A lot of what I encountered from my time using it(which I might return to someday) was that it became more irritating as you introduced more platform dependencies, but mostly because it became harder to build the project. And this was disproportionately true for targets with complex build processes(SWF was one of them back in the day, and C++ still is).

Some of it does get mitigated by doing a double layer of abstraction: your platform code has a shell of functionality that is handled using the native paradigms, but exposes an interface that Haxe code calls. And the Haxe code accesses your own abstractions, not the native ones.

But doing all of that can get away from "just getting a result", because then you're pushing more of the development onto the native target. If you don't have a clear view of what abstraction you want, you can get stuck on designing it.