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

[Russell Keith-Magee]

On Sun, Oct 26, 2014 at 4:58 AM, Andrew Barnert <abarnert at yahoo.com> wrote:

> 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.
>

To clarify - this isn't a theoretical thing - I've got a Python 2.7 static
library running on non-jailbroken iOS and Android devices, and I've
published the tools (and builds) to let others do the same:

https://github.com/pybee/Python-iOS-support
https://github.com/pybee/Python-Android-support

And I've published cookiecutter templates for iOS and Android projects if
you want to write your apps in Python:

https://github.com/pybee/Python-iOS-template
https://github.com/pybee/Python-Android-template

The support libraries are mostly patches and build system tweaks, and at
present, they're all for stale versions of Python 2.7. I'm on Python-ideas
because I want to move as much as possible back upstream into Python's
sources.


> > 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.
>

That's a good point; I'll investigate what can be done using other fields
in platform and sys.

>  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 looked at PyObjC; I was unsatisfied with the performance, and it has a
native compiled component. I ended up writing my own ObjC bindings, based
off an initial collection of code from Pyglet:

https://github.com/pybee/rubicon-objc

This uses ctypes, so there's no compiled component.

> 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.
>

Yes, but AFAICT, this is done by leveraging the ability of clang to compile
a binary that supports multiple architectures at once.. The iOS toolchain
doesn't do that (AFAICT) - you need to build separately and lipo the
products together. OSX only needs a single compiler pass; iOS needs
multiple passes.

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?


I'll take a closer look at PyObjC's build process and see what I can work
out.

Yours,
Russ Magee %-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20141026/3a80e6e5/attachment.html>