{"id":6126,"library":"pyobjc-framework-launchservices","title":"PyObjC LaunchServices Framework","description":"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.","status":"active","version":"12.1","language":"en","source_language":"en","source_url":"https://github.com/ronaldoussoren/pyobjc","tags":["macos","cocoa","launchservices","desktop","pyobjc"],"install":[{"cmd":"pip install pyobjc-framework-launchservices","lang":"bash","label":"Install latest version"}],"dependencies":[{"reason":"Required for core bridge functionality between Python and Objective-C.","package":"pyobjc-core","optional":false}],"imports":[{"symbol":"LSCopyAllApplicationURLs","correct":"from LaunchServices import LSCopyAllApplicationURLs"},{"note":"Commonly used with LaunchServices for URL manipulation.","symbol":"NSURL","correct":"from Foundation import NSURL"}],"quickstart":{"code":"import objc\nfrom Foundation import NSURL\nfrom LaunchServices import LSCopyAllApplicationURLs\n\ndef list_all_applications():\n    # LSCopyAllApplicationURLs returns a CFArrayRef of CFURLRefs\n    # PyObjC automatically bridges these to Python lists and NSURL objects.\n    apps_cf_array = LSCopyAllApplicationURLs(None) # None for all users\n\n    if apps_cf_array:\n        app_urls = list(apps_cf_array)\n        print(f\"Found {len(app_urls)} applications:\")\n        # Print the paths of the first 5 applications for brevity\n        for url in app_urls[:5]:\n            print(f\"- {url.path()}\")\n    else:\n        print(\"No applications found or an error occurred.\")\n\nif __name__ == \"__main__\":\n    # For simple scripts, direct calls are often sufficient.\n    # For UI applications, PyObjC usually runs within a Cocoa event loop.\n    list_all_applications()","lang":"python","description":"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."},"warnings":[{"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.","message":"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.","severity":"gotcha","affected_versions":"All versions"},{"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.","message":"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.","severity":"breaking","affected_versions":">=11.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__`.","message":"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.","severity":"gotcha","affected_versions":"10.3 - 10.3.1"},{"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.","message":"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.","severity":"gotcha","affected_versions":">=11.0 (with Python 3.13+)"}],"env_vars":null,"last_verified":"2026-04-14T00:00:00.000Z","next_check":"2026-07-13T00:00:00.000Z"}