7.1.1.iOS version compatibility¶

The minimum supported iOS version is specified at compile time, using the--host option toconfigure. By default, when compiled for iOS,Python will be compiled with a minimum supported iOS version of 13.0. To use adifferent 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 buildwith a deployment target of 15.4.

7.1.2.Platform identification¶

When executing on iOS,sys.platform will report asios. This value willbe returned on an iPhone or iPad, regardless of whether the app is running onthe 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 usingplatform.ios_ver().platform.system() will reportiOS oriPadOS, depending on the device.

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

7.1.3.Standard library availability¶

The Python standard library has some notable omissions and restrictions oniOS. See theAPI availability guide for iOS fordetails.

7.1.4.Binary extension modules¶

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

The iOS App Store requires thatall binary modules in an iOS app must bedynamic libraries, contained in a framework with appropriate metadata, storedin theFrameworks folder of the packaged app. There can be only a singlebinary per framework, and there can be no executable binary material outsidetheFrameworks folder.

This conflicts with the usual Python approach for distributing binaries, whichallows a binary extension module to be loaded from any location onsys.path. To ensure compliance with App Store policies, an iOS project mustpost-process any Python packages, converting.so binary modules intoindividual standalone frameworks with appropriate metadata and signing. Fordetails on how to perform this post-processing, see the guide foraddingPython to your project.

To help Python discover binaries in their new location, the original.sofile onsys.path is replaced with a.fwork file. This file is a textfile containing the location of the framework binary, relative to the appbundle. To allow the framework to resolve back to the original location, theframework 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 importfromfoo.barimport_whiz,where_whiz is implemented with the binary modulesources/foo/bar/_whiz.abi3.so, withsources being the locationregistered onsys.path, relative to the application bundle. This modulemust be distributed asFrameworks/foo.bar._whiz.framework/foo.bar._whiz(creating the framework name from the full import path of the module), with anInfo.plist file in the.framework directory identifying the binary as aframework. Thefoo.bar._whiz module would be represented in the originallocation with asources/foo/bar/_whiz.abi3.fwork marker file, containingthe pathFrameworks/foo.bar._whiz/foo.bar._whiz. The framework would alsocontainFrameworks/foo.bar._whiz.framework/foo.bar._whiz.origin, containingthe path to the.fwork file.

When running on iOS, the Python interpreter will install anAppleFrameworkLoader that is able to read andimport.fwork files. Once imported, the__file__ attribute of thebinary module will report as the location of the.fwork file. However, theModuleSpec for the loaded module will report theorigin 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 anxcrunscript that resolves to a full compiler path (e.g.,xcrun--sdkiphoneosclang to get theclang for an iPhone device). However, using this scriptposes two problems:

• The output ofxcrun includes paths that are machine specific, resultingin a sysconfig module that cannot be shared between users; and

• It results inCC/CPP/LD/AR definitions that include spaces.There is a lot of C ecosystem tooling that assumes that you can split acommand line at the first space to get the path to the compiler executable;this isn't the case when usingxcrun.

To avoid these problems, Python provided stubs for these tools. These stubs areshell script wrappers around the underinglyxcrun tools, distributed in abin folder distributed alongside the compiled iOS framework. These scriptsare relocatable, and will always resolve to the appropriate local system paths.By including these scripts in the bin folder that accompanies a framework, thecontents of thesysconfig module becomes useful for end-users to compiletheir own modules. When compiling third-party Python modules for iOS, youshould ensure these stub binaries are on your path.

7.2.1.Tools for building iOS apps¶

Building for iOS requires the use of Apple's Xcode tooling. It is stronglyrecommended that you use the most recent stable release of Xcode. This willrequire the use of the most (or second-most) recently released macOS version,as Apple does not maintain Xcode for older macOS versions. The Xcode CommandLine Tools are not sufficient for iOS development; you need afull Xcodeinstall.

If you want to run your code on the iOS simulator, you'll also need to installan iOS Simulator Platform. You should be prompted to select an iOS SimulatorPlatform when you first run Xcode. Alternatively, you can add an iOS SimulatorPlatform 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. Thefollowing examples will use Objective C; if you are using Swift, you may find alibrary likePythonKit to behelpful.

To add Python to an iOS Xcode project:

