FreeTubeApp
[Feature Request]: Official ARM download for macOS
Guidelines
- [X] I have searched the issue tracker for open and closed issues that are similar to the feature request I want to file, without success.
- [X] I have searched the documentation for information that matches the description of the feature request I want to file, without success.
Problem Description
There is no ARM-based build for macOS at https://freetubeapp.io/#download .
Proposed Solution
Provide an official ARM build for macOS at https://freetubeapp.io/#download .
Alternatives Considered
Adding FreeTube to the macOS app store and offering an ARM-based build there.
Issue Labels
new feature, support for external software
Additional Information
No response
Please see https://github.com/FreeTubeApp/FreeTube/discussions/2771#discussioncomment-3973550
@absidue Thanks for that!
There's one part of the comment that isn't addressed, though: "If not, instead of binary, add it to brew or MacPorts as a source package?" Would that at least be possible?
A lot of my software comes from Homebrew, so I'd be happy to see the ARM version of FreeTube there too. Or is this version there already?
(Also, should I close this issue?)
Homebrew does not compile FreeTube, it fetches and installs the built binaries. A binary that requires Rosetta to run on ARM Macs.
Homebrew does not compile FreeTube, it fetches and installs the built binaries. A binary that requires Rosetta to run on ARM Macs.
Oh, ok, good to know.
"If not, instead of binary, add it to brew or MacPorts as a source package?" Would that at least be possible?
@12people We don't maintain the homebrew or MacPorts packages, if you would like to use source packages, please ask their respective maintainers to add them.
Back to the original proposals in the post, both offering FreeTube on the macOS App Store (would likely get rejected anyway, as it's a 3rd party YouTube client) and providing official macOS arm64 builds involve handing over loads of money to Apple. As arm64 macOS Gatekeeper rejects any apps that weren't built on your machine or aren't signed with a certificate issued by Apple.
Is that good for security? Yes. Does it screw over open source projects? 100%
The current solutions:
- Build FreeTube yourself
- Reach out to those unofficial repositories and ask them to add suport for building FreeTube on your machine (basically number 1 but you don't need to work out how to build it yourself)
- We provide official arm64 builds but have to ask everyone to add a Gatekeeper exception for FreeTube
There's also the possibility of asking Apple for a fee waiver, if there's a trusted maintainer in one of the eligible countries: Australia, Brazil, Canada, China mainland, France, Germany, Israel, Italy, Japan, Mexico, South Korea, United Kingdom, United States.
See Apple's official developer docs page on this for details.
If I'm thinking of the right thing, you can bypass Gatekeeper on a per-app(/binary) basis via the "Open Anyway" button under System Preferences > "Security & Security" that appears after you get the "unidentified developer" pop-up, as detailed by Apple here (under "If you want to open an app that hasn’t been notarized or is from an unidentified developer"): https://support.apple.com/en-us/HT202491
You can bring up the same "Are you sure you want to open [this app]?" dialogue by right-clicking a given unsigned app in Finder and selecting "Open" from the context menu, or by holding ⌃ (control) while launching said app from Launchpad or the Dock (via left-click).
You'll only need to go through said dialogue once, after which (on subsequent launches) the unsigned app will open immediately as any other app would.
Note that you'll have to go through the same Gatekeeper-bypass process after every app update (read: every time the app binary itself is changed).
@unilock Unfortunately, that doesn't work for M1 apps, only for Intel apps.
How about doing what 0 A.D. does: precede the download link with an informational message that one needs to run xattr -cr /Applications/FreeTube.app after installation?
Non-technical users who don't want to ever touch the Terminal could use Intel apps, but power users could easily run this command once and then just use the optimized M1 version.
Maybe also of note, Homebrew has a --no-quarantine flag when installing a cask that automatically removes the quarantine attribute from the installed app. Although it's been said that the Homebrew cask isn't under FreeTube's control.
The command would be:
brew install --cask --no-quarantine freetube
(Or am I trying to solve a different problem? Is the quarantine attribute at all related to having to self-sign the FreeTube binary before it can be launched on Apple silicon...?)
3. We provide official arm64 builds but have to ask everyone to add a Gatekeeper exception for FreeTube
I'm already doing xattr -cr /Applications/FreeTube.app with a few other arm64 macOS apps. A silicon build of FreeTube would be greatly appreciated, even if it was an unofficial build or a fork.
Maybe also of note, Homebrew has a
--no-quarantineflag when installing a cask that automatically removes the quarantine attribute from the installed app. Although it's been said that the Homebrew cask isn't under FreeTube's control.The command would be:
brew install --cask --no-quarantine freetube(Or am I trying to solve a different problem? Is the quarantine attribute at all related to having to self-sign the FreeTube binary before it can be launched on Apple silicon...?)
@unilock Does this work well on apple silicon m1/m2? How does one know the origin/control over a cask/package in brew?
@bencodesall For FreeTube you can check our README, anything listed in the unofficial downloads section is not maintained by the FreeTube team.
The only official downloads for FreeTube are the official website (https://freetubeapp.io), the GitHub releases (https://github.com/FreeTubeApp/FreeTube/releases) and the flatpak (https://flathub.org/apps/io.freetubeapp.FreeTube).
It seems an arm64 build can now be added to the GitHub Action workflow. GitHub made M1 runners available for free for open-source projects: https://github.blog/changelog/2024-01-30-github-actions-introducing-the-new-m1-macos-runner-available-to-open-source/
It would still require a note be added to disable Gatekeeper. But having a pre-built binary would benefit many users and, as mentioned, it would be easy to include —no-quarantine in the Homebrew command (once the cask definition gets updated for arm64).
@toobuntu Unfortunately that won't help here, the problem is that if you want to run an arm64 version of an app on an arm64 Mac, it has to be signed with an Apple developer certificate ($99 a year and I'm pretty sure you need a Mac to even get the certificate in the first place, so that's at least another $600) or built on the same machine that you want to run it on, otherwise gatekeeper will refuse to let it run. As far as I know there is a command you can run to tell gatekeeper to not block it, but you have to run it every single time you download a new version of FreeTube, so for users of the nightly builds that would be a nightmare.
Basically it's a lot easier for everyone to just run the x64 build of FreeTube through Rosetta 2.
Basically it's a lot easier for everyone to just run the x64 build of FreeTube through Rosetta 2.
I fully agree with the ease of running the x64 build through Rosetta 2. However, considering the long-term phase-out of Rosetta 2, I suggest exploring a Homebrew tap solution[^hosting-a-tap]. This tap, hosted by FreeTubeApp, could provide a streamlined way for macOS users on Apple Silicon to download and install the unsigned arm64 binary without manual intervention[^manual-intervention] to bypass Gatekeeper restrictions[^unsigned-apps]. GitHub Actions workflows can automate the tap's cask definition updates on new releases, and hosting the unsigned binary as a release asset in the tap repo should be possible if you don't want to have it in this repo. Thank you for FreeTube, and I respect whatever you decide regarding Apple Silicon support.
[^hosting-a-tap]: A tap can be as simple as a separate GitHub repo named homebrew-FreeTube with two files: README.md and Casks/freetubeapp-freetube.rb. The README could explain to use the --no-quarantine option and why. The existing x64 (Intel) cask hosted by Homebrew would be unaffected and still available for users to install as before.
[^manual-intervention]: Running /usr/bin/xattr -d com.apple.quarantine <path/to/freetube-<version>-mac-arm64.dmg> after every new binary download.
[^unsigned-apps]: Unsigned apps are not allowed in the official Homebrew cask tap, but "fear not. Removal of a cask from the official repositories means we won’t support it, but you can do so by hosting your own tap." (Source)
Question is how to generate arm64 version but not allowing users to download (we want them to use homebrew cask when it's setup to avoid manual step(s)) while there is an URL for downloading for the cask...
@PikachuEXE
So my thought on that was to keep the download out of the main FreeTube repo altogether and instead publish it as a release asset to the new homebrew-FreeTube tap repo.
It would still be possible to download it directly from there, but at least that is a step removed and it wouldn’t be visible among the other release assets here.
The readme for this repo could point those interested in Apple Silicon support to the tap repo, and the tap repo’s readme could explain about using Homebrew with —no-quarantine. (It could also mention that if one does directly download it from the tap repo’s releases, it would be necessary to remove the com.apple.quarantine xattr using a command of the form /usr/bin/xattr -d com.apple.quarantine <path/to/freetube-<version>-mac-arm64.dmg>.
hosting the unsigned binary as a release asset in the tap repo should be possible if you don't want to have it in this repo.
I am excited that you are even considering the self-hosted Homebrew tap suggestion, and am happy to help in any way I can.
Just no idea how to automate the asset building (semi auto is fine) & the cask update It might be fine to do it manually for first few releases (FT has infrequent releases anyway) but prefer automating it (and test it before making it official I got Macbook to test cask changes (https://github.com/PikachuEXE/homebrew-FreeTube
There are several ways to do that, and it depends if you have the cooperation of upstream. One possibility is the Homebrew bump cask GitHub Action or its more recently updated fork. If upstream will use it in their workflow, then it can be used in standard mode to update the cask definition when a new release happens. If not, then it can be used in livecheck mode on a schedule.
For building and uploading the release assets, I suppose the answer is similar. If upstream will do it and has permissions to push a new release to the tap, great. If not, the tap's workflow would have to check for a new release on a schedule and then build, package, release and upload.
We can discuss these further at the tap repo.
Currently I maintain a Homebrew Tap https://github.com/PikachuEXE/homebrew-FreeTube
No idea when an official one would be available (or if would be using a tap as distribution method)
Currently I maintain a Homebrew Tap https://github.com/PikachuEXE/homebrew-FreeTube
No idea when an official one would be available (or if would be using a tap as distribution method)
Thank you 🙏 your version makes a huge difference for Apple silicon users: would be great to see it soon part of normal releases. 🤞
@toobuntu Unfortunately that won't help here, the problem is that if you want to run an arm64 version of an app on an arm64 Mac, it has to be signed with an Apple developer certificate ($99 a year and I'm pretty sure you need a Mac to even get the certificate in the first place, so that's at least another $600) or built on the same machine that you want to run it on, otherwise gatekeeper will refuse to let it run. As far as I know there is a command you can run to tell gatekeeper to not block it, but you have to run it every single time you download a new version of FreeTube, so for users of the nightly builds that would be a nightmare.
Basically it's a lot easier for everyone to just run the x64 build of FreeTube through Rosetta 2.
@absidue
I already have to deal with “FreeTube” cannot be opened because the developer cannot be verified. stuff on the Freetube x64 version on my M3 mac now .. every time I update it I've got to use the option-right-click-open trick to get around it, as it is.
I don't see how providing an official arm binary would make this worse ?
Holding option when selecting open from the context (right click) menu gives this dialog which allows you to grant it a gatekeeper exception:
Thank for PikachuEXE for another build.
I just manually download your macOS ARM builds from https://github.com/PikachuEXE/homebrew-FreeTube/releases and then run xattr -r -d com.apple.quarantine /Applications/FreeTube.app in Terminal, much like I do with LibreWolf browser builds.
@macOS-Mavericks If you got homebrew installed you can just follow the instructions in the README
Back to the original proposals in the post, both offering FreeTube on the macOS App Store (would likely get rejected anyway, as it's a 3rd party YouTube client) and providing official macOS arm64 builds involve handing over loads of money to Apple. As arm64 macOS Gatekeeper rejects any apps that weren't built on your machine or aren't signed with a certificate issued by Apple.
Is that good for security? Yes. Does it screw over open source projects? 100%
The current solutions:
- Build FreeTube yourself
- Reach out to those unofficial repositories and ask them to add suport for building FreeTube on your machine (basically number 1 but you don't need to work out how to build it yourself)
- We provide official arm64 builds but have to ask everyone to add a Gatekeeper exception for FreeTube
Even the Intel one gives me a Gatekeeper pop-up, so I'm a little confused on this. I built an arm64 version and didn't get a Gatekeeper notice since I've already allowed the app.
@aileks If you can afford to build locally it might be the most flexible way (to include additional changes for example) macOS does not care about apps built locally thus there is no popup which is also a benefit
Yea I think now that even the Intel one warns there’s no reason not to have an official Apple silicon build that’s no worse from an install perspective ?