PyObjC LaunchServices Framework

Warnings

• gotcha PyObjC 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.
• breaking In 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.
• gotcha PyObjC 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__`.
• gotcha PyObjC 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.

Install

• pip install pyobjc-framework-launchservices Install latest version

Imports

• LSCopyAllApplicationURLs

  from LaunchServices import LSCopyAllApplicationURLs

• NSURL

  from Foundation import NSURL

  Commonly used with LaunchServices for URL manipulation.

Quickstart

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()