1. Build or obtain a PythonXCFramework. See the instructions iniOS/README.rst (in the CPython source distribution) for details onhow to build a PythonXCFramework. At a minimum, you will need a buildthat supportsarm64-apple-ios, plus one of eitherarm64-apple-ios-simulator orx86_64-apple-ios-simulator.

2. Drag theXCframework into your iOS project. In the followinginstructions, we'll assume you've dropped theXCframework into the rootof your project; however, you can use any other location that you want byadjusting paths as needed.

3. Drag theiOS/Resources/dylib-Info-template.plist file into your project,and ensure it is associated with the app target.

4. Add your application code as a folder in your Xcode project. In thefollowing instructions, we'll assume that your user code is in a foldernamedapp in the root of your project; you can use any other location byadjusting paths as needed. Ensure that this folder is associated with yourapp target.

5. Select the app target by selecting the root node of your Xcode project, thenthe target name in the sidebar that appears.

6. In the "General" settings, under "Frameworks, Libraries and EmbeddedContent", addPython.xcframework, with "Embed & Sign" selected.

7. In the "Build Settings" tab, modify the following:

   • 建置選項

     • 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

8. Add a build step that copies the Python standard library into your app. Inthe "Build Phases" tab, add a new "Run Script" build stepbefore the"Embed Frameworks" step, butafter the "Copy Bundle Resources" step. Namethe step "Install Target Specific Python Standard Library", disable the"Based on dependency analysis" checkbox, and set the script content to:

   set-emkdir-p"$CODESIGNING_FOLDER_PATH/python/lib"if["$EFFECTIVE_PLATFORM_NAME"="-iphonesimulator"];thenecho"Installing Python modules for iOS Simulator"rsync-au--delete"$PROJECT_DIR/Python.xcframework/ios-arm64_x86_64-simulator/lib/""$CODESIGNING_FOLDER_PATH/python/lib/"elseecho"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 bedifferent, depending the CPU architectures yourXCFramework supports.

