Skip to content

Comments

fix(macos-app): patch SwiftPM Bundle.module accessor for app bundle#3337

Open
skymoore wants to merge 2 commits intoopenclaw:mainfrom
skymoore:fix/macos-app-patch-swiftpm-bundle
Open

fix(macos-app): patch SwiftPM Bundle.module accessor for app bundle#3337
skymoore wants to merge 2 commits intoopenclaw:mainfrom
skymoore:fix/macos-app-patch-swiftpm-bundle

Conversation

@skymoore
Copy link

@skymoore skymoore commented Jan 28, 2026

fix(macos-app): patch SwiftPM Bundle.module accessor for app bundle compatibility

Problem

SwiftPM's auto-generated resource_bundle_accessor.swift files use Bundle.main.bundleURL.appendingPathComponent(...) to locate package resource bundles. This resolves to .app/Package_Target.bundle at the app root.

However:

• macOS app bundles put resources in .app/Contents/Resources/
• Code signing prohibits arbitrary files/symlinks at the app root
• This causes EXC_BREAKPOINT crashes when packages like Textual try Bundle.module.url(forResource:) (e.g., prism-bundle.js for syntax highlighting)
Crash trace:

Thread 0 Crashed:
0 libswiftCore.dylib _assertionFailure
1 Clawdbot closure #1 in variable initialization expression of static NSBundle.module
2 Clawdbot CodeTokenizer.init()

Solution

After the first swift build (which generates accessors), patch all resource_bundle_accessor.swift files:

  • let mainPath = Bundle.main.bundleURL.appendingPathComponent("textual_Textual.bundle").path
  • let mainPath = (Bundle.main.resourceURL ?? Bundle.main.bundleURL).appendingPathComponent("textual_Textual.bundle").path

• Falls back to resourceURL first (correct for .app/Contents/Resources/), then bundleURL (development builds)
• Rebuilds with patched accessors
• No upstream changes needed
Changes

• scripts/package-mac-app.sh: Add double-build + sed patching step
• Works for all arches, all packages (Textual, SwiftUIMath, ClawdbotKit, etc.)
• Minimal overhead (~1-2s rebuild)
Testing

  1. BUNDLE_ID=dev.rwx.ai.bot ./scripts/package-mac-app.sh
  2. Copy to /Applications/ → launches without crash ✅
  3. Syntax highlighting works (uses Prism.js from Textual bundle) ✅
  4. Codesign verifies ✅
    Before/After

Development (swift run)
• Before: ✅
• After: ✅

Packaged .app
• Before: 💥 Crash on startup
• After: ✅ Launches + full functionality

Codesign
• Before: ✅
• After: ✅

Fixes #1709 (#1709) (Textual/CodeTokenizer crash).

Closes: #1709
Type: Fix
Scope: macos-app, swiftpm

Greptile Overview

Greptile Summary

This PR updates scripts/package-mac-app.sh to patch SwiftPM-generated resource_bundle_accessor.swift files so Bundle.module resolves resources via Bundle.main.resourceURL inside a signed .app bundle (instead of bundleURL at the app root). The script now performs an initial swift build per-arch to generate accessors, rewrites the accessor code via sed, then rebuilds and continues packaging by copying resource bundles (including adding SwiftUIMath’s bundle) into Moltbot.app/Contents/Resources.

Confidence Score: 3/5

  • Mostly safe to merge, but the build-step error handling could mask failures and produce flaky packaged apps.
  • The change is localized to a packaging script and aligns with macOS bundle resource layout, but the new swift build ... || true can let the script proceed without actually generating/patching accessors, making failures harder to diagnose and potentially reintroducing the crash at runtime.
  • scripts/package-mac-app.sh (new build+patch loop and error handling)

(2/5) Greptile learns from your feedback when you react with thumbs up/down!

Context used:

  • Context from dashboard - CLAUDE.md (source)
  • Context from dashboard - AGENTS.md (source)

@openclaw-barnacle openclaw-barnacle bot added the scripts Repository scripts label Jan 28, 2026
Copy link
Contributor

@greptile-apps greptile-apps bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

1 file reviewed, 1 comment

Edit Code Review Agent Settings | Greptile

@greptile-apps
Copy link
Contributor

greptile-apps bot commented Feb 3, 2026

Additional Comments (1)

scripts/package-mac-app.sh
[P0] Ignoring the first swift build failure can silently leave accessors unpatched and produce a broken app.

Because the first build is ... || true, if generation fails (missing deps, wrong toolchain, transient SwiftPM error), the patch loop will find nothing and the second build will run anyway; you’ll only find out later at runtime. Consider removing || true or explicitly failing if no resource_bundle_accessor.swift files were found/patched for the target.

Prompt To Fix With AI
This is a comment left during a code review.
Path: scripts/package-mac-app.sh
Line: 132:132

Comment:
[P0] Ignoring the first `swift build` failure can silently leave accessors unpatched and produce a broken app.

Because the first build is `... || true`, if generation fails (missing deps, wrong toolchain, transient SwiftPM error), the patch loop will find nothing and the second build will run anyway; you’ll only find out later at runtime. Consider removing `|| true` or explicitly failing if no `resource_bundle_accessor.swift` files were found/patched for the target.

How can I resolve this? If you propose a fix, please make it concise.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

scripts Repository scripts

Projects

None yet

Development

Successfully merging this pull request may close these issues.

voice-call plugin: config validation ignores environment variables

1 participant