macOS and Python: Should CPython keep shipping macOS installers?

# Overview

At the Python Language Summit 2026, Ned Deily reviewed whether CPython should continue producing official macOS installers. CPython releases are primarily source tarballs, but historically Python.org has also shipped prebuilt installers for Windows and macOS. Ned challenged the community to decide if continuing to ship macOS installers still makes sense given macOS platform changes, current maintenance burden, and how downstream projects handle macOS Python builds.

# What makes macOS different

macOS uses three distinct CPython build types: static and shared (like other Unix systems) and a macOS/iOS-specific framework build. Framework builds package Python in a structure that eases embedding into macOS apps. Apple toolchains support multi-architecture binaries (ARM64 and x86-64) in single "fat" files, and Apple SDKs live inside SDK bundles rather than standard system paths, which affects how builds find headers and libraries. The same tooling also supports iOS-related platforms.

# Current problems with the official macOS installer

Ned described the python.org macOS installer as having significant technical debt accumulated over 25 years. Specific issues include:

• File layout that doesn't follow modern macOS guidelines.
• No support for macOS sandboxing required for App Store distribution.
• A single system-wide install location rather than more flexible options.
• Framework versioning that doesn't match Python's versioning and ABI compatibility expectations.

Maintenance has been sparse: the installer work has been "in a dark corner," often handled by only a few people, and at times by a single maintainer. That fragile maintenance model led Ned to ask whether the project should stop shipping installers or reorganize how they are supported.

# Who uses the official macOS builds?

# Proposed next steps

Ned laid out several concrete proposals:

• Define an overall macOS support policy covering people who build CPython locally and what the project supports upstream.
• Consider treating each macOS build type and architecture as separate PEP 11 targets (for example, macOS/ARM vs macOS/x86-64) to allow different support tiers.
• Raise awareness: move macOS installer knowledge out of a narrow maintainer group so more core developers know how changes affect macOS packaging.
• Automate builds, packaging, and continuous integration for macOS in a manner similar to existing Windows automation.
• Leverage overlap between macOS and iOS builds to reduce duplicate effort.

Ned also suggested collecting data via the Python Developers Survey to better understand who uses the python.org macOS installers.

# Practical implications right now

If the community keeps shipping official macOS installers, it needs to invest in maintenance, documentation, and CI automation. If the community decides to stop, downstreams that already build their own binaries will continue to do so, but some user groups relying on a simple official installer may lose an upstream distribution path.

# Bottom line

The immediate decision is whether to continue automatic shipping of macOS installers or pause until the project has a clearer policy, better automation, and broader maintainer knowledge. Ned favors adding macOS to PEP 11, clarifying support per build and architecture, and improving automation and visibility before proceeding further.