Registry /
serialization / pyobjc-framework-installerplugins
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.
InstallerPlugins
✓ import InstallerPlugins
Imports the InstallerPlugins framework classes and functions directly.
NSObject
✓ from Foundation import NSObject
Commonly used base class for Objective-C objects, part of the core Foundation framework.
objc
✓ import objc
Provides core PyObjC bridging utilities, decorators, and functions.
This quickstart demonstrates how to import the `InstallerPlugins` framework and define a basic Objective-C compatible class in Python. Actual usage as an Installer Plugin requires a specific project structure, Objective-C class definition patterns, and bundling into a `.bundle` within an installer package, typically managed with tools like `py2app` and proper `InstallerSections.plist` configuration. This example focuses on the Python-side import and class definition.
from Foundation import NSObject
import objc
import InstallerPlugins
class MyCustomInstallerSection(NSObject):
# The 'alloc().init()' pattern is standard for Objective-C object creation.
# Python methods often use trailing underscores for Objective-C selector arguments.
# Example: Defining a method that an Installer Plugin might call.
# In a real plugin, you would override specific methods like 'initWithSection_'.
@objc.python_method
def myPluginMethod_(self, installerSection):
print(f"My custom installer plugin method called by: {installerSection}")
# You'd typically interact with installerSection here
return True
# This simple script demonstrates importing the framework and defining a class.
# A real Installer Plugin requires specific project structure and bundling
# (e.g., using py2app) to be loaded by the macOS Installer.app.
if __name__ == '__main__':
print("InstallerPlugins framework imported successfully.")
# Instantiate the class (though it won't be 'used' without Installer.app)
plugin_instance = MyCustomInstallerSection.alloc().init()
print(f"Instance created: {plugin_instance}")
# Demonstrate calling a custom method (for illustrative purposes)
# In practice, the macOS Installer would call specific methods on your plugin.
# Replace 'None' with a mock InstallerSection object if testing interaction.
plugin_instance.myPluginMethod_(None)
Debug
Known issues
breakingPyObjC v12.0 dropped support for Python 3.9. Projects must upgrade to Python 3.10 or newer.fixUpgrade your Python environment to 3.10 or a later supported version. PyObjC v11.0 similarly dropped Python 3.8 support.
affects: >=12.0
breakingIn PyObjC v11.1, the behavior for Objective-C initializer methods ('init' family) was aligned with `clang`'s Automatic Reference Counting (ARC) documentation. PyObjC now correctly models that these methods steal a reference to `self` and return a new reference, which might change memory management expectations for custom initializers.fixReview custom initializer methods in Python subclasses of Objective-C objects, especially those interacting with `alloc` and `init` patterns, to ensure correct reference handling under the updated ARC model.
affects: >=11.1
gotchaPyObjC 10.3 did not support Python 3.13's experimental free-threading (PEP 703). While PyObjC 11.0 introduced *experimental* support, developers should be cautious and test thoroughly when using PyObjC with free-threading Python interpreters, as the bridge's internal C API usage may still have edge cases.fixAvoid using free-threading Python 3.13+ with PyObjC unless explicitly requiring and thoroughly testing the experimental support. If issues arise, use a standard Python interpreter.
affects: 10.3 (no support), 11.0+ (experimental support)
gotchaThere was a temporary change in PyObjC v10.3 where `__init__` could not be used when a class or its superclasses had a user-implemented `__new__`. This was largely reverted in v10.3.1 to support popular projects, but understanding the interaction between `__new__` and Objective-C's two-phase instantiation (`alloc`/`init`) is crucial.fixIf implementing `__new__` in a PyObjC-bridged class, be aware of how it interacts with Objective-C's `alloc` and `init` patterns. For most cases, rely on the behavior re-introduced in 10.3.1, but complex scenarios might require explicit `objc.pyobjc_id` usage.
affects: 10.3, 10.3.1
breakingPyObjC v10.0 removed the `IMServicePlugIn` bindings entirely, as the framework was deprecated in macOS 10.13 and removed in macOS 14. While this specific package is `InstallerPlugins`, it demonstrates a pattern where bindings for deprecated macOS frameworks are removed in major PyObjC versions without backward compatibility.fixAlways check PyObjC release notes for deprecation or removal of bindings for specific macOS frameworks, especially when upgrading major PyObjC versions or targeting newer macOS versions. Plan to refactor code relying on removed frameworks.
affects: >=10.0 (for IMServicePlugIn)
Upgrade
Version history
12.2latest on PyPI · released May 30, 2026
Audit
Dependencies
pyobjc-corerequiredThe core PyObjC bridge is required for all framework wrappers.