Apps like LibreWolf and FreeTube are to be deprecated in 2026-09-01

[nafarinha]

Output of brew config

HOMEBREW_VERSION: 4.6.0-45-gdbe68ef
ORIGIN: https://github.com/Homebrew/brew
HEAD: dbe68ef80ce1faefddddbade2029c610c6fba3f4
Last commit: 2 days ago
Branch: main
Core tap JSON: 10 Aug 13:33 UTC
Core cask tap JSON: 10 Aug 13:33 UTC
HOMEBREW_PREFIX: /usr/local
HOMEBREW_CASK_OPTS: []
HOMEBREW_DISPLAY: /private/tmp/com.apple.launchd.qY8S8QJhZS/org.xquartz:0
HOMEBREW_EDITOR: nano
HOMEBREW_MAKE_JOBS: 4
HOMEBREW_NO_AUTO_UPDATE: set
HOMEBREW_NO_UPDATE_REPORT_NEW: set
HOMEBREW_SORBET_RUNTIME: set
Homebrew Ruby: 3.4.5 => /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/3.4.5/bin/ruby
CPU: quad-core 64-bit broadwell
Clang: 16.0.0 build 1600
Git: 2.50.1 => /usr/local/bin/git
Curl: 8.7.1 => /usr/bin/curl
macOS: 14.7.4-x86_64
CLT: 16.2.0.0.1.1733547573
Xcode: N/A

Output of brew doctor

Please note that these warnings are just used to help the Homebrew maintainers
with debugging if you file an issue. If everything you use Homebrew for is
working fine: please don't worry or file an issue; just ignore this. Thanks!

Warning: Some installed casks are deprecated or disabled.
You should find replacements for the following casks:
  freetube
  gstreamer-runtime
  librewolf
  usbimager

Warning: Some installed formulae are deprecated or disabled.
You should find replacements for the following formulae:
  icu4c@76

Warning: You have the following deprecated, official taps tapped:
  Homebrew/homebrew-bundle
  Homebrew/homebrew-services
Untap them with `brew untap`.

Warning: The following formulae have the same name as core formulae:
  cryfs/tap/cryfs
  mas-cli/tap/mas
Their taps are in use, so you must use these full names throughout Homebrew.

Warning: You have booted macOS using OpenCore Legacy Patcher.
We do not provide support for this configuration.

This is a Tier 2 configuration:
  https://docs.brew.sh/Support-Tiers#tier-2
