Registry / serialization / pyobjc-framework-intents

pyobjc-framework-intents

JSON →
library12.2pypypiunverified

PyObjC-framework-intents provides Python wrappers for Apple's Intents framework on macOS, enabling developers to integrate Python applications with system services like Siri and Shortcuts. It is part of the larger PyObjC project, a bridge between Python and Objective-C. The library is actively maintained, with releases often coinciding with new macOS SDK updates to ensure compatibility and introduce new features.

pip install pyobjc-framework-intents
INSTALL
IMPORT
SIG · PYOBJC-FRAMEWORK-I
P
pyobjc-framework-intents
serializationpythonv12.2
Install
Import
Disk
Pass rate
0/ 10
Env Coverage0 / 10
glibc
3.93.13
musl
3.93.13
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
musl
py 3.103.920 runs
build_error
glibc
py 3.103.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.
fix
Upgrade 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.
fix
Review 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__`.
fix
If 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.
fix
Stay 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.
fix
Exercise 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.
fix
Ensure 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`.
fix
Always 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.
Agent activity
7 hits · last 30 days
node
6
Resources
pyobjc-framework-intents — pip install pyobjc-framework-intents · libregistry