Over the last 15 years, mobile platforms have become increasingly important parts of the computing landscape. iOS is one of two operating systems that control the vast majority of these devices. However, there is no official support for iOS in CPython.
is important for the future of Python as a language that it is able to be used on any hardware or OS that has widespread adoption. If Python cannot be used a on a platform that has widespread use, adoption of the language will be impacted as potential users will adopt other languages that do provide support for these platforms.
This is one of the main topics that I tend to re-iterate on multiple times during conference talks and generally while discussing Kivy and Python-based app lifecycle on mobile platforms.
Python on mobile platforms is definitely a thing, and can’t be ignored.
Adding iOS to Tier 3 support will certainly help to make python package maintainers aware of mobile platforms (and making package maintainers aware of mobile platforms is a key point in order to consider iOS “Really Supported”, cause as the PEP 730 describes, on iOS, some features are not available, and libraries need to better accommodate the dynamic-loading limitations of iOS. [pycryptodome here is a great example])
This imposes some constraints on the operation of CPython. It is not possible store binary modules in the lib-dynload and/or site-packages folders; they must be stored in the app’s Frameworks folder, with each module wrapped in a Framework. This also means that the common assumption that a Python module can construct the location of a binary module by using the file attribute of the Python module no longer holds.
I definitely agree with having an Umbrella Framework for each dynamically loadable library.
I thought of this solution multiple times but looked (unfortunately) “a way too big change” to fit into my
OSS (Kivy) schedule, as I have a limited amount of time budget. So it just has been kept on my wishlist.
We currently use another approach (static libraries, linked to the main executable [https://github.com/kivy/kivy-ios/blob/master/kivy_ios/recipes/python3/dynload_shlib.patch]), but sometimes this approach it’s not applicable (again, here pycryptodome is a great example) unless a lot of patching is done on the package side. (and it’s super-challenging to maintain on long term).
There may be some backwards compatibility implications on the projects that have historically provided CPython support (i.e., BeeWare and Kivy) if the final form of any CPython patches don’t align with the patches they have historically used.
I think my first PRs on Kivy project have been done on cross-compiling things, mostly on
kivy-ios repository, so, trust me, I can be quite emotive about the work that has been done.
But, even if that means keeping that code only in my memories, (and git commits), I will be happy to remove (and I think the whole team will be happy too) most of the wizardry and alchemy that keeps kivy-ios up and running (but flaky), in order to have a battle-tested and future-proof solution, raised and grown by the whole Python community.
And, I will be happy to support the whole process, with code, tests and migration guides for our users.
agree the need for a deprecated compiler setting is less than ideal. All I can go on is the reference in the Apple discussion that is linked in the PEP which suggests that Apple is at least somewhat sympathetic to the needs of Python as a language ecosystem.
That can be a huge issue, but yeah, discussing about it with Apple, may help, since lately (and that’s awesome) they are pretty welcoming with the open-source community. (And they are also actively contributing to multiple projects)
But, having a working parachute, is always a nice to have.
P.S: I had the opportunity to talk with someone (I don’t recall the nickname, but I can check on my emails) from the Python Core Dev team ~6 months ago about “Making cross-compilation easier for Python packages”, and we talked about the issues we had on Android and iOS, while cross-compiling Python packages, as he was interested in writing a PEP about it.
If adding iOS to Tier 3 support is the first step, the second one could be define a “suggested” way to cross-compile packages.