I’ve noticed that the mkvtoolnix-app Homebrew cask is marked as deprecated as it (currently) fails Gatekeeper checks. We could fix that with my notarized app/image but by definition that’s a more restricted distribution than mkvtoolnix-app, so it would need to become an ‘mkvtoolnix-gui-arm’ cask or similar.
To me that feels like splintering off into distributing too many platform-specific options, but if I’ve got this right, when Apple drops Rosetta we’re going to need two binaries anyway: ‘mkvtoolnix-gui-arm’ and ‘mkvtoolnix-gui-intel’ (or similar). So maybe we could think about this now and get everything in place.
Unfortunately the only Intel Mac I own can’t go beyond Catalina (10.15) so I can’t create and notarize an Intel build of MKVToolNix GUI (which currently supports macOS 13.x and later).
I think we might be able to put together a plan for MKVToolNix GUI to survive beyond the retirement of Rosetta, and for ease of use Homebrew seems like a good choice for distribution, but for that we need notarized builds (so we get past Gatekeeper).
Any thoughts? I’m old and could well be just talking nonsense
Thanks @XeFire that is one fascinating rabbit hole
As it happens I need to keep my Intel Mac running as is for other reasons, but I’ll poke around and see if there are any other hardware options, keeping OCLP in mind
I think the 2018 Mac Mini is the oldest Intel Mac that can run macOS 15 ‘clean’. The cheapest I’ve found on eBay so far is about £200, which might be a bit excessive for a hobby project.
So, for MKVToolNix on macOS I’ve been thinking about what to distribute and how to distribute it.
Looking into how, I’m talking with Homebrew about replacing the mkvtoolnix-app cask with the notarized build, but there are complications: (1) it’s an unofficial build, and (2) it’s Apple-Silicon-only. So the how may heavily influence the what.
To address the Apple-Silicon-only issue I’m investigating the creation of a universal binary. I can’t create an Intel build with my hardware, and cross-compilation (building for example an Intel release on an Apple Silicon Mac) is a bigger task than I have the resources to complete. Some of the libraries used cause more headaches than others. (See for example this GTK cross-compiling glib article.)
I believe notarization is still key for end-user acceptance; it uses Apple’s automated service to check signed binaries for malicious content and code-signing issues. @mbunkus has been signing his macOS binaries for years but notarization was less of an issue for those releases. Newer versions of macOS are more stringent.
Ideally we’ll be able to create a signed and notarized universal binary ‘blessed’ (Homebrew’s phraseology) by @mbunkus so it can simply take the place of the mkvtoolnix-app cask and be fit for all Mac users. There are quite a few hurdles before getting to that stage though.
I’ll keep this thread up to date with investigations, and would welcome any thoughts or comments on these ideas
Thanks for doing the work. I’ll gladly give my blessing if you’re willing to somewhat commit to keeping up with providing the macOS releases. My development speed and thereby frequency of releases have slowed down over the last couple of years, so don’t expect more than eight releases per year, I’d guess.
I didn’t plan on renewing my Apple developer membership, and therefore I won’t be able to sign anything myself anymore (well, that and the fact that I don’t have a working mac anymore, soooo…). Meaning I can give my verbal/written blessing but not cryptographically sign DMGs. Just to be clear.
That’s very generous @mbunkus, thanks! I’m happy to keep on top of releases, and I’m sure there’ll be more discussions to come before everything’s ready
Exciting news: a notarized, universal binary of 98.0 is running just fine in ‘native’ mode on Tahoe 26.4.1. The same app, launched via Rosetta 2, also appears to be completely stable. Just a lot slower to load
Many thanks to @corticalcode for patiently creating and testing the Intel builds that are supporting these proof-of-concept tests.
Hi @mbunkus, a quick question if I may. Homebrew are keen for a cask’s content to be hosted in the same domain as the project’s home page. This would mean hosting the universal macOS releases alongside your earlier releases.
I can arrange alternative hosting, but before I do I thought it best to ask whether you’d be willing to host the new releases in the same location?
And while I’m here, would you prefer me to use some other form of comms for these kind of questions instead of the forum?
I kind of expected as such. I’m fine with hosting it on my end. I’ll set up an account on my SFTP server where you can upload new builds. Let’s continue this via email, please. I’ll send you my preferred address via direct message here in the forum.
Well, it was an interesting exercise, and the end result may turn out to be of use somewhere, but Homebrew casks can “…deliver specific versions of artifacts depending on the current macOS release or CPU architecture.”
Another step towards the end-goal: I’ve acquired an Intel Mac Mini which I’ve installed from scratch and it just served up my first notarized Intel MKVToolNix package
It takes around three times longer than my Apple Silicon Mac to create a clean build but it means the first arm64/x86_64 package pair is just around the corner
It’s done! Please see this post for details and downloads.
Also, I’ve renamed the repo I was using for arm64 releases as it now covers building all ‘MKVToolNix for Mac’ packages and also includes the tools used to create universal binaries. It’s now called package-mkvtoolnix-for-mac and release 1.3 is available including the MKVToolNix 98.0 revision 1 package artefacts
The next task is to start on the Homebrew cask code so it can serve the right binary for each user
Thanks again for your help 
