7. Using Python on iOS ¶

作者 :: Russell Keith-Magee (2024-03)

Python on iOS is unlike Python on desktop platforms. On a desktop platform, Python is generally installed as a system resource that can be used by any user of that computer. Users then interact with Python by running a python executable and entering commands at an interactive prompt, or by running a Python script.

On iOS, there is no concept of installing as a system resource. The only unit of software distribution is an “app”. There is also no console where you could run a python executable, or interact with a Python REPL.

As a result, the only way you can use Python on iOS is in embedded mode - that is, by writing a native iOS application, and embedding a Python interpreter using libPython , and invoking Python code using the Python embedding API . The full Python interpreter, the standard library, and all your Python code is then packaged as a standalone bundle that can be distributed via the iOS App Store.

If you’re looking to experiment for the first time with writing an iOS app in Python, projects such as BeeWare and Kivy will provide a much more approachable user experience. These projects manage the complexities associated with getting an iOS project running, so you only need to deal with the Python code itself.

7.1. Python at runtime on iOS ¶

7.1.1. iOS version compatibility ¶

The minimum supported iOS version is specified at compile time, using the --host 选项到 configure . By default, when compiled for iOS, Python will be compiled with a minimum supported iOS version of 13.0. To use a different minimum iOS version, provide the version number as part of the --host argument - for example, --host=arm64-apple-ios15.4-simulator would compile an ARM64 simulator build with a deployment target of 15.4.

7.1.2. Platform identification ¶

When executing on iOS, sys.platform will report as ios . This value will be returned on an iPhone or iPad, regardless of whether the app is running on the simulator or a physical device.

Information about the specific runtime environment, including the iOS version, device model, and whether the device is a simulator, can be obtained using platform.ios_ver() . platform.system() will report iOS or iPadOS , depending on the device.

os.uname() reports kernel-level details; it will report a name of Darwin .

7.1.3. Standard library availability ¶

The Python standard library has some notable omissions and restrictions on iOS. See the API availability guide for iOS 了解细节。

7.1.4. Binary extension modules ¶

One notable difference about iOS as a platform is that App Store distribution imposes hard requirements on the packaging of an application. One of these requirements governs how binary extension modules are distributed.

The iOS App Store requires that all binary modules in an iOS app must be dynamic libraries, contained in a framework with appropriate metadata, stored in the Frameworks folder of the packaged app. There can be only a single binary per framework, and there can be no executable binary material outside the Frameworks folder.

This conflicts with the usual Python approach for distributing binaries, which allows a binary extension module to be loaded from any location on sys.path . To ensure compliance with App Store policies, an iOS project must post-process any Python packages, converting .so binary modules into individual standalone frameworks with appropriate metadata and signing. For details on how to perform this post-processing, see the guide for adding Python to your project .

To help Python discover binaries in their new location, the original .so file on sys.path is replaced with a .fwork file. This file is a text file containing the location of the framework binary, relative to the app bundle. To allow the framework to resolve back to the original location, the framework must contain a .origin file that contains the location of the .fwork file, relative to the app bundle.

For example, consider the case of an import from foo.bar import _whiz ，其中 _whiz is implemented with the binary module sources/foo/bar/_whiz.abi3.so ，采用 sources being the location registered on sys.path , relative to the application bundle. This module must be distributed as Frameworks/foo.bar._whiz.framework/foo.bar._whiz (creating the framework name from the full import path of the module), with an Info.plist file in the .framework directory identifying the binary as a framework. The foo.bar._whiz module would be represented in the original location with a sources/foo/bar/_whiz.abi3.fwork marker file, containing the path Frameworks/foo.bar._whiz/foo.bar._whiz . The framework would also contain Frameworks/foo.bar._whiz.framework/foo.bar._whiz.origin , containing the path to the .fwork 文件。

When running on iOS, the Python interpreter will install an AppleFrameworkLoader that is able to read and import .fwork files. Once imported, the __file__ attribute of the binary module will report as the location of the .fwork file. However, the ModuleSpec for the loaded module will report the origin as the location of the binary in the framework folder.

7.1.5. Compiler stub binaries ¶

Xcode doesn’t expose explicit compilers for iOS; instead, it uses an xcrun script that resolves to a full compiler path (e.g., xcrun --sdk iphoneos clang 以获取 clang for an iPhone device). However, using this script poses two problems:

