Support ARM64 Simulator + Introduce build platform concept + Introduce `xcframework`

[misl6]

WIP. DO NOT MERGE

Historically kivy-ios used the CPU arch name in order to distinguish if the build was intended for the Simulator (x86_64) or the "real" device (armv7 and now arm64).

With Apple Silicon macs, Apple introduced the arm64 iOS Simulator, so the CPU arch name is not enough to distinguish iOS Simulator builds or iOS ones.

So, now, via this PR, instead of targeting x86_64 and arm64, the user can now specify which platform+CPU arch combination wants to build (Or can just use the default ones: iphoneos-arm64 + iphonesimulator-x86_64 on Intel macs, iphoneos-arm64 + iphonesimulator-arm64 on Apple Silicon macs)

With this change, we can potentially (and quite easily) also support tvOS, and we are "future-proof".

Additionally, since 2 libraries with the same CPU arch can't be lipo-ized, now we create a "lipo" library for each platform (iphoneos, iphonesimulator) and then the 2 lipo-ized libraries are added into a xcframework artifact. (https://developer.apple.com/documentation/xcode/creating-a-multi-platform-binary-framework-bundle)

I've tested a minimal python3 + kivy setup and worked like a charm. But needs a lot of testing + we will likely find some broken (unrelated to this change) recipes.

Closes https://github.com/kivy/kivy-ios/issues/751

[dlewandaDK]

Hi @misl6, I see you released some other kivy-ios improvements upstream on master from where this branch, will you be rebasing the arm64 simulator work on top of that? We are getting close to getting this working on our side, but would like to get ahead of any known upcoming changes. Also, any idea what the timeline or requirements would be for getting this functionality merged and officially released?

[misl6]

Hi @dlewandaDK !

I had the chance to test this feature widely, even in production, and seems we're near to the merge.

I've scheduled a new kivy-ios release, which will happen before the end of the next week, and this release will be the last one to build fat libs instead of xcframeworks.

So, the (rebase and) merge of this feature is scheduled to happen just after the next release.

[dlewandaDK]

I had the chance to test this feature widely, even in production, and seems we're near to the merge.

I've scheduled a new kivy-ios release, which will happen before the end of the next week, and this release will be the last one to build fat libs instead of xcframeworks.

So, the (rebase and) merge of this feature is scheduled to happen just after the next release.

Hi @misl6 it is great to hear that you're moving forward with this approach, and even better that you're moving to xcframeworks as we have been doing that ourselves so taking one more step out of the equation will be great.

That said, the original team members on our side who got Kivy-iOS working with our project left before I joined, and we have been unable to recreate what they've done previously with this new version. In our case, we are just looking to compile some mathematical calculation code written in Python into libraries we can link against and call from our new app (written entirely in Swift), not write a whole app in Python. We will await the merge and release of this fix and then try again. If you know of any support forums or discussions where we can reach out with questions specifically around generating standalone libraries based on Python without the whole app, we'd appreciate any suggestions.

[dlewandaDK]

Hi @misl6, just checking in to see if you have an updated timeline for releasing these changes. I haven't seen a new release since May, so I presume there's still one more to come before this one lands, correct?

[misl6]

Hi @misl6, just checking in to see if you have an updated timeline for releasing these changes. I haven't seen a new release since May, so I presume there's still one more to come before this one lands, correct?

Hi @dlewandaDK ! Sorry for the late reply, but I took a 3 week digital detox 😀 I just performed a release for kivy-ios, the last one which will not use the .xcframework, and rebased everything on top of it.

If the CI is happy with it, I will merge this PR into master, so we can continue the development and recipe migrations (if needed).

[misl6]

Thank you @AndreMiras ❤️

[tcaduser]

@AndreMiras , do you need me to prepare a PR to fix cpplink, kiwisolver, and matplotlib for this new change?

[misl6]

@AndreMiras , do you need me to prepare a PR to fix cpplink, kiwisolver, and matplotlib for this new change?

Ouch! I did not notice that a new recipe has been added! If you want to, yes. Feel free to ask if you need some help 😀

(I'm authoring a "Migrate from .a to .xcframework ATM)

[tcaduser]

Hi @misl6

I have some time to look at it today. Has there been any change to how I would need to invoke the toolchain commands?

[tcaduser]

meaning, additional command line to the toolchain command, or will it just build all of the variants?

[misl6]

meaning, additional command line to the toolchain command, or will it just build all of the variants?

toolchain build yourdep automatically builds yourdep for the default platforms.

Default platforms differ if you're on a Intel mac or Apple Silicon mac.

• Intel: iphoneos-arm64 + iphonesimulator-x86_64
• Apple silicon: iphoneos-arm64 + iphonesimulator-arm64

If you want to, you can specify every single platform you want to build via --platform, but feel free to only build the default platforms, as then CI tests are performed on both Intel and Apple Silicon macs.