Registry / serialization / pyobjc-framework-launchservices

pyobjc-framework-launchservices

library12.2pypypiunverified

PyObjC-framework-LaunchServices provides Python bindings for Apple's LaunchServices framework on macOS. It allows Python applications to interact with macOS features like launching applications, opening files, and querying file type information. Part of the larger PyObjC project, it is currently at version 12.1 and typically releases alongside new macOS SDK versions and Python major releases.

serialization communication devops

pip install pyobjc-framework-launchservices

github ↗package ↗docs ↗

INSTALL

IMPORT

SIG · PYOBJC-FRAMEWORK-L

pyobjc-framework-launchservices

serializationpythonv12.2

Install

—

Import

—

Disk

—

Pass rate

0/ 10

Env Coverage0 / 10

glibc

3.9–3.13

musl

3.9–3.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.10–3.920 runs

build_error

glibc

py 3.10–3.920 runs

build_error

Code

Verified usage

Verified import paths — ran on the pinned version, not inferred.

LSCopyAllApplicationURLs

✓ from LaunchServices import LSCopyAllApplicationURLs

NSURL

✓ from Foundation import NSURL

Commonly used with LaunchServices for URL manipulation.

This example demonstrates how to use `LSCopyAllApplicationURLs` to retrieve a list of all installed applications on macOS and print their file paths. It shows the basic pattern of importing symbols from PyObjC framework bindings.

import objc from Foundation import NSURL from LaunchServices import LSCopyAllApplicationURLs def list_all_applications(): # LSCopyAllApplicationURLs returns a CFArrayRef of CFURLRefs # PyObjC automatically bridges these to Python lists and NSURL objects. apps_cf_array = LSCopyAllApplicationURLs(None) # None for all users if apps_cf_array: app_urls = list(apps_cf_array) print(f"Found {len(app_urls)} applications:") # Print the paths of the first 5 applications for brevity for url in app_urls[:5]: print(f"- {url.path()}") else: print("No applications found or an error occurred.") if __name__ == "__main__": # For simple scripts, direct calls are often sufficient. # For UI applications, PyObjC usually runs within a Cocoa event loop. list_all_applications()

Debug

Known issues

gotchaPyObjC bindings are generated against specific macOS SDKs. While generally forward-compatible, installing `pyobjc-framework-launchservices` on an older macOS version than the SDK it was built against (or vice-versa) can lead to missing symbols or unexpected behavior. It's best to install PyObjC on the target macOS version or use universal wheels.

fix

Ensure your macOS version is compatible with the PyObjC version's SDK (check release notes, e.g., v12.1 built for 26.1 SDK). Consider using a Python virtual environment to manage dependencies for specific macOS targets.

affects: All versions

breakingIn PyObjC 11.1, the core bridge's behavior for initializer (`init`) methods changed to align with `clang`'s Automatic Reference Counting (ARC) documentation. Methods in the 'init' family now correctly steal a reference to `self` and return a new reference. This can affect custom Objective-C classes subclassed in Python that heavily rely on direct reference counting or `alloc`/`init` patterns.

fix

Review Objective-C subclassing code, especially `alloc`/`init` sequences, to ensure correct object lifecycle management under the new ARC alignment. PyObjC now correctly models the reference ownership.

affects: >=11.1

gotchaPyObjC 10.3 introduced a change that prevented `__init__` from being called when a user-defined `__new__` method was present. This was partially reverted in 10.3.1 to allow `__init__` calls when `__new__` is user-implemented (not the PyObjC-provided `__new__`). If your Python class overrides `__new__` and *also* expects `__init__` to run, be aware of this nuanced behavior, especially when upgrading from versions prior to 10.3.1.

fix

Ensure your class structure correctly handles object initialization. If you override `__new__`, ensure it returns an instance that PyObjC can initialize, or handle all necessary initialization within `__new__` itself. If on 10.3, upgrade to 10.3.1 or later if you rely on `__init__` with custom `__new__`.

affects: 10.3 - 10.3.1

gotchaPyObjC 11.0 introduced *experimental* support for free-threading (PEP 703) in Python 3.13. While this aims for better concurrency, the interaction between Python's GIL and Objective-C's threading model (especially for Cocoa UI operations) can be complex. Exercise caution when using PyObjC in a free-threaded Python environment.

fix

Thoroughly test concurrent code involving PyObjC in free-threaded environments. Consider using traditional threading models (e.g., `threading` module with GIL) if issues arise, or stick to the main thread for Cocoa UI interactions.

affects: >=11.0 (with Python 3.13+)

Upgrade

Version history

12.2latest on PyPI · released May 30, 2026

Audit

Dependencies

pyobjc-corerequiredRequired for core bridge functionality between Python and Objective-C.

Agent activity

13 hits · last 30 days

node

OpenAI (training)

Resources

githubhttps://github.com/ronaldoussoren/pyobjc ↗

packagehttps://pypi.org/project/pyobjc-framework-launchservices/ ↗

docshttps://pyobjc.readthedocs.io/en/latest/ ↗