Mobile wheels

[psychowasp]

This pull request introduces significant improvements for iOS platform support in the Kivy build system, primarily by integrating iOS framework handling with cibuildwheel and updating build scripts and logic to streamline cross-platform compilation. The changes automate iOS dependency installation, refactor framework detection and linking, and modernize platform-specific build flags. iOS builds now use the standard build pipeline rather than relying on the legacy kivy-ios environment.

iOS Build Integration and Framework Handling

• Added .ci/ios_frameworks.sh script to automate downloading and unpacking required iOS frameworks and dependencies, including SDL3 and ANGLE, for use in builds. (.ci/ios_frameworks.sh)
• Updated pyproject.toml to run the new iOS framework setup script before building with cibuildwheel, enabling automated framework preparation for iOS builds. (pyproject.toml)

Platform Detection and Build Logic Refactoring

• Refactored platform detection in setup.py to rely on cibuildwheel for iOS builds, removing legacy kivy-ios environment checks and adding logic to collect and organize iOS framework paths and headers. (setup.py) [1] [2]
• Updated build flag determination functions (determine_angle_flags, determine_gl_flags, determine_sdl3) to use the new framework organization and paths for iOS, ensuring correct linking and inclusion of headers for ANGLE, EGL, GLESv2, and SDL3 frameworks. (setup.py) [1] [2] [3]

Platform-Specific Compilation and Linking Flags

• Modernized iOS-specific build flags for core image, AVFoundation, and other subsystems to use the correct frameworks and headers, including new dependencies required for App Store support and improved compatibility with Xcode 16 and macOS 14.5+. (setup.py) [1] [2]

Mobile Platform Compatibility

• Improved sleep function handling in kivy/clock.py for mobile platforms by using time.sleep on Android and iOS, enhancing cross-platform reliability. (kivy/clock.py)

General Codebase Maintenance

• Minor cleanups and reordering of imports in setup.py to improve readability and maintainability. (setup.py)

These changes collectively make the iOS build process more robust, automated, and maintainable, aligning it with modern Python packaging and CI practices.

[welcome[bot]]

Thanks for opening your first pull request here! 💖 Please check out our contributing guidelines.

[psychowasp]

i added this ios_frameworks.sh to .ci which cibuildwheel will run before starting to build wheel and downloads SDL / Angle frameworks..

not sure howto deal with the paths in both .sh and setup.py when it comes to the dist/Frameworks..

@misl6 but let me know what you think so far, and what i need to change

how its been tested so far ios_setup_py.yml

[mhsmith]

@freakboy3742: FYI

[psychowasp]

i personal like the way beeware has the

• OpenSSL
• XZ
• libFFI
• Bzip

as seperate releases, and always easy to get same builds as the pythons.

same would be nice when working for stuff for kivy or kivy itself..

just get the sdl3/angle deps directly from kivy github (kivy-deps repo), which matches either master branch or a release.

[freakboy3742]

i personal like the way beeware has the

• OpenSSL
• XZ
• libFFI
• Bzip

as seperate releases, and always easy to get same builds as the pythons.

same would be nice when working for stuff for kivy or kivy itself..

FWIW: The aim is that those four in particular won't be BeeWare's responsibility for much longer - responsibility will be passed upstream to CPython. At the CPython core team sprint in September, there was some discussion about a unified approach to maintaining binary dependency assets. Nothing has come of that yet, but I believe "for the 3.15 release" was the broad timeframe being suggested.

[misl6]

i personal like the way beeware has the

• OpenSSL
• XZ
• libFFI
• Bzip

as seperate releases, and always easy to get same builds as the pythons.

same would be nice when working for stuff for kivy or kivy itself..

just get the sdl3/angle deps directly from kivy github (kivy-deps repo), which matches either master branch or a release.

For experience, maintaining separate releases for "non-standard" dependencies is quite painful and adds an additional burden to maintain, for which we do not have enough workforce. (See dependencies for Windows, which we discussed multiple times to be migrated here).

A separate release means:

• A separate repo (generic like kivy-sdk-packager is not always a good idea, and kivy-sdk-packager is a valid example)
• More CI/CD pipelines to mantain
• Un-necessary releases of the dependencies, that does not always fit into a release of the "real" product (See how many SDL3 releases we already made for Windows, with Kivy 3.x.x which is nowhere near to a release).

So, except to ANGLE, which is a different beast, we strongly encourage to keep the dependencies build internal. But yes, it can be changed in a later PR, but if you already have the build scripts, it would be nice to include it since day 0 :)

[psychowasp]

Well both ways got its pro and cons..

but if SDL3+rest have to be build each time you have to make a wheel release, then its also important they are bundled with it, so they are assets in the release or embeded into the kivy build..

What worked with kivy-ios toolchain, i dont think will work well with new pep730 standards.

In the end goal of pep730 is about moving away from having to explicit build for ios local. And have same benefits of wheel install like on example macos ..

And whatever building is required should happen in the cloud..

I just know for PSProject and Briefcase to run to current kivy ios wheels, we just need to pip install them, and download the same SDL3+Rest of frameworks as kivy was build with..

so for those 2 project makers, its important that ios wheel is present and if external frameworks is needed, they should be easy to fetch as prebuild frameworks from upstream, and is matching kivy build..

But sure is best to have it all ready from "0 day" but i think its a tricky one atm..

again just so we all clear about what will happen now xD

this PR will break kivy-ios and the recipe to build it..

i hat hoped the current kivy tests would hat made it more clear if any of my changes hat bricked other platforms.. but seems like i said ealier its only after builds the tests fails..

i also tried not to affect Android side, but in the end that should also be the next thing todo, implement Android Wheel.. and that properly also going to change how you need to think in terms of how p4a needs to work in the future..

Right now im just waiting for example meson-python to make release of current master, then Numpy + some others gets native ios wheel support out of the box..

so only reason we still would need recipes/building at all, is those few cases which still have to be fixed completely upstream..

[misl6]

Ok, so, I'm performing some tests, and I've been able to run a modified version of kivy-ios generated project with Python 3.14.2 (self-built) + your produced wheels.

It works, but the startup time is quite long. Is happening the same on your side?

FYI: Will work on pyobjus so we can have an official build that supports iOS + I will move the ios "package" code out of kivy-ios (that will cease to exists as-is).

For the binary dependencies (SDL3, ANGLE), I'm still thinking about a viable solution for us. How psproject and beeware make sure to select the right release for a specific Kivy release ATM?

[psychowasp]

I have tried explained it on discord now..

just ask there and we can always write a final summary here..