First, a big thank you to Moritz for MKVToolNix and for providing macOS GUI builds for so many years. And to everyone in this thread and the build thread who shared fixes and binaries — Miklos, Ryu67, umzyi99, SoCuul, Touchstone64, and others. Your work made this possible.
I’ve set up a repo that builds the MKVToolNix GUI for macOS from the official source:
The latest ARM (Apple Silicon) build is up (MKVToolNix 98.0 with Qt 6.10.2). An Intel build is in progress and should be available soon. The repo includes the build scripts, patches, and automated builds for when new upstream versions are released.
I’m not a professional developer, just a hobbyist who uses MKVToolNix and wanted to give back. These are personal builds, not official and not signed. I’ll do my best to keep them up to date, but if you’re experienced with macOS build issues and want to collaborate, I’d welcome the help. The scripts and patches are all public.
An Intel build is now available alongside Apple Silicon.
Grab the right DMG for your Mac from the latest release.
I did a basic test with each app to ensure that they loaded. I didn’t find any obvious issues traversing the UI. I was able to complete a basic mux on both versions without issues..
Compiler and linker optimizations were also applied to all dependencies, bringing the Apple Silicon app from 84.8 MB down to 72 MB on disk (31.9 MB DMG). Intel comes in at 86.6 MB (39 MB DMG). Both are built with Qt 6.10.2, Boost 1.88.0, targeting macOS 13+.
The build system now includes automated post-build verification (Qt version, architecture of all binaries, duplicate library scan, size check) so these builds are more thoroughly validated than the earlier ones. Previous intermediate releases have been pulled. Only the final verified builds are published.
First — the word “Sentinel” in your translated message is likely “Wächter” in the original, which is macOS Gatekeeper. Just wanted to confirm — are you referring to macOS’s built-in Gatekeeper, or do you have a separate security application called Sentinel installed? The fix depends on which one.
Assuming it’s Gatekeeper (Wächter):
The “damaged” message is macOS blocking the app because it’s not signed or notarized. This is expected for community builds.
The easiest fix is to open Terminal and run:
xattr -cr /path/to/MKVToolNix-98.0.app
For example, if you dragged it to Applications:
xattr -cr /Applications/MKVToolNix-98.0.app
Then open the app again. This removes the quarantine flag that macOS sets on downloaded files.
The build targets macOS 13+ and has been tested on Apple Silicon (M4). Your M1 MacBook Pro on Sequoia 15.7.4 is fully supported.
I think I may have found the issue. The error message you described — “Check with the developer to make sure MKVToolNix-98.0 works with this version of macOS” — is the exact message macOS shows when you try to run an Intel app on an Apple Silicon Mac.
Since you have an M1 MacBook Pro, you need the Apple Silicon download, not the Intel one. There are two files on the release page:
MKVToolNix-98.0-macos-apple-silicon.dmg — this is the one for your M1
MKVToolNix-98.0-macos-intel.dmg — this is for older Intel Macs
I renamed the download from “ARM” to “Apple Silicon” to make it clearer which file is which.
Could you check which file you downloaded? If it was the Intel version, please try downloading the Apple Silicon version instead. I’ve also just updated the build with improved signing which should make the installation smoother.
After downloading, try copying the app to your Desktop first, then run the following command in Terminal instead of using Sentinel — it does the same thing:
I’ve tested the arm version and couldn’t open it because some homebrew dylibs are missing. So not everything needed is inside the app bundle and someone who hasn’t installed homebrew or hasn’t installed the required homebrew package won’t be able to run this. Would be better if everything could be packaged inside the app bundle.
Termination Reason: Namespace DYLD, Code 1, Library missing
Library not loaded: /opt/homebrew//libdouble-conversion.3.dylib
Referenced from: <69CFF4CC-AFB9-35F7-92C4-31A6E22C5813> /Volumes/VOLUME/MKVToolNix-98.0.app/Contents/MacOS/libs/libQt6Core.6.10.2.dylib
Reason: tried: '/opt/homebrew//libdouble-conversion.3.dylib’ (no such file), ‘/System/Volumes/Preboot/Cryptexes/OS/opt/homebrew//libdouble-conversion.3.dylib’ (no such file), '/opt/homebrew//libdouble-conversion.3.dylib’ (no such file)
(terminated at launch; ignore backtrace)
I also encountered the same issue as Adam & Ryu67. Currently running Tahoe 26.4.1 on MBP M1 Pro - both builds from the latest release fail to run on my system. Apple Silicon systems should be able to run both arch variants (it’s the Intel systems that can only run the native variants)
The build that Ryu67 posted a couple of days ago did work for me though.
I did attach the Apple crash reports for both of these builds below (basically same termination reason as Ryu67 mentioned above) - hope you will take a look at this. Thanks!
Thank you for the detailed reports and crash logs. That was very helpful in tracking this down.
I believe the issue is related to how Qt discovers system libraries during the build. It appears that Qt’s configure is finding and linking against Homebrew-installed libraries on my build machine instead of using its own bundled copies. I’m investigating the root cause now and working on a fix.
I’ll post an update once I have a corrected build.
Update:
After further investigation, this appears to be a known macOS packaging issue that affects multiple projects, not just MKVToolNix. The Qt configure in the upstream build script enables pkg-config on macOS (where Qt deliberately disables it by default), which allows Qt to discover and link against Homebrew-installed libraries on the build machine instead of using its own bundled copies.
My build machine has several Homebrew packages (double-conversion, pcre2, zstd, libpng, md4c, freetype) that were pulled in as dependencies of other installs. Qt found those during the build and linked against them, so the app bundle has references to libraries that only exist on my machine. Both builds were affected: the Apple Silicon build links against six Homebrew libraries, and the Intel build links against one (pcre2). If the builds had been done in a clean CI environment, or on a machine without Homebrew, this would never have come up, which is likely why other community builders haven’t run into it.
A good learning experience. Working on a fix now. The approach is to force Qt to use its bundled third-party libraries regardless of what’s installed on the build system. I’ll post an updated build once it’s ready.
Thank you again for the crash reports, Vek239. Those were very helpful in confirming the root cause.
Updated builds are now available: v98.0-b2026.04.3
Thank you to Adam, Ryu67, and Vek239 for reporting the crash. The issue is now identified and fixed.
What happened:
The upstream macOS build script configures Qt with -force-pkg-config -pkg-config, which overrides Qt 6’s built-in macOS safeguard that excludes Homebrew prefixes from library search paths. On machines with certain Homebrew packages installed (double-conversion, pcre2, zstd, libpng, md4c, freetype), Qt links against the Homebrew copies instead of its own bundled versions in qtbase/src/3rdparty/. The app bundle then contains hardcoded references to /opt/homebrew/ paths that don’t exist on other machines, causing the DYLD crash on launch.
This affected every published build. It was never caught because all testing was done on the build machines, which had those same Homebrew packages installed.
The fix:
Two approaches were combined for belt-and-suspenders protection:
Removed -force-pkg-config and -pkg-config from the Qt configure, restoring Qt 6’s default macOS behavior where Homebrew prefixes are stripped from cmake’s search paths
Added -force-bundled-libs to explicitly force Qt’s bundled third-party libraries, and -no-feature-zstd to disable zstd (not bundled by Qt, falls back to zlib)
Both approaches were tested independently on ARM and Intel, then combined. A post-build verification step has also been added that scans every binary in the app bundle for external library references.
Verified in a clean VM:
Tested in a virtual machine with no Homebrew installed. The previous builds (v98.0-b2026.04.1) crash on launch with the DYLD error. The updated builds (v98.0-b2026.04.3) launch and run without issues.
Both ARM and Intel builds have been tested and verified. If you downloaded the previous release, please update. If you run into any other issues, please report back here.
Note: This only applies if you cloned the GitHub repo directly. If you only downloaded the DMG from the releases page, you can ignore this.
Lighter repo clones: LFS dependencies are now opt-in
If you cloned the repo before the recent update, your local copy includes ~534 MB of pre-built dependency archives. These are now opt-in downloads, so new clones are lightweight (~1 MB).
The easiest way to get a clean, lightweight copy is to delete your existing clone and clone fresh. Your local build cache at ~/opt/proven/ lives outside the repo and won’t be affected.
If you have local branches or uncommitted work you want to preserve, there’s a manual cleanup option that keeps your existing clone intact.
Both approaches are documented in the migration guide: docs/lfs-migration.md
For details on pulling pre-built dependencies on demand, see the Build Workflow guide.
I’m not quite sure how to proceed so I’m asking for opinions
I love what @corticalcode has done here but, in parallel, I’ve been developing a different approach: using a clean macOS install, target arm64 only, build everything from source, patch QT as necessary for 26.4.1, code-sign and notarize the app so it passes Gatekeeper.
I’ve not had to make any changes to the packaging/macos scripts other than config.local.sh (for code-signing) but I’ll have to if I’m going to automate notarization.
So, I have a notarized arm64 disk image of release 98.0, ready for testing, but I don’t want to make it look like a competition. The repo is in Github but still in pre-release state until notarization is automated.
Should I just keep the image/repo for personal use or would it be of use to the community?
Genuinely hoping to do the right thing here Thanks for your thoughts!
Thanks for reaching out. A code-signed and notarized build would be awesome, and you should absolutely release it.
I’ve used MKVToolNix for years and relied on mbunkus’s macOS releases. When he stopped providing binaries, I saw that a few people stepped up with their own builds, but I wanted to see if I could compile it myself. To my surprise, it worked, and that was really exciting.
Once I got the bug, it became a personal challenge. Learning the build process, tuning compiler flags, figuring out GitHub Actions and CI/CD. As I said in the original post, this started as a personal build. I figured I should give back what I’d been able to put together, and I wanted to do it in a way that made it easy for people to find and grab.
It sounds like you were on the same path. I just got there a little quicker, but that doesn’t mean the door is closed. I wouldn’t be surprised if there are others with similar ideas too. The real hero here is mbunkus. He develops and maintains MKVToolNix as an open-source project. What you and I are doing is packaging his work and filling a macOS distribution gap he’s no longer able to fill. That’s useful, but it belongs to him, not either of us.
On my end, I’m planning to keep doing both ARM and Intel builds. I’ve been tuning build flags as part of the process, and that’s been half the fun. But there’s plenty of room for our work to coexist or even complement each other. It’s not zero-sum. If one of us doesn’t produce a build, someone else can pick up the slack.
I’m open to talking about collaboration if that interests you. Either way, what you’ve built makes MKVToolNix more accessible on macOS, and that’s the whole point
For what it’s worth: what I did for releases was unlocking the keychain in wich the code-signing key was stored in with something like security unlock-keychain -p … ~/Library/Keychains/login.keychain-db before running the macOS build.sh script. This along with a handful of other maintenance commands that were unique to my actual setup have intentionally not been part of the published build scripts. Unlocking the keychain was enough to make the codesign CLI work.
Absolutely; the code-signing works out of the box, thanks once again
To notarize the app I need to harden the executables (by passing --options=runtime in the codesign command), then xcrun notarytool submit... with a prepared keychain profile and wait for the result. I’ll use an empty NOTARY_PROFILE variable in config.sh, to be overridden in config.local.sh, and only run the extra steps in build.sh when that’s set. I’ll create a pull request once the automation and testing is complete.
Note: This only applies if you cloned the GitHub repo directly. If you only downloaded the DMG from the releases page, you can ignore this.
Thanks for your thoughts!