openfl
Static build of lime is coupled to specific hxcpp versions
We've had issues previously due to lime and hxcpp both using their own versions of mbedtls. In a static build, each symbol can only exist once, so previously lime's mbedtls would overwrite hxcpp's one and cause crashes at runtime due to version incompatibilities.
Since #1818, lime now links against hxcpp mbedtls. This is backwards and forwards compatible with many hxcpp versions, and it means that lime won't interfere with hxcpp's inner libraries. If there does happen to be an incompatibility, we now get a link time error instead of a crash at runtime.
This is already much better since most problems now show up as link time, however, it is still not ideal. The lime package is currently distributed with a static liblime build for ios. Since it is now built against mbedtls that is specific to a hxcpp version, a user may run into errors when attempting to build an ios project with a different hxcpp version. They are forced to rebuild lime to use it with an hxcpp version other than the one lime was built with.
Long term, it would be more flexible for hxcpp to allow using a custom build of mbedtls. This would allow liblime to remain forwards compatible with future hxcpp versions, so lime doesn't have to be rebuilt. However, this would mean updating the required hxcpp version that can be used by the distributed lime build (at least for ios builds)~~, and current hxcpp git no longer supports haxe 3~~ (EDIT: It still works with haxe 3.4.7). We can continue to allow building with older hxcpp as long as lime is rebuilt from source.
Long term, it would be more flexible for hxcpp to allow using a custom build of mbedtls.
This would require lime haxelib to be shipped with the mbedtls headers which is not ideal as it increases the size of the lime package.
On discord we discussed a better solution, which would be to build a dynamic lime ndll for ios, but place it in a framework to meet Apple's restrictions.
iOS, watchOS, and tvOS support third-party frameworks but don’t support third-party standalone dynamic libraries, which are those outside a framework bundle, typically with the .dylib filename extension.
https://developer.apple.com/documentation/bundleresources/placing-content-in-a-bundle#Place-content-based-on-type-and-platform
If someone needs a static build still, they will have to build lime from source (like is required for other targets now), which means the headers will be available anyway. It would still be good get hxcpp to link with a custom mbedtls for this purpose.