[Bug] macOS game bookmark app uses shell script as CFBundleExecutable, causing Finder launch failure

[RVZO6]

Prerequisites

• I am confident that my issue has not been reported already in open OR closed issues.
• I am able to reliably reproduce the issue on the latest stable or canary version.
• I am not using an unofficial build (Flatpak, Emudeck, etc.).
• I am a silly goose and DID read these boxes.

Description of the issue

On macOS, the generated game bookmark .app bundle appears to use a shell script directly as CFBundleExecutable:

<key>CFBundleExecutable</key>
<string>runner.sh</string>

with the executable at:

Contents/MacOS/runner.sh

The script itself works when run directly, but launching the generated bookmark app through Finder/LaunchServices fails with:

The application "Finder" does not have permission to open "(null)."

Launching it with open returns:

_LSOpenURLsWithCompletionHandler() failed for the application ... with error -54.

The same generated app also did not reliably appear in Raycast's application index. Spotlight only partially recognized it until the bundle was made more conventional.

This seems to be an app-bundle generation issue rather than an emulation/game issue. macOS LaunchServices, Finder, Spotlight, and third-party launchers expect a more conventional .app bundle. Using a .sh file directly as the bundle executable appears fragile.

A local workaround fixed both launch and indexing:

1. Replaced runner.sh as the main executable with a tiny compiled Mach-O launcher named runner.
2. Changed CFBundleExecutable from runner.sh to runner.
3. Left the existing shell script as an implementation detail invoked by that launcher.
4. Added conventional bundle metadata:

<key>CFBundlePackageType</key>
<string>APPL</string>
<key>CFBundleShortVersionString</key>
<string>1.0</string>
<key>CFBundleIdentifier</key>
<string>com.example.generated-bookmark</string>

5. Added Contents/PkgInfo containing:

APPL????

6. Re-signed the bundle ad-hoc and re-registered it with LaunchServices.

After that, open '/Applications/Tomodachi Life: Living the Dream.app' succeeded and Spotlight/Raycast indexing worked.

A robust implementation probably would not need users to have a compiler installed. Ryujinx/Ryubing could ship one precompiled universal launcher binary and copy it into each generated bookmark app. The generated bookmark app could store the game path/application ID in a plist/json file inside the bundle, and the launcher could exec Ryujinx with the correct arguments.

AppleScript app generation would probably also be more compatible than using a raw shell script as the bundle executable, but a bundled launcher binary seems cleaner.

Reproduction steps

1. On macOS, create a game bookmark app from Ryujinx/Ryubing.
2. Inspect the generated app bundle's Contents/Info.plist.
3. Observe that CFBundleExecutable points directly to runner.sh.
4. Try to open the generated app from Finder.
5. Finder shows: The application "Finder" does not have permission to open "(null)."
6. Try to launch it from Terminal with open '/Applications/<generated bookmark>.app'.
7. open fails with LaunchServices error -54.
8. Run Contents/MacOS/runner.sh directly.
9. The script itself works, confirming the issue is the generated .app bundle/LaunchServices integration.

Log file

This does not appear to produce a normal Ryujinx emulation log because the failure happens before Ryujinx is launched by Finder/LaunchServices.

Relevant terminal output:

_LSOpenURLsWithCompletionHandler() failed for the application /Applications/Tomodachi Life: Living the Dream.app with error -54.

OS

macOS 26.4.1 (25E253)

Ryujinx version

1.3.294

Game version

N/A - issue is with generated macOS bookmark app bundle before game launch

CPU

Apple M4 Pro

GPU

Apple M4 Pro integrated GPU

RAM

24GB

List of applied mods

N/A

Additional context?

The generated bookmark app had metadata similar to:

kMDItemContentType = "com.apple.application-bundle"
kMDItemFSName = "Tomodachi Life: Living the Dream.app"

but Finder/LaunchServices launch failed until the bundle used a Mach-O executable stub instead of the shell script as CFBundleExecutable, and until conventional app metadata such as CFBundlePackageType=APPL was added.

[sh0inx]

this will likely be resolved once we transition to gruke (.dmg bundle, anyone?), but we can't build using any apple scripture, since we don't have a macOS runner.

[RVZO6]

could just shell out to osacompile but i suppose thats clunky