fix(release): package macOS build as a proper .app bundle#19
Merged
Conversation
The macOS release shipped the raw single-file executable (EftViewer.Desktop). Double-clicking a bare Mach-O in Finder produces the "choose an application to open this" prompt because there is no .app bundle / Info.plist for LaunchServices to register. Wrap the published output in EftViewer.app (Contents/MacOS + Info.plist from a committed template) and archive it with `ditto` so the bundle structure survives zipping. Windows and Linux packaging are unchanged. Note: binaries remain unsigned/unnotarized, so first launch still needs right-click -> Open (or xattr -dr com.apple.quarantine). Code signing is tracked separately. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- LSMinimumSystemVersion 11.0 -> 12.0 (actual .NET 10 macOS runtime floor; 11.0 would advertise false Big Sur support and crash on launch there) - Strip *.pdb from the .app bundle (debug symbols don't belong in Contents/MacOS) - Drop the unused empty Contents/Resources dir (ditto wouldn't archive it anyway) - Add `test -x` assertion so the job fails loudly if the executable name ever drifts from CFBundleExecutable instead of shipping a broken bundle Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Owner
Author
Review — isolated pass (Code Reviewer)The change does exactly what it claims: the macOS asset becomes a double-clickable No blockers. Findings addressed in follow-up commit
Out of scope (acknowledged): unsigned/unnotarized → first launch needs right-click → Open; no (Posted as a comment — GitHub blocks self-approval.) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Downloading the macOS release asset, unzipping, and double-clicking yields macOS's "choose an application to open this" prompt. The release shipped the raw single-file executable (
EftViewer.Desktop) — a bare Mach-O has no.appbundle /Info.plist, so Finder/LaunchServices can't launch it by double-click.Fix
For the
osx-arm64build, wrap the publish output in a properEftViewer.app:Contents/MacOS/← published binary (+x)Contents/Info.plist← generated from committed template.github/macos/Info.plistwith the tag version substitutedditto -c -k --keepParentso the bundle structure/symlinks survive zipping (plainzip -rcan mangle.appbundles)Windows (
7z) and Linux (zip) packaging are unchanged — only refactored into subshells so they no longer rely on a persistentcd.Validation
release.ymlparses as valid YAMLInfo.plistparses viaplistlib→com.willtyler.eftviewer,CFBundlePackageType=APPL,CFBundleExecutable=EftViewer.DesktopKnown follow-up (out of scope)
Binaries are still unsigned/unnotarized, so first launch needs right-click → Open (or
xattr -dr com.apple.quarantine EftViewer.app). Code signing / notarization is tracked separately. No.icnsicon yet → generic Dock icon.🤖 Generated with Claude Code