Hi all,

tl;dr - I'd like to add iOS and Android to the list of platforms that Python supports out-of-the-box, and I'm looking for guidance on the way forward (and assistance, if anyone is keen).

Longer version: For the last 9 months or so, I've been working on tools to enable developers to write native mobile apps using Python. My motivation is to get Toga (http://pybee.org/toga) to the point where it's a viable way to write mobile apps. However, I'm not alone in the "Python on mobile" goal - Kivy has been around for a few years, with similar goals (although they've got some different ideas and priorities).

To date, I've been using the groundwork established by Kivy, which takes the Python 2.7.1 (for iOS) and Python 2.7.2 (for Android) source code, applies a bunch of patches, and wraps those in a set of build scripts to yield Python libraries that can be used on iOS and Android.

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.

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) 

 2) Modifications to the build system to support cross-platform builds for mobile - AFAICT, cross platform builds currently only work on Linux and require readelf; iOS libraries can only be built on Mac, and building Android libraries don't require readelf (AFAICT).

 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.

 4) Support for building fat libraries for iOS. Xcode uses a tool called lipo to mash multiple platform libraries into a single library file. 

I don't imagine 1 & 2 are especially controversial.

However, I would anticipate that 3 might raise some concerns, as the general Python "batteries included" philosophy would be modified to "unless you're on one of these platforms". Any guidance on whether this approach would be palatable? Is there any precedent for "module not supported on platform X" that I'm not aware of? Any platforms where Python is *only* available as a library?

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.

Is there any documentation of the build process itself? Or is there anyone who can point me in the right direction?

I'm also not clear how to tackle the testing and CI problems. Since you can't run iOS code on a non-iOS machine, it isn't entirely clear to me what an acceptance test would look like for a mobile build.

So - am I completely wasting my time? Are patches for mobile platforms likely to be accepted into Python's repository? Or should I stick with the "external patches" approach? Any pointers, hints, guidance or assistance would be gratefully accepted. 

Yours,

Russ Magee %-)