[Python-ideas] Adding iOS/Android support to Python

[Andrew Barnert]

On Oct 24, 2014, at 19:20, Russell Keith-Magee <russell at keith-magee.com> wrote:

> I'd like to start supporting more recent versions of Python - most importantly, Python 3. While I could certainly continue maintaining patches externally (and I imagine I'll have to if I want to maintain Python 2.7 support), I'd like to see that effort integrated into Python's repository.

People have already been making Python 3 builds for iOS, wrapping them in mini-IDEs, and selling them on the App Store for quite some time. Have you talked to Xiaowen Huang or any of the others?

As far as I know, most of them build Python as a static lib, and link in the C extensions from the stdlib, to get around the issues with shared-lib frameworks before iOS 8. And I'm not sure how they deal with third-party modules (at least one of them includes numpy, for example).

You also may want to talk to whoever maintains the ports for jailbroken iOS, because that's just a standard-as-possible build, with the command line interpreter and pip and everything.

> In particular, there are four areas where I can see changes required:
> 
>  1) At least 2 new sys.platform definitions - "ios" and "android" (a third "iossimulator" platform might also be needed - the iOS simulator has enough differences that it can be helpful to be able to identify the platform) 

There are other fields in platform and sys that can be used to distinguish iOS from the simulator. And, since you need to check iOS simulator or real iOS vs. everything else at least as often as you need to distinguish them from each other, I'm not sure it's important whether it's treated as a separate platform or a different version of the same platform--as long as there's some documented and guaranteed way to distinguish them.

>  3) Disabling certain modules on mobile platforms. Supporting modules like linuxaudiodev, ossaudiodev, readline, curses, idle and tkinter on mobile platforms doesn't make much sense; modules likes bsddb and bz2 are difficult to support due to library dependencies; and the need for modules like multiprocessing is arguable (and difficult to support on mobile). Even providing a Python executable/shell is arguable for these platforms.

How is multiprocessing difficult to provide on mobile? iOS has had fork, posix_spawn, semaphores, etc. since the first release with an SDK, although you'd get rejected from the App Store for using them in the early days. Of course Apple would prefer people to use XPC via grand central, but that doesn't mean you need to make it impossible to use fork instead; at most, you just need to warn people to read the App Store guidelines.

In the opposite direction, it might be worth looking at the "extra batteries" in Apple's OS X builds. At least PyObjC seems like something you'd want to get working on iOS.

> I have no idea how to tackle 4. To create a complete iOS build, you have to do at least 4 complete Python builds - a native system build (so you can run Python scripts that are part of the build), an i386 build (for the simulator), an armv7 build, and an arm64 build - and then the build products of the last three need to be combined into a single framework directory. 
> 
> Given three independent platform-specific build directories, it's relatively easy to construct a "fat" framework, but it isn't clear to me how that would fit into Python's build system. I can see that the build system has support for "universal" builds, which looks like an artefact of the OS X PPC->i386 conversion, but the build approach appears to be different to that required for iOS.

It's still perfectly possible to build Python universal on OS X. In fact, both the python.org builds and Apple's pre-installed builds are fat i386/x86_64.

iOS does put some limitations on things, especially when building shared libs, but if you need to fall back to building each target separately and lipo'ing them together manually, I'm pretty sure there are a few third-party libs that already use that workaround. Didn't PyObjC used to build that way?