9. Add a second build step that processes the binary extension modules in thestandard library into "Framework" format. Add a "Run Script" build stepdirectly after the one you added in step 8, named "Prepare Python BinaryModules". It should also have "Based on dependency analysis" unchecked, withthe following script content:

   set-einstall_dylib(){INSTALL_BASE=$1FULL_EXT=$2# The name of the extension fileEXT=$(basename"$FULL_EXT")# The location of the extension file, relative to the bundleRELATIVE_EXT=${FULL_EXT#$CODESIGNING_FOLDER_PATH/}# The path to the extension file, relative to the install basePYTHON_EXT=${RELATIVE_EXT/$INSTALL_BASE/}# The full dotted name of the extension module, constructed from the file path.FULL_MODULE_NAME=$(echo$PYTHON_EXT|cut-d"."-f1|tr"/"".");# A bundle identifier; not actually used, but required by Xcode framework packagingFRAMEWORK_BUNDLE_ID=$(echo$PRODUCT_BUNDLE_IDENTIFIER.$FULL_MODULE_NAME|tr"_""-")# The name of the framework folder.FRAMEWORK_FOLDER="Frameworks/$FULL_MODULE_NAME.framework"# If the framework folder doesn't exist, create it.if[!-d"$CODESIGNING_FOLDER_PATH/$FRAMEWORK_FOLDER"];thenecho"Creating framework for$RELATIVE_EXT"mkdir-p"$CODESIGNING_FOLDER_PATH/$FRAMEWORK_FOLDER"cp"$CODESIGNING_FOLDER_PATH/dylib-Info-template.plist""$CODESIGNING_FOLDER_PATH/$FRAMEWORK_FOLDER/Info.plist"plutil-replaceCFBundleExecutable-string"$FULL_MODULE_NAME""$CODESIGNING_FOLDER_PATH/$FRAMEWORK_FOLDER/Info.plist"plutil-replaceCFBundleIdentifier-string"$FRAMEWORK_BUNDLE_ID""$CODESIGNING_FOLDER_PATH/$FRAMEWORK_FOLDER/Info.plist"fiecho"Installing binary for$FRAMEWORK_FOLDER/$FULL_MODULE_NAME"mv"$FULL_EXT""$CODESIGNING_FOLDER_PATH/$FRAMEWORK_FOLDER/$FULL_MODULE_NAME"# Create a placeholder .fwork file where the .so wasecho"$FRAMEWORK_FOLDER/$FULL_MODULE_NAME">${FULL_EXT%.so}.fwork# Create a back reference to the .so file location in the frameworkecho"${RELATIVE_EXT%.so}.fwork">"$CODESIGNING_FOLDER_PATH/$FRAMEWORK_FOLDER/$FULL_MODULE_NAME.origin"}PYTHON_VER=$(ls-1"$CODESIGNING_FOLDER_PATH/python/lib")echo"Install Python$PYTHON_VER standard library extension modules..."find"$CODESIGNING_FOLDER_PATH/python/lib/$PYTHON_VER/lib-dynload"-name"*.so"|whilereadFULL_EXT;doinstall_dylibpython/lib/$PYTHON_VER/lib-dynload/"$FULL_EXT"done# Clean up dylib templaterm-f"$CODESIGNING_FOLDER_PATH/dylib-Info-template.plist"echo"Signing frameworks as$EXPANDED_CODE_SIGN_IDENTITY_NAME ($EXPANDED_CODE_SIGN_IDENTITY)..."find"$CODESIGNING_FOLDER_PATH/Frameworks"-name"*.framework"-exec/usr/bin/codesign--force--sign"$EXPANDED_CODE_SIGN_IDENTITY"${OTHER_CODE_SIGN_FLAGS:-}-oruntime--timestamp=none--preserve-metadata=identifier,entitlements,flags--generate-entitlement-der"{}"\;

10. Add Objective C code to initialize and use a Python interpreter in embeddedmode. You should ensure that:

• UTF-8 mode (PyPreConfig.utf8_mode) isenabled;

• Buffered stdio (PyConfig.buffered_stdio) isdisabled;

• Writing bytecode (PyConfig.write_bytecode) isdisabled;

• Signal handlers (PyConfig.install_signal_handlers) areenabled;

• PYTHONHOME for the interpreter is configured to point at thepython subfolder of your app's bundle; and

• ThePYTHONPATH for the interpreter includes:

  • thepython/lib/python3.X subfolder of your app's bundle,

  • thepython/lib/python3.X/lib-dynload subfolder of your app's bundle, and

  • theapp subfolder of your app's bundle

Your app's bundle location can be determined using[[NSBundlemainBundle]resourcePath].

Steps 8, 9 and 10 of these instructions assume that you have a single folder ofpure Python application code, namedapp. If you have third-party binarymodules in your app, some additional steps will be required:

• You need to ensure that any folders containing third-party binaries areeither associated with the app target, or copied in as part of step 8. Step 8should also purge any binaries that are not appropriate for the platform aspecific build is targeting (i.e., delete any device binaries if you'rebuilding an app targeting the simulator).

• Any folders that contain third-party binaries must be processed intoframework form by step 9. The invocation ofinstall_dylib that processesthelib-dynload folder can be copied and adapted for this purpose.

• If you're using a separate folder for third-party packages, ensure that folderis included as part of thePYTHONPATH configuration in step 10.

7.2.3.Testing a Python package¶

The CPython source tree containsa testbed project thatis used to run the CPython test suite on the iOS simulator. This testbed can alsobe used as a testbed project for running your Python library's test suite on iOS.

After building or obtaining an iOS XCFramework (SeeiOS/README.rstfor details), create a clone of the Python iOS testbed project by running:

$pythoniOS/testbedclone--framework<path/to/Python.xcframework>--app<path/to/module1>--app<path/to/module2>app-testbed

You will need to modify theiOS/testbed reference to point to thatdirectory in the CPython source tree; any folders specified with the--appflag will be copied into the cloned testbed project. The resulting testbed willbe created in theapp-testbed folder. In this example, themodule1 andmodule2 would be importable modules at runtime. If your project hasadditional dependencies, they can be installed into theapp-testbed/iOSTestbed/app_packages folder (usingpipinstall--targetapp-testbed/iOSTestbed/app_packages or similar).

You can then use theapp-testbed folder to run the test suite for your app,For example, ifmodule1.tests was the entry point to your test suite, youcould run:

$pythonapp-testbedrun--module1.tests

This is the equivalent of runningpython-mmodule1.tests on a desktopPython build. Any arguments after the-- will be passed to the testbed asif they were arguments topython-m on a desktop machine.

You can also open the testbed project in Xcode by running:

$openapp-testbed/iOSTestbed.xcodeproj

This will allow you to use the full Xcode suite of tools for debugging.