Background
libonnxruntime.dylib (universal2, ~67MB) currently ships bundled as a .app resource (Contents/Resources/onnxruntime/libonnxruntime.dylib), fetched at build time by src-tauri/scripts/fetch-onnxruntime.sh and loaded at runtime via ORT_DYLIB_PATH.
During the v0.8.12 release work we hit a notarization failure because Tauri signs the main binary + .app shell but not this nested dylib, so Apple rejected the archive ("The binary is not signed"). Fixed in the release workflow by codesigning the dylib (Developer ID + hardened runtime + secure timestamp) before tauri build.
This issue tracks a possible future optimization: download the dylib on-demand (first run / onboarding) instead of bundling it, to slim the initial download by ~67MB.
Important caveat — this does NOT remove the signing requirement
The app uses hardened runtime. Loading a third-party, unsigned dylib at runtime is blocked by library validation unless either:
- the dylib is signed with our Team ID (same signing problem we have today), or
- we add the
com.apple.security.cs.disable-library-validation entitlement (weakens the security posture).
So on-demand download trades a one-line CI signing step for: a download manager, progress UI, integrity/checksum verification, first-run network dependency (hurts offline UX), updater/version-sync handling, and likely still signing or a weakened entitlement.
Recommendation
Keep bundle + sign for now (already shipping). Only pursue on-demand download if initial download size becomes a real pain point. A better-scoped variant of this idea is optional/on-demand model downloads (the ONNX models, not the runtime), which is a cleaner product decision.
Acceptance criteria (if pursued)
Filed while debugging the v0.8.12 macOS release signing/notarization pipeline.
Background
libonnxruntime.dylib(universal2, ~67MB) currently ships bundled as a.appresource (Contents/Resources/onnxruntime/libonnxruntime.dylib), fetched at build time bysrc-tauri/scripts/fetch-onnxruntime.shand loaded at runtime viaORT_DYLIB_PATH.During the v0.8.12 release work we hit a notarization failure because Tauri signs the main binary +
.appshell but not this nested dylib, so Apple rejected the archive ("The binary is not signed"). Fixed in the release workflow by codesigning the dylib (Developer ID + hardened runtime + secure timestamp) beforetauri build.This issue tracks a possible future optimization: download the dylib on-demand (first run / onboarding) instead of bundling it, to slim the initial download by ~67MB.
Important caveat — this does NOT remove the signing requirement
The app uses hardened runtime. Loading a third-party, unsigned dylib at runtime is blocked by library validation unless either:
com.apple.security.cs.disable-library-validationentitlement (weakens the security posture).So on-demand download trades a one-line CI signing step for: a download manager, progress UI, integrity/checksum verification, first-run network dependency (hurts offline UX), updater/version-sync handling, and likely still signing or a weakened entitlement.
Recommendation
Keep bundle + sign for now (already shipping). Only pursue on-demand download if initial download size becomes a real pain point. A better-scoped variant of this idea is optional/on-demand model downloads (the ONNX models, not the runtime), which is a cleaner product decision.
Acceptance criteria (if pursued)
.appdisable-library-validation)Filed while debugging the v0.8.12 macOS release signing/notarization pipeline.