Registry / pyobjc-framework-systemextensions
Install & Compatibility
Where this runs
tested against v? · pip install
Install × environment matrix
Each cell = how many times install + import succeeded across repeated harness runs. Partial = flaky.
glibc = Debian/Ubuntu slim · musl = Alpine Linux
muslpy 3.10–3.920 runs
build_error
glibcpy 3.10–3.920 runs
build_error
Code
Verified usage
Verified import paths — ran on the pinned version, not inferred.
SystemExtensions
✓ import SystemExtensions
Frameworks are typically imported as top-level packages named after the framework itself.
SESystemExtensionManager
✓ import SystemExtensions
manager = SystemExtensions.SESystemExtensionManager.sharedManager()
This quickstart demonstrates how to import the `SystemExtensions` framework and access a common entry point like `SESystemExtensionManager.sharedManager()`. Full interaction with system extensions, such as installing or uninstalling, requires specific macOS entitlements and user permissions which are outside the scope of a basic runnable example. The example illustrates the standard PyObjC pattern for accessing framework classes and shared instances.
import Foundation
import SystemExtensions
# Accessing the shared system extension manager
manager = SystemExtensions.SESystemExtensionManager.sharedManager()
# Note: Interacting with SystemExtensions typically requires specific
# entitlements and user permissions, and cannot be fully demonstrated
# in a simple, non-privileged quickstart example.
# This example primarily shows the import and class access pattern.
print(f"SESystemExtensionManager instance: {manager}")
# For example, to get currently installed extensions (requires permissions):
# extensions = manager.installedExtensions()
# if extensions:
# print(f"Installed extensions: {extensions}")
# else:
# print("No system extensions found or permission denied.")
Debug
Known issues
breakingPyObjC 12.0 dropped support for Python 3.9, and PyObjC 11.0 dropped support for Python 3.8. Users must ensure their Python version meets the `>=3.10` requirement for `pyobjc-framework-systemextensions 12.1`.fixUpgrade Python to 3.10 or newer. Check `requires_python` in PyPI metadata for exact version compatibility.
affects: 11.0, 12.0, 12.1
breakingPyObjC 11.1 changed how initializer methods (methods in the 'init' family) handle reference counting, aligning with `clang`'s documentation. PyObjC now correctly models that these methods steal a reference to `self` and return a new reference. Previous versions might have exhibited incorrect behavior, especially with singletons or specific `alloc`/`init` patterns.fixReview Objective-C `alloc().init()` patterns in your Python code, especially if directly managing `NSObject` lifecycles or subclassing. It's generally recommended to use the more Pythonic `SomeClass(...)` constructor if available, introduced in PyObjC 10.3, which handles the `alloc()`/`init()` process correctly.
affects: >=11.1
gotchaWhen creating Objective-C objects in Python, PyObjC 10.3 introduced a more Pythonic constructor style (e.g., `SomeClass(...)`) alongside the traditional `SomeClass.alloc().init_method(...)`. While both still exist, the `SomeClass.alloc().init_method(...)` pattern had subtle reference counting issues in older versions and is less idiomatic Python. Directly assigning to `alloc` (e.g., `obj.alloc = MyObject.alloc`) was fixed in v12.2 to prevent `AttributeError`.fixPrefer the `SomeClass(...)` constructor where possible. If using `alloc().init_method(...)`, ensure correct reference handling, especially with custom subclasses or complex initialization. Avoid assigning `alloc` as an attribute.
affects: >=10.3
gotchaSubclasses of `NSProxy` defined in Python may have issues with Key-Value Observing (KVO) usage. PyObjC 12.1 automatically disables KVO for these subclasses to prevent potential problems.fixIf you are subclassing `NSProxy` in Python and relying on KVO, be aware that it will be automatically disabled. Consider alternative observation mechanisms or review your design if KVO is critical for `NSProxy` subclasses.
affects: >=12.1
gotchaBuilding PyObjC (or its framework wrappers) from source requires Apple's Xcode Command Line Tools to be installed. Using an older macOS SDK or an outdated Python environment during the build process can lead to compilation errors.fixEnsure Xcode Command Line Tools are installed (`xcode-select --install`). Use the latest macOS SDK available on your system, and ensure your Python environment is compatible with the `pyobjc` version being installed. Installing via binary wheels using `pip` is the preferred and often easiest method.
affects: All versions (when building from source)
Upgrade
Version history
12.2latest on PyPI · released May 30, 2026
Audit
Dependencies
pyobjc-corerequiredCore bridging library for Python and Objective-C, required by all PyObjC framework wrappers.
pyobjc-framework-CocoarequiredCommon dependency for macOS framework interactions, providing core Cocoa classes like NSObject.
pythonrequiredRequires Python 3.10 or later.