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

Russell Keith-Magee russell at keith-magee.com
Sat Oct 25 04:20:05 CEST 2014


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 %-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20141025/11ae777d/attachment.html>


More information about the Python-ideas mailing list