You can report Tier 2 unrelated issues to Homebrew/* repositories!
Read the above document instead before opening any issues or PRs.


Warning: Unbrewed dylibs were found in /usr/local/lib.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae and may need to be deleted.

Unexpected dylibs:
  /usr/local/lib/libCMDServices.1.0.0.dylib
  /usr/local/lib/libcrypto.3.dylib
  /usr/local/lib/libcurl.4.dylib
  /usr/local/lib/libfontconfig.1.dylib
  /usr/local/lib/libfreetype.6.dylib
  /usr/local/lib/libjpeg.62.dylib
  /usr/local/lib/libopenjp2.2.4.0.dylib
  /usr/local/lib/libpng16.16.dylib
  /usr/local/lib/libpoppler.129.dylib
  /usr/local/lib/libpteidapplayer.2.0.0.dylib
  /usr/local/lib/libpteidcardlayer.2.0.0.dylib
  /usr/local/lib/libpteidcommon.2.0.0.dylib
  /usr/local/lib/libpteiddialogsQT.2.0.0.dylib
  /usr/local/lib/libpteidlib.2.0.0.dylib
  /usr/local/lib/libpteidlibj.2.0.0.dylib
  /usr/local/lib/libpteidpkcs11.2.0.0.dylib
  /usr/local/lib/libssl.3.dylib
  /usr/local/lib/libtiff.6.dylib
  /usr/local/lib/libxerces-c-3.2.dylib
  /usr/local/lib/libxml-security-c.20.dylib
  /usr/local/lib/libzip.5.5.dylib
  /usr/local/lib/pteidlib_dotnet8+.dylib

Warning: Unbrewed header files were found in /usr/local/include.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae and may need to be deleted.

Unexpected header files:
  /usr/local/include/eidErrors.h
  /usr/local/include/eidlib.h
  /usr/local/include/eidlibException.h
  /usr/local/include/eidlibcompat.h
  /usr/local/include/eidlibdefines.h

Warning: You have unlinked kegs in your Cellar.
Leaving kegs unlinked can lead to build-trouble and cause formulae that depend on
those kegs to fail to run properly once built. Run `brew link` on these:
  libpng
  [email protected]
  openssl@3
  ollama

Description of issue

I noticed that casks like LibreWolf and FreeTube are being deprecated starting September due to being unsigned? If this is correct, and partially agreeing (solely as a user, not a developer) that this is due to security, it still feels wrong to remove apps for this reason without giving homebrew users an option and instead trying to force the app devs to get an Apple developer license. If indeed someone would like to fully use Apple's security implementations, why would that person even install homebrew in the first place, where the install method is copying and pasting a shell script from the internet in the terminal? I hope that homebrew devs could consider if there is a more user-friendly approach instead of deprecating apps.

[daeho-ro]

AFAIK,

1. We are rejecting unsigned apps already for new registrations.
2. Keeping unsigned apps is only for the intel based macOS users.
3. Signing is required to run on silicon based macOS.
4. Apple announced that macOS 26 Tahoe will be the last version of macOS to support Intel-based Macs.
5. No more unsigned apps after this phase.

[OliverGuy]

@SMillerDev do you have any sources on that ?
For now they have made it harder to run unsigned apps using the UI, but I have not seen any news of the xattr bypass going away.

[SMillerDev]

@SMillerDev do you have any sources on that ?

On them making unsigned apps harder to use? It's visible when looking at macOS over the years.

For now they have made it harder to run unsigned apps using the UI, but I have not seen any news of the xattr bypass going away.

That just tricks gatekeeper into trusting a binary like it was compiled on your device. It doesn't allow unsigned code, it tricks the system into believing it doesn't need any protection.

[OliverGuy]

I understand your point, even if I don't agree with it.
In fact, I'd argue that removing those trusted, known apps is a greater security risk, as users will need to manually check for updates themselves.
Making the installation fail without the --remove-quarantine flag (for as long as it works) would IMO be a softer way to deprecate them.

[p-linnane]

The bottom line is that these applications do not comply with the built-in security mechanisms of macOS. Anyone is free to create their own Tap and add whatever software they want to it. We are simply no longer going to offer applications in our official repositories that require reducing OS-level security to run.

[Wowfunhappy]

Signing is required to run on [apple] silicon based macOS.

Did Apple recently change something I'm not aware of?

I know that from the start, Apple Silicon has required binaries to be signed with a signature, but since that could be an ad-hoc signature this struck me as more of an implementation detail of the binary format than a significant policy shift. Otherwise, as far as I was aware the requirements were the same for both Intel and Apple Silicon based Macs. To the extent running ad-hoc signed apps reduces security, it's the same on both platforms.

[carlocab]

If you are using these apps, then it would be a lot more helpful for you to contact the developers yourself to request that they provide signed builds of their apps. They're much more likely to respond positively to a request from a user than from us.

[p-linnane]

Thankfully the FreeTube homebrew cask was added and is maintained by the community, so if it gets taken off homebrew it's not a big deal for the project.

It will be removed after the deprecation cycle is complete. For the sake of your users, I hope you and your team are starting to plan for the eventual wind down of macOS support for FreeTube.

Just noting this here in case any FreeTube users stumble upon this thread, it's not possible for us to provide signed builds, due to Apple's limitations.

That's a pretty disingenuous statement. You're able to provide signed builds, you are simply choosing not to. Naturally, you are under no obligation to do so as a FOSS project. However, you do have to be ready for your macOS users to have an increasingly poor experience until your app no longer even runs on the platform.

We are simply starting to warn users that that day is coming.

[absidue]

Not exactly sure what kind of year long plan you are expecting for winding down an open source cross-platform Electron app, that doesn't rely on any servers run by the project, that stores all your data in plain text files on your own computer, which can already be imported into other similar programs. There are also many alternatives to FreeTube that do pretty much the same thing or people can just switch back to using YouTube directly.

It would definitely be nice if Apple provided alternatives to doxxing yourself (the irony of having to doxx oneself to keep a privacy friendly application going is not lost on me) and buying a very expensive piece of hardware to use one single time and then paying a yearly ransom, just so a few very vocally ungrateful users can keep using the program.

[p-linnane]

I'm not expecting anything. I don't use your software. But since you commented in a discussion for a project where I hold a leadership role, I took the time to respond.

To be clear: Apple's Developer Program is not "doxxing". Choosing to register under a public Developer ID for software distribution is not remotely the same as having private information exposed against one's will. Calling it "doxxing" is hyperbolic and misleading, and continuing to frame it that way feels deliberately disingenuous.

I don't disagree that the requirements are burdensome, especially for FOSS projects. I'd also prefer a more equitable, privacy-respecting model. But I don't work for Apple. I have a day job, and I help maintain Homebrew. My only intent was to gently encourage you to do your macOS users a favor by letting them know FreeTube will not keep working on the macOS platform.

Whether or not you choose to provide signed builds is entirely your prerogative. But framing that choice as victimization is a disservice to your users, and diminishes the very real harm of actual doxxing.

[absidue]

As we clearly do not see eye-to-eye on this topic, I'll leave you and the homebrew project in peace.

[p-linnane]

For what it's worth, I genuinely appreciate your civility here. I wish more discussions could be handled this way. I hope for nothing but the best for you and the FreeTube project.

[SMillerDev]

why would that person even install homebrew in the first place, where the install method is copying and pasting a shell script from the internet in the terminal?

Or running a signed and notarised installer, or manually extracting the git repo. Security minded people have plenty of options to install and use Homebrew.

[nafarinha]

Thanks @carlocab and @daeho-ro for your replies. I wasn't aware that on Apple silicon macOS app signing was mandatory (you correctly guessed I'm on an Intel-based). But considering macOS 26 will be officially supported for a bit more, if feasible, it would be welcomed to delay the deprecation of similarly affected casks, at least for the Intel-based macos still on the wild. In the end, I guess this is one extra nudge towards my linux migration in the short term.

[ThatIsAPseudo]

formulae.brew.sh/analytics/homebrew-os-arch-ci/30d vs formulae.brew.sh/analytics/homebrew-os-arch-ci/365d shows a clear decline in intel macs though.

Indeed, which does not mean one should push toward its deprecation IMHO, i'd rather keep the legacy systems usable for as long as possible. I'd like to be able to boot a 2015 mac on big sur and just run Homebrew to install a bunch of apps (well, the last versions that work)

[p-linnane]

You're not considering the maintenance burden here. Intel hardware is not sold anymore. CI times are dramatically longer on x86_64 compared to arm64. Apple has announced that Tahoe will be the last macOS to support Intel. The writing is on the wall. We cannot invest more and more time and money to support a platform that is coming to the end of its supported life. To do so would be damaging to the Homebrew project, and a disservice to the majority of users on supported platforms. We have this same conversation every year when we drop a version of macOS. This is just on a larger scale.

We have already stopped building all formulae on every x86_64 platform starting with Sequoia. This will continue with Tahoe. Anaconda also recently announced they are dropping Intel package support: https://www.anaconda.com/blog/intel-mac-package-support-deprecation.

Homebrew's goal is not to provide extensive support to legacy systems. Our goal is to provide the latest versions of software on supported platforms. Other package managers, like MacPorts, provide many more packages for legacy versions of macOS. If you plan to stay on Intel macOS, you should probably begin planning for what that will entail.

[xtqqczze]

But considering macOS 26 will be officially supported for a bit more

Apple only considers products obsolete after more than 7 years since they stopped distributing them for sale, so Intel-based Macs will be supported by Apple into 2030.

[p-linnane]

Apple only considers products obsolete after more than 7 years since they stopped distributing them for sale, so Intel-based Macs will be supported by Apple into 2030.

This is for hardware support and repairs. It has nothing to do with software support.

[gromgit]

Summary table of macOS versions support: https://endoflife.date/macos