<p>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 <strongclass="program">python</strong>
executable and entering commands at an interactive prompt, or by running a
Python script.</p>
<p>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 <strongclass="program">python</strong> executable, or interact with a Python REPL.</p>
<p>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 <codeclass="docutils literal notranslate"><spanclass="pre">libPython</span></code>, and invoking Python code using the <aclass="reference internal" href="../extending/embedding.html#embedding"><spanclass="std std-ref">Python embedding
API</span></a>. 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.</p>
<p>If you're looking to experiment for the first time with writing an iOS app in
Python, projects such as <aclass="reference external" href="https://beeware.org">BeeWare</a>, <aclass="reference external" href="https://kivy.org">Kivy</a>, and <aclass="reference external" href="https://flet.dev/">Flet</a> 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.</p>
<sectionid="python-at-runtime-on-ios">
<h2><spanclass="section-number">7.1. </span>Python at runtime on iOS<aclass="headerlink" href="#python-at-runtime-on-ios" title="連結到這個標頭">¶</a></h2>
<sectionid="ios-version-compatibility">
<h3><spanclass="section-number">7.1.1. </span>iOS version compatibility<aclass="headerlink" href="#ios-version-compatibility" title="連結到這個標頭">¶</a></h3>
<p>The minimum supported iOS version is specified at compile time, using the
<aclass="reference internal" href="configure.html#cmdoption-host"><codeclass="xref std std-option docutils literal notranslate"><spanclass="pre">--host</span></code></a> option to <codeclass="docutils literal notranslate"><spanclass="pre">configure</span></code>. 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
<codeclass="xref std std-option docutils literal notranslate"><spanclass="pre">--host</span></code> argument - for example,
<codeclass="docutils literal notranslate"><spanclass="pre">--host=arm64-apple-ios15.4-simulator</span></code> would compile an ARM64 simulator build
<p>When executing on iOS, <codeclass="docutils literal notranslate"><spanclass="pre">sys.platform</span></code> will report as <codeclass="docutils literal notranslate"><spanclass="pre">ios</span></code>. This value will
be returned on an iPhone or iPad, regardless of whether the app is running on
the simulator or a physical device.</p>
<p>Information about the specific runtime environment, including the iOS version,
device model, and whether the device is a simulator, can be obtained using
<codeclass="docutils literal notranslate"><spanclass="pre">iPadOS</span></code>, depending on the device.</p>
<p><aclass="reference internal" href="../library/os.html#os.uname" title="os.uname"><codeclass="xref py py-func docutils literal notranslate"><spanclass="pre">os.uname()</span></code></a> reports kernel-level details; it will report a name of
<p>The Python standard library has some notable omissions and restrictions on
iOS. See the <aclass="reference internal" href="../library/intro.html#mobile-availability"><spanclass="std std-ref">API availability guide for iOS</span></a> for
<p>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.</p>
<p>The iOS App Store requires that <em>all</em> binary modules in an iOS app must be
dynamic libraries, contained in a framework with appropriate metadata, stored
in the <codeclass="docutils literal notranslate"><spanclass="pre">Frameworks</span></code> folder of the packaged app. There can be only a single
binary per framework, and there can be no executable binary material outside
the <codeclass="docutils literal notranslate"><spanclass="pre">Frameworks</span></code> folder.</p>
<p>This conflicts with the usual Python approach for distributing binaries, which
allows a binary extension module to be loaded from any location on
<codeclass="docutils literal notranslate"><spanclass="pre">sys.path</span></code>. To ensure compliance with App Store policies, an iOS project must
post-process any Python packages, converting <codeclass="docutils literal notranslate"><spanclass="pre">.so</span></code> binary modules into
individual standalone frameworks with appropriate metadata and signing. For
details on how to perform this post-processing, see the guide for <aclass="reference internal" href="#adding-ios"><spanclass="std std-ref">adding
Python to your project</span></a>.</p>
<p>To help Python discover binaries in their new location, the original <codeclass="docutils literal notranslate"><spanclass="pre">.so</span></code>
file on <codeclass="docutils literal notranslate"><spanclass="pre">sys.path</span></code> is replaced with a <codeclass="docutils literal notranslate"><spanclass="pre">.fwork</span></code> 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 <codeclass="docutils literal notranslate"><spanclass="pre">.origin</span></code> file that contains the location of the
<codeclass="docutils literal notranslate"><spanclass="pre">.fwork</span></code> file, relative to the app bundle.</p>
<p>For example, consider the case of an import <codeclass="docutils literal notranslate"><spanclass="pre">from</span><spanclass="pre">foo.bar</span><spanclass="pre">import</span><spanclass="pre">_whiz</span></code>,
where <codeclass="docutils literal notranslate"><spanclass="pre">_whiz</span></code> is implemented with the binary module
<codeclass="docutils literal notranslate"><spanclass="pre">sources/foo/bar/_whiz.abi3.so</span></code>, with <codeclass="docutils literal notranslate"><spanclass="pre">sources</span></code> being the location
registered on <codeclass="docutils literal notranslate"><spanclass="pre">sys.path</span></code>, relative to the application bundle. This module
<em>must</em> be distributed as <codeclass="docutils literal notranslate"><spanclass="pre">Frameworks/foo.bar._whiz.framework/foo.bar._whiz</span></code>
(creating the framework name from the full import path of the module), with an
<codeclass="docutils literal notranslate"><spanclass="pre">Info.plist</span></code> file in the <codeclass="docutils literal notranslate"><spanclass="pre">.framework</span></code> directory identifying the binary as a
framework. The <codeclass="docutils literal notranslate"><spanclass="pre">foo.bar._whiz</span></code> module would be represented in the original
location with a <codeclass="docutils literal notranslate"><spanclass="pre">sources/foo/bar/_whiz.abi3.fwork</span></code> marker file, containing
the path <codeclass="docutils literal notranslate"><spanclass="pre">Frameworks/foo.bar._whiz/foo.bar._whiz</span></code>. The framework would also
the path to the <codeclass="docutils literal notranslate"><spanclass="pre">.fwork</span></code> file.</p>
<p>When running on iOS, the Python interpreter will install an
<aclass="reference internal" href="../library/importlib.html#importlib.machinery.AppleFrameworkLoader" title="importlib.machinery.AppleFrameworkLoader"><codeclass="xref py py-class docutils literal notranslate"><spanclass="pre">AppleFrameworkLoader</span></code></a> that is able to read and
import <codeclass="docutils literal notranslate"><spanclass="pre">.fwork</span></code> files. Once imported, the <codeclass="docutils literal notranslate"><spanclass="pre">__file__</span></code> attribute of the
binary module will report as the location of the <codeclass="docutils literal notranslate"><spanclass="pre">.fwork</span></code> file. However, the
<aclass="reference internal" href="../library/importlib.html#importlib.machinery.ModuleSpec" title="importlib.machinery.ModuleSpec"><codeclass="xref py py-class docutils literal notranslate"><spanclass="pre">ModuleSpec</span></code></a> for the loaded module will report the
<codeclass="docutils literal notranslate"><spanclass="pre">origin</span></code> as the location of the binary in the framework folder.</p>
<p>Xcode doesn't expose explicit compilers for iOS; instead, it uses an <codeclass="docutils literal notranslate"><spanclass="pre">xcrun</span></code>
script that resolves to a full compiler path (e.g., <codeclass="docutils literal notranslate"><spanclass="pre">xcrun</span><spanclass="pre">--sdk</span><spanclass="pre">iphoneos</span>
<spanclass="pre">clang</span></code> to get the <codeclass="docutils literal notranslate"><spanclass="pre">clang</span></code> for an iPhone device). However, using this script
poses two problems:</p>
<ulclass="simple">
<li><p>The output of <codeclass="docutils literal notranslate"><spanclass="pre">xcrun</span></code> includes paths that are machine specific, resulting
in a sysconfig module that cannot be shared between users; and</p></li>
<li><p>It results in <codeclass="docutils literal notranslate"><spanclass="pre">CC</span></code>/<codeclass="docutils literal notranslate"><spanclass="pre">CPP</span></code>/<codeclass="docutils literal notranslate"><spanclass="pre">LD</span></code>/<codeclass="docutils literal notranslate"><spanclass="pre">AR</span></code> 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 <codeclass="docutils literal notranslate"><spanclass="pre">xcrun</span></code>.</p></li>
</ul>
<p>To avoid these problems, Python provided stubs for these tools. These stubs are
shell script wrappers around the underingly <codeclass="docutils literal notranslate"><spanclass="pre">xcrun</span></code> tools, distributed in a
<codeclass="docutils literal notranslate"><spanclass="pre">bin</span></code> 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 <codeclass="docutils literal notranslate"><spanclass="pre">sysconfig</span></code> 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.</p>
</section>
</section>
<sectionid="installing-python-on-ios">
<h2><spanclass="section-number">7.2. </span>Installing Python on iOS<aclass="headerlink" href="#installing-python-on-ios" title="連結到這個標頭">¶</a></h2>
<sectionid="tools-for-building-ios-apps">
<h3><spanclass="section-number">7.2.1. </span>Tools for building iOS apps<aclass="headerlink" href="#tools-for-building-ios-apps" title="連結到這個標頭">¶</a></h3>
<p>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 <em>full</em> Xcode
install.</p>
<p>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.</p>
</section>
<sectionid="adding-python-to-an-ios-project">
<spanid="adding-ios"></span><h3><spanclass="section-number">7.2.2. </span>Adding Python to an iOS project<aclass="headerlink" href="#adding-python-to-an-ios-project" title="連結到這個標頭">¶</a></h3>
<p>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 <aclass="reference external" href="https://github.com/pvieito/PythonKit">PythonKit</a> to be
helpful.</p>
<p>To add Python to an iOS Xcode project:</p>
<olclass="arabic">
<li><p>Build or obtain a Python <codeclass="docutils literal notranslate"><spanclass="pre">XCFramework</span></code>. See the instructions in
<aclass="extlink-source reference external" href="https://github.com/python/cpython/tree/3.15/Platforms/Apple/iOS/README.md">Platforms/Apple/iOS/README.md</a> (in the CPython source distribution) for details on
how to build a Python <codeclass="docutils literal notranslate"><spanclass="pre">XCFramework</span></code>. At a minimum, you will need a build
that supports <codeclass="docutils literal notranslate"><spanclass="pre">arm64-apple-ios</span></code>, plus one of either
<codeclass="docutils literal notranslate"><spanclass="pre">arm64-apple-ios-simulator</span></code> or <codeclass="docutils literal notranslate"><spanclass="pre">x86_64-apple-ios-simulator</span></code>.</p></li>
<li><p>Drag the <codeclass="docutils literal notranslate"><spanclass="pre">XCframework</span></code> into your iOS project. In the following
instructions, we'll assume you've dropped the <codeclass="docutils literal notranslate"><spanclass="pre">XCframework</span></code> into the root
of your project; however, you can use any other location that you want by
adjusting paths as needed.</p></li>
<li><p>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 <codeclass="docutils literal notranslate"><spanclass="pre">app</span></code> 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.</p></li>
<li><p>Select the app target by selecting the root node of your Xcode project, then
the target name in the sidebar that appears.</p></li>
<li><p>In the "General" settings, under "Frameworks, Libraries and Embedded
Content", add <codeclass="docutils literal notranslate"><spanclass="pre">Python.xcframework</span></code>, with "Embed & Sign" selected.</p></li>
<li><p>In the "Build Settings" tab, modify the following:</p>
<p>If you have placed your XCframework somewhere other than the root of your
project, modify the path to the first argument.</p>
</li>
<li><p>Add Objective C code to initialize and use a Python interpreter in embedded
mode. You should ensure that:</p>
<ulclass="simple">
<li><p>UTF-8 mode (<aclass="reference internal" href="../c-api/init_config.html#c.PyPreConfig.utf8_mode" title="PyPreConfig.utf8_mode"><codeclass="xref c c-member docutils literal notranslate"><spanclass="pre">PyPreConfig.utf8_mode</span></code></a>) is <em>enabled</em>;</p></li>
<li><p>Buffered stdio (<aclass="reference internal" href="../c-api/init_config.html#c.PyConfig.buffered_stdio" title="PyConfig.buffered_stdio"><codeclass="xref c c-member docutils literal notranslate"><spanclass="pre">PyConfig.buffered_stdio</span></code></a>) is <em>disabled</em>;</p></li>
<li><p>Writing bytecode (<aclass="reference internal" href="../c-api/init_config.html#c.PyConfig.write_bytecode" title="PyConfig.write_bytecode"><codeclass="xref c c-member docutils literal notranslate"><spanclass="pre">PyConfig.write_bytecode</span></code></a>) is <em>disabled</em>;</p></li>
<li><p>Signal handlers (<aclass="reference internal" href="../c-api/init_config.html#c.PyConfig.install_signal_handlers" title="PyConfig.install_signal_handlers"><codeclass="xref c c-member docutils literal notranslate"><spanclass="pre">PyConfig.install_signal_handlers</span></code></a>) are <em>enabled</em>;</p></li>
<li><p>System logging (<aclass="reference internal" href="../c-api/init_config.html#c.PyConfig.use_system_logger" title="PyConfig.use_system_logger"><codeclass="xref c c-member docutils literal notranslate"><spanclass="pre">PyConfig.use_system_logger</span></code></a>) is <em>enabled</em>
(optional, but strongly recommended; this is enabled by default);</p></li>
<li><p><spanclass="target" id="index-0"></span><aclass="reference internal" href="cmdline.html#envvar-PYTHONHOME"><codeclass="xref std std-envvar docutils literal notranslate"><spanclass="pre">PYTHONHOME</span></code></a> for the interpreter is configured to point at the
<codeclass="docutils literal notranslate"><spanclass="pre">python</span></code> subfolder of your app's bundle; and</p></li>
<li><p>The <spanclass="target" id="index-1"></span><aclass="reference internal" href="cmdline.html#envvar-PYTHONPATH"><codeclass="xref std std-envvar docutils literal notranslate"><spanclass="pre">PYTHONPATH</span></code></a> for the interpreter includes:</p>
<ul>
<li><p>the <codeclass="docutils literal notranslate"><spanclass="pre">python/lib/python3.X</span></code> subfolder of your app's bundle,</p></li>
<li><p>the <codeclass="docutils literal notranslate"><spanclass="pre">python/lib/python3.X/lib-dynload</span></code> subfolder of your app's bundle, and</p></li>
<li><p>the <codeclass="docutils literal notranslate"><spanclass="pre">app</span></code> subfolder of your app's bundle</p></li>
</ul>
</li>
</ul>
<p>Your app's bundle location can be determined using <codeclass="docutils literal notranslate"><spanclass="pre">[[NSBundle</span><spanclass="pre">mainBundle]</span>
<spanclass="pre">resourcePath]</span></code>.</p>
</li>
</ol>
<p>Steps 7 and 8 of these instructions assume that you have a single folder of
pure Python application code, named <codeclass="docutils literal notranslate"><spanclass="pre">app</span></code>. If you have third-party binary
modules in your app, some additional steps will be required:</p>
<ulclass="simple">
<li><p>You need to ensure that any folders containing third-party binaries are
either associated with the app target, or are explicitly copied as part of
step 7. Step 7 should also purge any binaries that are not appropriate for
the platform a specific build is targeting (i.e., delete any device binaries
if you're building an app targeting the simulator).</p></li>
<li><p>If you're using a separate folder for third-party packages, ensure that
folder is added to the end of the call to <codeclass="docutils literal notranslate"><spanclass="pre">install_python</span></code> in step 7, and
as part of the <spanclass="target" id="index-2"></span><aclass="reference internal" href="cmdline.html#envvar-PYTHONPATH"><codeclass="xref std std-envvar docutils literal notranslate"><spanclass="pre">PYTHONPATH</span></code></a> configuration in step 8.</p></li>
<li><p>If any of the folders that contain third-party packages will contain <codeclass="docutils literal notranslate"><spanclass="pre">.pth</span></code>
files, you should add that folder as a <em>site directory</em> (using
<aclass="reference internal" href="../library/site.html#site.addsitedir" title="site.addsitedir"><codeclass="xref py py-meth docutils literal notranslate"><spanclass="pre">site.addsitedir()</span></code></a>), rather than adding to <spanclass="target" id="index-3"></span><aclass="reference internal" href="cmdline.html#envvar-PYTHONPATH"><codeclass="xref std std-envvar docutils literal notranslate"><spanclass="pre">PYTHONPATH</span></code></a> or
<h3><spanclass="section-number">7.2.3. </span>Testing a Python package<aclass="headerlink" href="#testing-a-python-package" title="連結到這個標頭">¶</a></h3>
<p>The CPython source tree contains <aclass="extlink-source reference external" href="https://github.com/python/cpython/tree/3.15/Platforms/Apple/testbed">a testbed project</a> that
is used to run the CPython test suite on the iOS simulator. This testbed can also
be used as a testbed project for running your Python library's test suite on iOS.</p>
<p>After building or obtaining an iOS XCFramework (see <aclass="extlink-source reference external" href="https://github.com/python/cpython/tree/3.15/Platforms/Apple/iOS/README.md">Platforms/Apple/iOS/README.md</a>
for details), create a clone of the Python iOS testbed project. If you used the
<codeclass="docutils literal notranslate"><spanclass="pre">Platforms/Apple</span></code> build script to build the XCframework, you can run:</p>
<p>Any folders specified with the <codeclass="docutils literal notranslate"><spanclass="pre">--app</span></code> flag will be copied into the cloned
testbed project. The resulting testbed will be created in the <codeclass="docutils literal notranslate"><spanclass="pre">app-testbed</span></code>
folder. In this example, the <codeclass="docutils literal notranslate"><spanclass="pre">module1</span></code> and <codeclass="docutils literal notranslate"><spanclass="pre">module2</span></code> would be importable
modules at runtime. If your project has additional dependencies, they can be
installed into the <codeclass="docutils literal notranslate"><spanclass="pre">app-testbed/Testbed/app_packages</span></code> folder (using <codeclass="docutils literal notranslate"><spanclass="pre">pip</span>
<spanclass="pre">install</span><spanclass="pre">--target</span><spanclass="pre">app-testbed/Testbed/app_packages</span></code> or similar).</p>
<p>You can then use the <codeclass="docutils literal notranslate"><spanclass="pre">app-testbed</span></code> folder to run the test suite for your app,
For example, if <codeclass="docutils literal notranslate"><spanclass="pre">module1.tests</span></code> was the entry point to your test suite, you
<p>This is the equivalent of running <codeclass="docutils literal notranslate"><spanclass="pre">python</span><spanclass="pre">-m</span><spanclass="pre">module1.tests</span></code> on a desktop
Python build. Any arguments after the <codeclass="docutils literal notranslate"><spanclass="pre">--</span></code> will be passed to the testbed as
if they were arguments to <codeclass="docutils literal notranslate"><spanclass="pre">python</span><spanclass="pre">-m</span></code> on a desktop machine.</p>
<p>You can also open the testbed project in Xcode by running:</p>
<h3><spanclass="section-number">7.3.1. </span>Incompatible code in the standard library<aclass="headerlink" href="#incompatible-code-in-the-standard-library" title="連結到這個標頭">¶</a></h3>
<p>The Python standard library contains some code that is known to violate these
automated rules. While these violations appear to be false positives, Apple's
review rules cannot be challenged; so, it is necessary to modify the Python
standard library for an app to pass App Store review.</p>
<p>The Python source tree contains
<aclass="extlink-source reference external" href="https://github.com/python/cpython/tree/3.15/Mac/Resources/app-store-compliance.patch">a patch file</a> that will remove
all code that is known to cause issues with the App Store review process. This
patch is applied automatically when building for iOS.</p>
<p>In April 2025, Apple introduced a requirement for <aclass="reference external" href="https://developer.apple.com/support/third-party-SDK-requirements">certain third-party
libraries to provide a Privacy Manifest</a>.
As a result, if you have a binary module that uses one of the affected
libraries, you must provide an <codeclass="docutils literal notranslate"><spanclass="pre">.xcprivacy</span></code> file for that library.
OpenSSL is one library affected by this requirement, but there are others.</p>
<p>If you produce a binary module named <codeclass="docutils literal notranslate"><spanclass="pre">mymodule.so</span></code>, and use you the Xcode
build script described in step 7 above, you can place a <codeclass="docutils literal notranslate"><spanclass="pre">mymodule.xcprivacy</span></code>
file next to <codeclass="docutils literal notranslate"><spanclass="pre">mymodule.so</span></code>, and the privacy manifest will be installed into
the required location when the binary module is converted into a framework.</p>