The output of xcrun includes paths that are machine specific, resulting in a sysconfig module that cannot be shared between users; and
It results in CC / CPP / LD / AR definitions that include spaces. There is a lot of C ecosystem tooling that assumes that you can split a command line at the first space to get the path to the compiler executable; this isn’t the case when using xcrun .

To avoid these problems, Python provided stubs for these tools. These stubs are shell script wrappers around the underingly xcrun tools, distributed in a bin folder distributed alongside the compiled iOS framework. These scripts are relocatable, and will always resolve to the appropriate local system paths. By including these scripts in the bin folder that accompanies a framework, the contents of the sysconfig module becomes useful for end-users to compile their own modules. When compiling third-party Python modules for iOS, you should ensure these stub binaries are on your path.

7.2. Installing Python on iOS ¶

7.2.1. Tools for building iOS apps ¶

Building for iOS requires the use of Apple’s Xcode tooling. It is strongly recommended that you use the most recent stable release of Xcode. This will require the use of the most (or second-most) recently released macOS version, as Apple does not maintain Xcode for older macOS versions. The Xcode Command Line Tools are not sufficient for iOS development; you need a full Xcode install.

If you want to run your code on the iOS simulator, you’ll also need to install an iOS Simulator Platform. You should be prompted to select an iOS Simulator Platform when you first run Xcode. Alternatively, you can add an iOS Simulator Platform by selecting from the Platforms tab of the Xcode Settings panel.

7.2.2. Adding Python to an iOS project ¶

Python can be added to any iOS project, using either Swift or Objective C. The following examples will use Objective C; if you are using Swift, you may find a library like PythonKit to be helpful.

To add Python to an iOS Xcode project:

Build or obtain a Python XCFramework . See the instructions in iOS/README.rst (in the CPython source distribution) for details on how to build a Python XCFramework . At a minimum, you will need a build that supports arm64-apple-ios , plus one of either arm64-apple-ios-simulator or x86_64-apple-ios-simulator .
Drag the XCframework into your iOS project. In the following instructions, we’ll assume you’ve dropped the XCframework into the root of your project; however, you can use any other location that you want by adjusting paths as needed.
Drag the iOS/Resources/dylib-Info-template.plist file into your project, and ensure it is associated with the app target.
Add your application code as a folder in your Xcode project. In the following instructions, we’ll assume that your user code is in a folder named app in the root of your project; you can use any other location by adjusting paths as needed. Ensure that this folder is associated with your app target.
Select the app target by selecting the root node of your Xcode project, then the target name in the sidebar that appears.
In the “General” settings, under “Frameworks, Libraries and Embedded Content”, add Python.xcframework , with “Embed & Sign” selected.
In the “Build Settings” tab, modify the following:
- Build Options
  - User Script Sandboxing: No
  - Enable Testability: Yes
- Search Paths
  - Framework Search Paths: $(PROJECT_DIR)
  - Header Search Paths: "$(BUILT_PRODUCTS_DIR)/Python.framework/Headers"
- Apple Clang - Warnings - All languages
  - Quoted Include In Framework Header: No

Add a build step that copies the Python standard library into your app. In the “Build Phases” tab, add a new “Run Script” build step before the “Embed Frameworks” step, but after the “Copy Bundle Resources” step. Name the step “Install Target Specific Python Standard Library”, disable the “Based on dependency analysis” checkbox, and set the script content to:

set -e
mkdir -p "$CODESIGNING_FOLDER_PATH/python/lib"
if [ "$EFFECTIVE_PLATFORM_NAME" = "-iphonesimulator" ]; then
    echo "Installing Python modules for iOS Simulator"
    rsync -au --delete "$PROJECT_DIR/Python.xcframework/ios-arm64_x86_64-simulator/lib/" "$CODESIGNING_FOLDER_PATH/python/lib/"
else
    echo "Installing Python modules for iOS Device"
    rsync -au --delete "$PROJECT_DIR/Python.xcframework/ios-arm64/lib/" "$CODESIGNING_FOLDER_PATH/python/lib/"
fi

Note that the name of the simulator “slice” in the XCframework may be different, depending the CPU architectures your


XCFramework

支持。