macOS Intel bundle fails to launch (missing Swift runtime) — upstream menuinst/feedstock fix

[hiroalchem]

Summary

The official macOS Intel (x86_64) bundled app fails to launch on a clean Intel Mac:

dyld: Library not loaded: @rpath/libswiftCore.dylib
  Referenced from: /Applications/napari (0.7.1).app/Contents/MacOS/napari-071
  Reason: image not found

Reproduced with napari 0.7.0 and 0.7.1 Intel installers. Apple Silicon bundles are
not affected.

Root cause (upstream)

Contents/MacOS/napari-071 is menuinst's Swift appkit_launcher. It links the Swift
runtime (libswiftCore etc.) non-weak via @rpath. The launcher source ships with a
/usr/lib/swift RPATH, but conda package binary relocation strips that RPATH when
the menuinst conda-forge package is built, so the shipped launcher can't locate the OS
Swift runtime on Intel. (Apple Silicon is fine: arm64 dyld resolves Swift from the dyld
shared cache without the RPATH.)

• Analysis / issue: macOS Intel bundles fail to launch: binary relocation strips /usr/lib/swift RPATH from appkit_launcher conda/menuinst#507
• Fix: Disable binary relocation to preserve /usr/lib/swift RPATH on macOS launchers conda-forge/menuinst-feedstock#62 (build.dynamic_linking.binary_relocation: false)

Why this matters for napari

napari's macOS installers are built via conda constructor + menuinst, so all Intel
bundles are currently unlaunchable. Once the fixed menuinst package is published,
napari/packaging needs to pick it up and rebuild the Intel installers (and ideally
re-release 0.7.x Intel artifacts).

Environment

• macOS 13.7.8 (22H730), Intel (MacBookPro14,1), x86_64
• napari 0.7.0 and 0.7.1 official macOS Intel installers

Workaround for affected users (until a fixed build ships)

Re-add the RPATH to the bundled launcher (do not rename the .app — the launcher
locates its wrapped app by bundle name):

APP="/Applications/napari (0.7.1).app"
sudo install_name_tool -add_rpath /usr/lib/swift "$APP/Contents/MacOS/napari-071"
sudo codesign -f -s - "$APP/Contents/MacOS/napari-071"

[TimMonko]

Thank you for the report @hiroalchem!
@psobolewskiPhD and @jni are you able to have more insight on this? I don't know what menuinst is for, to start with

[psobolewskiPhD]

Menuinst is part of our bundle stack, should be documented here: https://napari.org/stable/developers/coredev/packaging.html

I don't have an Intel mac to test, but it sounds plausible?
That said, arm64 macs were introduced Fall 2020 and Intel is being fully dropped in the next macOS release as far as I know.
Maybe @jaimergp can take a close look at the issues and the fix?

[jaimergp]

I believe this was addressed by conda-forge/menuinst-feedstock#62

[jni]

Nice! Thanks @hiroalchem! @jaimergp, so, what is the fastest way to replace the intel bundles for 0.7.0/0.7.1? Is it "just" a matter of running this action with the two tags, and then updating the artifacts on the GH release?

btw, this bit in the docs linked by @psobolewskiPhD can be updated now, right? 😃

On Windows, any Microsoft-blessed certificate will do. […] Right now, we simply reuse the Apple certificate just to sign the installer with something.

[hiroalchem]

@jni careful — re-running the action today likely won't fix the Intel bundles yet.

