[Question] Is it possible to create a shared library/framework that works in both iOS and MacOs arm64?

[ceztko]

I was wondering if it could be theoretically possible for XCode to produce non-FAT binaries that works in both iOS/MacOS. Provided there's an ABI that works in both the operating systems and that the binaries only use hardware instructions/OS API(s) that are available in both CPU/OS(es), this would be feasible and would help reducing the matrix of builds to support. The question is if such cross-platform target actually exists and can be used in XCode toolchains hence ios-cmake.

[kambala-decapitator]

impossible afaik because libraries contain platform info which they were built against. Sample output from otool -l on a dylib:

Load command 9
      cmd LC_VERSION_MIN_IPHONEOS
  cmdsize 16
  version 9.0
      sdk 14.5

[kambala-decapitator]

also check this: https://bogo.wtf/arm64-to-sim-dylibs.html

[ceztko]

Ok, let's assume having cross iOS/macos binaries is not feasible. My point was trying to reduce compilation times by reducing the build matrix of a complex project that has many open source 3rd party dependencies (9 deps and still growing...). If I have to support both macos and iOS experience + simulators (no watch/tv OSes) this means, using @leetal architectures:

MAC (macox_x86_64)
MAC_ARM64 (macox_arm64)
OS64 (ios-arm64)
SIMULATOR64 (ios-simulator-x86_64)
SIMULATORARM64 (ios-simulator-arm64)

If I could create arm64 macos framework and hack them to work in the simulator, and the hack is easily scriptable, I could technically have one arch less to compile project+dependencies. If I could similarly hack a x86_64 macos framework to work in the simulator that would mean in total 2 architectures less to compile.

This is definitely out of project purpose but if @leetal has other suggestions as well that would be very appreciated. In the mean time I can verify if the hacks work.