Indy.Framework Universal for iOS

[MosCD3]

I tried every possible way to re-build the framework for universal deployment as in the docs but I fail, Buch of error in the script to the point that I am almost lost Is there a way to provide us with a build framework for universal deployment, that would save tons of time for developers who want to focus on Aries development

[WadeBarnes]

@TimoGlastra, @mirgee, @Patrik-Stas, @smccown, Any thoughts on this?

[TimoGlastra]

@blu3beri didn't you build the iOS framework last week?

[berendsliedrecht]

I did build libindy for iOS. However that is not a universal framework and I don't think that that is very smart as it increases bundle size massively.

Building a static library for any platform is something I can help with if that is what you need. However combining every architecture into a single library, I can not.

[MosCD3]

@blu3beri Thank you for your effort Even if it was not the smartest solution I know but it will be good for testing on simulators as far as development considered and no physical devices available.

The other possible solution (and elegant) is to build one for arm64 which is already build and we use and other for iphonesimulator (Not Universal) and I will combine them in XCFramework which will reduce size and pickup automatically depending on your final project build target

[berendsliedrecht]

That could work for the ios side (however Android is still split up). Dont forget to build x86_64 and arm64 for the iphonesimulator and comvine them with lipo.

[MosCD3]

Yess I am talking about iOS here, and the issue here is about me not able to build the framework. If I was able to build the framework I wouldn't open the ticket in the first place

[berendsliedrecht]

My apologies, I read your question wrong.

If you could add some information about what went wrong I might be able to help. A stacktrace, error message, steps you followed, etc. would be helpful.

[MosCD3]

@blu3beri I just created this ticket so that if any contributor has their machine configured and can build the archive and share it on the repo, that would save time. For me, I couldn't archive the bundle and you can refer to this issue I created if you can help me. Thanks in advance

2459

[Przytua]

@blu3beri have you been able to build it for m1 mac simulators? (arm64)

[berendsliedrecht]

@blu3beri have you been able to build it for m1 mac simulators? (arm64)

No, sadly not. It depends on an openssl dependency which does not work for simulators. I tried replacing it without success.

[Przytua]

Actually I managed to archive an xcframework of openssl with simulator and device frameworks. I'm having issues with the indy core. Building it with aarch64-apple-ios-sim target results in a non-simulator lib anyway, and when trying to build Indy wrapper for simulator I'm getting Building for ios simulator but the linked library was built for ios.

[berendsliedrecht]

Actually I managed to archive an xcframework of openssl with simulator and device frameworks. I'm having issues with the indy core. Building it with aarch64-apple-ios-sim target results in a non-simulator lib anyway, and when trying to build Indy wrapper for simulator I'm getting Building for ios simulator but the linked library was built for ios.

cargo build --release --target aarch64-apple-ios-sim

Gives an device, non-sim, build?

Could you confirm it with: lipo -info LIB.a

[Przytua]

lipo only gives Architectures in the fat file: libindy.a are: x86_64 arm64 or Non-fat file: libindy-arm64.a is architecture: arm64 when used on the thin binary. I checked with otool -fahl libindy-arm64.a | grep VERSION and it mixes both LC_VERSION_MIN_IPHONEOS and LC_BUILD_VERSION commands - which seems wrong. From what I read here: https://bogo.wtf/arm64-to-sim.html sim library should use LC_BUILD_VERSION, while LC_VERSION_MIN_IPHONEOS command is for device libraries.