Registry / pyobjc-framework-safariservices
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.940 runs
build_error
glibcpy 3.10–3.940 runs
build_error
Code
Verified usage
Verified import paths — ran on the pinned version, not inferred.
SafariServices
✓ import SafariServices
✗ from AppKit import SafariServices
Frameworks are typically imported directly after importing `objc` if needed, not usually from AppKit.
This example demonstrates how to import the SafariServices framework and instantiate a basic object like `SFSafariViewController`. In a full macOS application, UI-related objects like `SFSafariViewController` must be created and managed on the main thread within an `NSApplication` context.
import objc
from Foundation import NSURL
import SafariServices
# Get the Python class for SFSafariViewController
# This class is part of SafariServices.framework
SFSafariViewController = SafariServices.SFSafariViewController
# Create a sample URL
url = NSURL.URLWithString_("https://www.example.com")
# Instantiate SFSafariViewController
# In a real macOS application, this controller would need to be
# initialized on the main thread and presented by an NSViewController.
# For this quickstart, we just demonstrate instantiation.
try:
controller = SFSafariViewController.alloc().initWithURL_entersReaderIfAvailable_(url, False)
print(f"Successfully created SFSafariViewController instance: {controller}")
# Example of accessing a property (if available and safe outside main thread)
# if hasattr(controller, 'URL'):
# print(f"Controller URL: {controller.URL()}")
except Exception as e:
print(f"Error instantiating SFSafariViewController (may require main thread/application context): {e}")
print("Note: SFSafariViewController typically requires a running Cocoa application and main thread for full functionality.")
Debug
Known issues
breakingPyObjC major versions frequently drop support for older Python versions. For example, v12.0 dropped Python 3.9, and v11.0 dropped Python 3.8. Ensure your Python environment meets the `requires_python` specification for the PyObjC version you are using.fixUpgrade Python to a supported version for your PyObjC release, or use an older PyObjC version compatible with your Python environment. Always check `requires_python` on PyPI.
affects: All major versions (e.g., v11.0+, v12.0+)
breakingPyObjC releases are tightly coupled with macOS SDK versions. Upgrading macOS might require upgrading PyObjC to a version that includes updated framework bindings for the new SDK, or vice-versa. Using an incompatible combination can lead to missing symbols or unexpected behavior.fixKeep PyObjC updated with your macOS version. Check PyObjC release notes for targeted macOS SDK support. For critical applications, pin PyObjC to a version known to work with your specific macOS release.
affects: All versions, especially when crossing major macOS updates
gotchaPyObjC v11.1 introduced significant changes to how initializer (`init` family) methods handle automatic reference counting (ARC). Previously, PyObjC might not have correctly modeled that `init` methods steal a reference to `self` and return a new reference. This can lead to memory management issues if not handled correctly when implementing custom Cocoa classes in Python.fixWhen implementing `init` methods in Python subclasses of Cocoa objects, be aware of the ARC semantics. Ensure proper reference management, especially if porting code from older PyObjC versions or if encountering unexpected deallocations.
affects: v11.1+
gotchaPyObjC's handling of `__init__` and `__new__` for user-defined subclasses of Cocoa objects can be tricky. In v10.3, `__init__` was disabled when a user-defined `__new__` was present, causing breakage. While v10.3.1 re-enabled `__init__` for specific `__new__` scenarios, it highlights a potential footgun when customizing object creation.fixWhen subclassing Cocoa objects and providing custom `__new__` or `__init__` methods, thoroughly test object lifecycle. Prefer using standard Cocoa initializer patterns where possible. Refer to PyObjC documentation for best practices on subclassing and initialization.
affects: v10.3 - v10.3.1, potentially earlier versions with complex `__new__` implementations.
gotchaFrameworks can be deprecated or removed by Apple in newer macOS versions. PyObjC will drop bindings for such frameworks when they can no longer be built against the latest SDK (e.g., IMServicePlugIn in v10.0). Code relying on deprecated frameworks may stop working unexpectedly.fixRegularly check Apple's developer documentation for framework deprecations and removals. Be prepared to update your code to use modern APIs if a framework you rely on becomes unavailable in a newer PyObjC version.
affects: All versions, dependent on macOS updates
Upgrade
Version history
12.2latest on PyPI · released May 30, 2026
Audit
Dependencies
pyobjc-corerequiredProvides the core bridge between Python and Objective-C.