Registry /
serialization / pyobjc-framework-intents
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.
INIntent
✓ from Intents import INIntent
✗ import INIntent
Framework classes are imported directly from their corresponding Python package, not as top-level modules.
This quickstart demonstrates how to import a class from the `Intents` framework and instantiate a basic `INIntent` object using PyObjC. Full integration with Apple's Intents system (e.g., for Siri or Shortcuts) typically requires defining and configuring intents within an Xcode project and running within an application context. The example also shows a minimal Objective-C class definition pattern in Python.
from Intents import INIntent
from Foundation import NSObject
import objc
# PyObjC often requires an application context for full functionality.
# This is a minimal example demonstrating class access.
# Instantiate a basic INIntent object (typically a subclass would be used)
# Note: Actual use of Intents often involves a complex app setup and definition
# through Xcode's project capabilities for proper system integration.
try:
# Attempt to create a generic INIntent instance
# In a real scenario, you'd subclass INIntent or use a specific IN*Intent class
intent = INIntent.alloc().init()
print(f"Successfully created INIntent instance: {intent}")
print(f"Intent identifier: {intent.identifier()}")
except objc.nosuchclass_error:
print("Intents framework classes are not available or Intents is not properly linked.")
except Exception as e:
print(f"An error occurred: {e}")
# Example of how to define a simple Python class that could interact with Intents
# (though direct INIntent subclassing in Python for full functionality might be limited
# without Xcode-generated intent definitions)
class MySimpleIntentHandler(NSObject):
def init(self):
self = super().init()
if self is None:
return None
print("MySimpleIntentHandler initialized.")
return self
@objc.python_method
def handleMyCustomIntent_(self, intent):
print(f"Handling custom intent: {intent.identifier()}")
# In a real app, this would process the intent
return None # Or return an INIntentResponse
if __name__ == '__main__':
# This part would usually run within an application main loop (e.g., AppKit.NSApplication.sharedApplication().run())
# For a simple script, it demonstrates object creation.
handler = MySimpleIntentHandler.alloc().init()
# Simulate calling the handler with a basic intent (won't actually do anything useful without a real intent from the system)
# For demonstration, we'll create a dummy INIntent
dummy_intent = INIntent.alloc().init()
dummy_intent.setValue_forKey_(f"com.example.myintent.{id(dummy_intent)}", "identifier") # Set a dummy identifier
handler.handleMyCustomIntent_(dummy_intent)
Debug
Known issues
breakingPyObjC 12.0 dropped support for Python 3.9, and PyObjC 11.0 dropped support for Python 3.8. PyObjC 12.1 requires Python >=3.10.fixUpgrade Python to 3.10 or later. For Python 3.9, use PyObjC 11.1; for Python 3.8, use PyObjC 10.3.
affects: <12.1 for Python 3.9, <11.0 for Python 3.8
breakingPyObjC 11.1 introduced significant changes to how initializer methods (`init...`) handle reference counts, aligning with `clang`'s Automatic Reference Counting (ARC) documentation. This means `init` family methods now correctly model stealing a reference to `self` and returning a new one. Code relying on previous behavior regarding partially initialized objects or manual reference counting in initializers may exhibit bugs.fixReview and update code that explicitly manages object lifetimes or relies on specific reference counting behavior in `init` methods, following ARC principles. Use `SomeClass(...)` or `SomeClass.alloc().init(...)` for object creation instead of patterns that accidentally worked previously.
affects: >=11.1
gotchaPyObjC (v10.3) initially removed support for `__init__` when a class or its superclasses provided a user-defined `__new__` method, causing breaks in existing projects. While v10.3.1 partially restored this for user-implemented `__new__`, code relying on PyObjC's provided `__new__` still cannot use `__init__`.fixIf implementing `__new__`, ensure `__init__` is compatible or carefully manage object initialization. Avoid relying on `__init__` when using PyObjC's default `__new__` mechanism.
affects: >=10.3
breakingPyObjC may drop support for framework bindings if Apple deprecates or removes the underlying macOS framework. For example, PyObjC 10 removed `IMServicePlugIn` bindings as the framework was deprecated in macOS 10.13 and removed in macOS 14.fixStay updated with macOS changes and PyObjC release notes to anticipate framework deprecations. Adjust your application if a required framework's bindings are removed.
affects: All versions (future risk)
gotchaPyObjC 11.0 introduced experimental support for free-threading (PEP 703) in Python 3.13, requiring significant internal changes. While supported, users should be aware of its experimental nature and potential for concurrency-related issues.fixExercise caution when using PyObjC with free-threading. Thoroughly test thread-safe code and be aware of potential limitations or unsupported thread-unsafe functionalities mentioned in PyObjC documentation.
affects: >=11.0 when using Python 3.13+
gotchaPyObjC is exclusively for macOS. Installing from source requires Xcode or the Command Line Tools with the *latest* macOS SDK. Using an older SDK can lead to build errors. Binary wheels also have specific macOS version support depending on the Python version.fixEnsure you are running on macOS. Install the latest Xcode Command Line Tools via `xcode-select --install` before attempting source builds. Match your Python version and PyObjC wheel to compatible macOS versions.
affects: All versions
gotchaObjective-C method names (selectors) containing colons (e.g., `doSomething:withSomethingElse:`) are mapped to Python method names with underscores replacing colons (e.g., `doSomething_withSomethingElse_`). Forgetting this convention is a common source of `AttributeError`.fixAlways translate Objective-C selectors by replacing colons with underscores in Python method calls (e.g., `myObject.methodWithArg_otherArg_(arg1, arg2)`).
affects: All versions
Upgrade
Version history
12.2latest on PyPI · released May 30, 2026
Audit
Dependencies
pyobjc-corerequiredProvides the core bridge between Python and Objective-C, essential for all PyObjC framework wrappers.