Python Bindings for SharedWithYouCore Framework

Warnings

• breaking Python 3.9 support was dropped in PyObjC 12.0. Version 12.0 incorrectly listed Python 3.9 in its packaging metadata, causing installation failures when building from source. This was corrected in version 12.1. [2, 17]
  Fix: Upgrade to `pyobjc-framework-sharedwithyoucore` version 12.1 or higher, or use a supported Python version (3.10+). [2, 17]
• breaking PyObjC 11.0 dropped support for Python 3.8. [2]
  Fix: Use Python 3.9 or later with PyObjC 11.x, or Python 3.10 or later with PyObjC 12.x. [2, 6]
• gotcha PyObjC 10.3 introduced a change that broke `__init__` when `__new__` was *not* explicitly implemented in Python classes. Version 10.3.1 partially reverted this, allowing `__init__` when `__new__` is user-implemented. However, classes relying on PyObjC's default `__new__` still cannot use `__init__` in the same way. [2, 27]
  Fix: Review Python classes subclassing Objective-C objects, especially those with custom `__init__` or `__new__` methods. Ensure `__new__` is explicitly defined if `__init__` is used, or adapt to the Objective-C two-phase instantiation model (`alloc().init()`) directly. [12, 30]
• gotcha While PyObjC supports free-threading (experimental in Python 3.13), Apple's Cocoa frameworks are generally not thread-safe. Many GUI elements and certain Core Foundation types require interaction on the main thread. Always manage `NSAutoreleasePool`s explicitly in new threads. [1, 11]
  Fix: Carefully review Apple's documentation for thread-safety of specific framework classes. Use `performSelectorOnMainThread_` or similar mechanisms for GUI updates. Implement explicit `NSAutoreleasePool` creation and drainage in non-main threads. [1, 11]
• breaking PyObjC 11.1 aligned its core bridge behavior for Automatic Reference Counting (ARC) with `clang`'s documentation, specifically for initializer methods (e.g., `init` family). This means methods in the 'init' family now correctly steal a reference to `self` and return a new reference, changing the proxy behavior for `[NSObject alloc]`. [2]
  Fix: Review code that directly manipulates or relies on the exact reference count behavior of objects returned from `alloc()` prior to `init()` calls, as the handling of 'partially initialized' objects has been rearchitected. [2]

Install

• pip install pyobjc-framework-sharedwithyoucore Install latest version

Imports

• SWCollaborationCoordinator

  from SharedWithYouCore import SWCollaborationCoordinator

• SWStartCollaborationAction

  from SharedWithYouCore import SWStartCollaborationAction

Quickstart

This example demonstrates how to import a class from the `SharedWithYouCore` framework and instantiate a `SWCollaborationCoordinator` object. It also includes the necessary `NSAutoreleasePool` management, which is a common pattern in PyObjC applications. [13, 16]

from Foundation import NSAutoreleasePool
from SharedWithYouCore import SWCollaborationCoordinator
import objc

# PyObjC requires an NSAutoreleasePool for many Cocoa operations
pool = NSAutoreleasePool.alloc().init()

try:
    # Get the SWCollaborationCoordinator class
    CoordinatorClass = SWCollaborationCoordinator

    # Instantiate the coordinator
    coordinator = CoordinatorClass.alloc().init()
    
    print(f"Successfully instantiated SWCollaborationCoordinator: {coordinator}")
    print(f"Is it an Objective-C object? {isinstance(coordinator, objc.objc_object)}")

except Exception as e:
    print(f"An error occurred: {e}")
finally:
    # Release the autorelease pool to clean up Cocoa objects
    del pool