[macOS] release app silently rewrites itself on first launch (unpacks Resources/<hash>.tar.zst)

[theopak]

Summary

Opening a built production Electrobun app for the first time increases the app's size while it self-unpacks an internal <hash>.tar.zst artifact. This can cause first-launch to fail until second launch when it takes too long, or to fail permanently if storage is full. It doesn't unpack until first launch.

In my case, it made an Electrobun app 4x bigger after opening it for the first time. From an end-user perspective, this breaks the expectation that the .app in the .dmg is already the size needed to install by dragging into the Applications folder.

Observed

• In non-dev macOS builds, the shipped .app is a wrapper containing Contents/Resources/<hash>.tar.zst.
• On first launch, it unpacks into the bundle (new files under Contents/MacOS and Contents/Resources/app).
• App size increases after first open, and first launch takes longer.
• This can fail on low free disk, because install-time footprint is smaller than steady-state footprint.

Expected

• A copied .app should be in its final on-disk state at install time (or at least offer a mode for that).
• No silent first-launch extraction that mutates bundle contents and changes app size.

Repro

1. Build a minimal Electrobun app with non-dev env (build --env=stable or equivalent production env).
2. Before first run:
   • du -sh "/Volumes/My App/My App.app"
   • ls "/Volumes/My App/My App.app/Contents/Resources" (contains <hash>.tar.zst)
3. Copy to Applications and launch once:
   • cp -R "/Volumes/My App/My App.app" "/Applications/My App.app"
   • open "/Applications/My App.app"
4. After first run:
   • du -sh "/Applications/My App.app" (larger)
   • Contents/MacOS and Contents/Resources/app now contain extracted runtime files.

Suggestion

What do you think of adding an ElectrobunConfig option to disable self-extract packaging on macOS (ship fully expanded bundle; skip creating/extracting .tar.zst)?

Context (Apple docs)

• Gatekeeper/runtime protection frames checks around identified developer, notarization, and unaltered software: Gatekeeper and runtime protection in macOS
• Apple code-signing model emphasizes tamper detection: App code signing process in macOS
• Notarization troubleshooting warns bundle modifications after signing can invalidate signature assumptions: Resolving common notarization issues

Additional Information

• Electrobun 1.16.0
• Bun 1.3.11 macOS Silicon
• macOS 26.3.1

[beautyfree]

Adding another failure mode caused by the same first-launch self-extract design, in case it helps build the case for a ship-expanded option.

Symptom

Signed + notarized .app silently exits on first launch when run from any location other than /Applications (Downloads, Desktop, or directly from a mounted DMG). No window appears, no crash dialog — the Dock icon bounces once, then disappears. Moving the .app to /Applications first makes it work.

Root cause (same as #359)

macOS Gatekeeper Path Randomization (App Translocation) runs a quarantined .app from a read-only mount at /private/var/folders/.../AppTranslocation/XXXX/d/MyApp.app. The first-launch self-extract step from #359 then tries to mutate the bundle (or rename across filesystems into ~/Library/Application Support/<bundle-id>/…), which fails with EXDEV / RenameAcrossMountPoints. The launcher exits before our Bun entrypoint runs, so the app can't catch it and show a message.

Repro

1. Build with electrobun build --env=stable, sign + notarize, staple.
2. Download the DMG via browser (gets the com.apple.quarantine xattr).
3. Double-click MyApp.app directly inside the mounted DMG — or copy it to ~/Downloads and open from there.
4. App bounces in Dock and exits silently.
5. Drag the same .app into /Applications and launch — works normally.

Can reproduce on:

• Electrobun 1.x (latest tag)
• Bun 1.3.x
• macOS 14/15 (Apple Silicon)

Workaround we use today

Ship a hand-styled DMG (create-dmg with an arrow + /Applications shortcut) to visually force drag-to-Applications, same as Chrome/Slack. It hides the bug but doesn't fix it — any user who double-clicks inside the DMG still hits it.

Why ship-expanded would fix this

If the bundle is already in its final on-disk shape (no <hash>.tar.zst to unpack on first launch), no filesystem writes are needed at startup, so translocated read-only execution works. This matches how Electron and Tauri ship.

+1 on the ElectrobunConfig option suggested in the issue body.

[beautyfree]

Follow-up with a concrete code pointer — I cloned the repo to pinpoint why this specific failure mode happens, in case it helps anyone picking this up.

The mutation that breaks under App Translocation is in package/src/extractor/main.zig#L1377-L1378:

std.fs.deleteTreeAbsolute(APPBUNDLE_PATH) catch {};
try std.fs.renameAbsolute(newBundlePath, APPBUNDLE_PATH);

Where:

• APPBUNDLE_PATH = the outer .app the user launched. Under translocation this is /private/var/folders/.../AppTranslocation/XXXX/d/MyApp.app on a read-only mount.
• newBundlePath = ~/Library/Application Support/<identifier>/<channel>/self-extraction/MyApp.app.

So the first-launch flow isn't "self-extract alongside" — it's delete the outer .app and rename the decompressed one into its place. That's exactly the pattern App Translocation is designed to prevent: TN2206 says a quarantined app gets launched from a read-only randomized mount specifically so it can't modify itself. deleteTreeAbsolute fails on the read-only mount, or renameAbsolute fails with EXDEV across filesystems, and the Zig extractor exits non-zero before the Bun runtime starts. Hence the silent exit.

Fix options, least-to-most invasive

1. Fail loud instead of silent — ~10 lines before L1377. If APPBUNDLE_PATH contains /AppTranslocation/ or starts with /Volumes/, shell out to osascript -e 'display dialog "Please drag MyApp to /Applications before launching."' and exit. Doesn't fix the underlying design but stops the "my app is broken" support tickets.

2. EXDEV fallback — replace renameAbsolute with copy-tree + deleteTree on the extracted dir. Fixes some cross-FS cases but not the translocation case, because the destination (translocated APPBUNDLE_PATH) is still on a read-only mount. Probably not worth the complexity on its own.

3. Skip the whole self-extract on macOS — this is what the issue body already asks for, and IMO the only real fix. The <hash>.tar.zst step is a macOS-specific optimization: on Windows/Linux, the self-extractor has a legitimate job (single-file installer via magic bytes; see extractFromSelf path at L1223–1231). On macOS there's no single-file distribution constraint — the .app is already a directory. Shipping it pre-expanded means:

• extractor doesn't run on first launch at all, so translocation is harmless.
• The codesign signature stays valid for the bundle's lifetime (right now it's implicitly replaced on first launch, which works but is fragile and would also affect stapled notarization tickets if Apple ever tightened checks).
• Patch-based updates via BSDIFF still work — they can target the expanded layout directly.

Concretely for option 3, the CLI path that writes the tarball into Contents/Resources/<hash>.tar.zst on macOS (in package/src/cli/index.ts around the buildAppBundle/packageRelease steps) needs a macOS-specific branch that writes the contents out expanded instead. The launcher binary at Contents/MacOS/<name> would then point directly at the real bun + main.js rather than chaining through the extractor.

Happy to PR option 1 as a stopgap (smallest change, immediate UX improvement) while option 3 is scoped — lmk.