I built a 0.7.1 osx-64 .pkg with menuinst 2.5.1 (#62) and checked it on an Intel Mac (macOS 13.7.8): the env's …/menuinst/data/appkit_launcher_x86_64 has /usr/lib/swift, but the deployed …/napari (0.7.1).app/Contents/MacOS/napari-071 still has only @loader_path/../.. — so on x86_64 it can't resolve @rpath/libswiftCore.dylib (the same failure as the original report). That deployed launcher matches the one embedded in the conda-forge conda-standalone (which bundles menuinst 2.1.2), so the shortcut seems to be built from conda-standalone's frozen menuinst, not the 2.5.1 in the env.

conda-standalone-feedstock also pins menuinst =2.5.0, and the rpath fix only landed in 2.5.1. So I think the order is:

1. Bump conda-standalone to menuinst ≥ 2.5.1 and rebuild it.
2. Then re-run the bundle action + update the release artifacts.

Otherwise step 2 alone re-ships the same broken launcher. (arm64 is unaffected — dyld resolves Swift from the shared cache without the rpath.) I'm still finishing an on-hardware launch check, but the rpath chain points here. cc @jaimergp

[TimMonko]

@hiroalchem I just want to make sure to go out of my way to say WOW and thanks for the excellent debug and tracking of this all down. Your effort is super appreciated ❤️

[jaimergp]

conda-standalone was rebuilt on July 1st (see https://conda-metadata-app.streamlit.app/?q=conda-forge%2Fosx-arm64%2Fconda-standalone-26.5.2-hfb368cc_1.conda), and carries menuinst-2.5.1-py313h6fa1262_0.conda, so I think we are ok! (Check Raw Json > rendered_recipe > finalized_dependencies > build > resolved)

[jaimergp]

Also locally:

$ pixi exec --with conda-standalone bash
(pixi:temp:conda-standalone) [~/Downloads/] $ cd $CONDA_PREFIX
(pixi:temp:conda-standalone) [~/Library/Caches/rattler/cache/cached-envs-v0/bash-de59d9687d34e62d] $ cd standalone_conda/
(pixi:temp:conda-standalone) [~/Library/Caches/rattler/cache/cached-envs-v0/bash-de59d9687d34e62d/standalone_conda] $ ./conda.exe python
Python 3.13.13 | packaged by conda-forge | (main, Apr  8 2026, 02:31:45) [Clang 19.1.7 ] on darwin
Type "help", "copyright", "credits" or "license" for more information.
(CondaStandaloneConsole)
>>> import menuinst
>>> menuinst.__version__
'2.5.1'

[hiroalchem]

Thanks @jaimergp — I checked the July 1st build and I don't think Intel is fixed yet.

Verified (binary inspection):

osx-64 conda-standalone-26.5.2-h8b077d2_1 does bundle menuinst 2.5.1, but the /usr/lib/swift rpath from #62 is missing on its frozen launcher:

• appkit_launcher_x86_64 in the published menuinst-2.5.1 package: LC_RPATH = /usr/lib/swift, @loader_path, … ✅
• same launcher as frozen inside conda-standalone: LC_RPATH = @loader_path/../.. only ❌

$ otool -l .../menuinst/data/appkit_launcher_x86_64 | grep -A2 LC_RPATH   # extracted from conda-standalone 26.5.2 h8b077d2_1
          cmd LC_RPATH
         path @loader_path/../.. (offset 12)

That matches the broken rpath on the deployed napari-071 launcher, and it links @rpath/libswiftCore.dylib non-weak, so x86_64 still can't resolve it.

My interpretation (not yet confirmed):

PyInstaller likely rewrites the launcher's rpath while freezing (@loader_path/../.. is its usual rewrite), dropping /usr/lib/swift. If so, the menuinst bump is necessary but not sufficient: re-running the bundle action today would re-ship the same broken Intel app, and conda-standalone would need to keep (or re-add) /usr/lib/swift on the frozen launcher. arm64 is unaffected (Swift resolves from the shared cache), which is why version checks on arm64 pass while the x86_64 launcher stays broken.

I'm still finishing the on-hardware launch check on an Intel Mac.

[hiroalchem]

Update: confirmed on hardware and fix submitted.

On an Intel Mac (macOS 13.7.8), I clean-installed a 0.7.1 osx-64 build embedding the July 1st conda-standalone-26.5.2-h8b077d2_1 (frozen menuinst 2.5.1, verified via sha256):

1. Fresh install → launcher has LC_RPATH = @loader_path/../.. only → dyld: Library not loaded: @rpath/libswiftCore.dylib (abort). So rebuilding the bundles today would still ship broken Intel apps.
2. install_name_tool -add_rpath /usr/lib/swift + ad-hoc re-sign → napari launches ✅

The stripping happens when PyInstaller freezes menuinst inside conda-standalone (it removes all rpaths from the launcher template and adds a bundle-relative one). Fix submitted: conda/conda-standalone#291 — once that lands and the feedstock rebuilds, re-running the bundle action should produce working Intel apps. cc @jaimergp

[hiroalchem]

Verified: conda/conda-standalone#291 (merged) fixes this end-to-end. I built a 0.8.0 osx-64 installer using that PR's CI artifact (conda-standalone-26.5.3-g356c85d) and clean-installed it on the same Intel Mac (macOS 13.7.8): the deployed launcher keeps /usr/lib/swift and napari launches with no manual fix.

The fix isn't in a published conda-standalone build yet, so napari osx-64 bundles built with the currently available conda-forge package remain affected. I've asked upstream about a post-release or an interim feedstock patch (conda/conda-standalone#291). Once a fixed build is available — and the bundle workflow picks it up — re-running the action should produce working Intel apps.