[Feature Request]: Official ARM download for macOS #2786
Comments
|
Please see #2771 (reply in thread) |
|
@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. |
Oh, ok, good to know. |
@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:
|
|
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"): 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 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 The command would be: (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...?) |
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. |
@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 |
|
@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. |
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 solution1. 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 intervention2 to bypass Gatekeeper restrictions3. 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. Footnotes
|
|
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... |
|
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
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 |
|
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. |
|
Any updates? |
|
Currently I maintain a Homebrew Tap 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. 🤞 |
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: |
|
is there an easy how-to to building this locally ? @PikachuEXE mentioned the Readme.. but I don't see build instructions there? @absidue : Considering gatekeeper pops up on both Arm and x86 builds .. there's really no reason not to automate the official arm builds at this point, unless i'm missing something ? |
|
Earlier this year, I made a script to build and install FreeTube on Apple Silicon. Below is a simplified version of it. (The original leveraged Homebrew to inform me of version updates.) I have since stopped using the script and switched to using the Homebrew tap. Dependencies are #! /bin/ksh
set -o errexit
set -o nounset
set -o pipefail
#
# Script to build FreeTube for Apple Silicon
# As of 14 Feb 2024, the FreeTube Homebrew cask installs an Intel build, which requires Rosetta 2 to run on Apple Silicon.
#
# Dependencies:
# yarn
# jq
#
# License: GPLv3+
typeset repo_dir="$HOME/devel/github/FreeTube-build-environment"
# Build the application in a development area of the filesystem
# Remove existing directory if it exists
if [ -d "$repo_dir" ]; then
printf "Removing existing directory: %s\n" "$repo_dir"
/bin/rm -rf "$repo_dir" || { printf 1>&2 "Error: Failed to remove existing directory.\n"; exit 1; }
fi
# Get the tag name of the most recent non-draft release
typeset tag_name="$(/usr/bin/curl --silent --url "https://api.github.com/repos/FreeTubeApp/FreeTube/releases?per_page=10" | jq -r '.[0] | select(.draft == false) | .tag_name')"
# Clone the repository at the extracted tag
if git clone --branch "$tag_name" https://github.com/FreeTubeApp/FreeTube "$repo_dir"; then
printf "Repository cloned successfully to: %s\n" "$repo_dir"
cd "$repo_dir" || { printf 1>&2 "Error: Failed to change directory.\n"; exit 1; }
else
printf 1>&2 "Error: Failed to clone the repository."
exit 1
fi
# Install build dependencies
yarn install --frozen-lockfile || { printf 1>&2 "Error: Failed to install build dependencies.\n"; exit 3; }
# Configure Electron Builder to generate only the macOS application bundle (.app) without additional packaging.
sed -i '' "s/targets = Platform.MAC.createTarget(\[[^]]*\], arch)/targets = Platform.MAC.createTarget(\['dir'\], arch)/" _scripts/build.js
# Build macOS .app bundle
yarn build:arm64 || { printf 1>&2 "Error: Failed to build macOS .app bundle."; exit 4; }
# Alternatively: npm run build:arm64 || { printf 1>&2 "Error: Failed to build macOS .app bundle."; exit 4; }
# Quit the application if running prior to installing it
/usr/bin/osascript <<EOF
tell application "System Events"
if (name of processes) contains "FreeTube" then
tell application "FreeTube" to activate
repeat until frontmost of process "FreeTube" is true
delay 0.1
end repeat
keystroke "q" using command down
end if
end tell
EOF
# Uninstall an existing version if present in /Applications
/usr/bin/sudo /bin/rm -rf /Applications/FreeTube.app
# Install the Apple Silicon build to /Applications
{ /usr/bin/sudo /bin/cp -RL build/mac-arm64/FreeTube.app /Applications && \
/usr/bin/sudo /usr/sbin/chown -R root:wheel /Applications/FreeTube.app; }
# Check for errors after installation to /Applications
if [ $? -eq 0 ]; then
printf "FreeTube built and installed successfully.\n"
else
printf 1>&2 "Error: An unexpected error occurred during the installation process.\n"
exit 1
fi
# Inform the user about the potential delay for Spotlight to reflect the new version
printf "Spotlight might take some time to rebuild its index and reflect the new version of FreeTube.\n"
# Offer to open FreeTube
read -r -n 1 -t 5 var?"Open FreeTube now? (This helps Spotlight index the new version.) [y|n] " < /dev/tty
printf "\n"
case "$var" in
[Yy]) open -a "/Applications/FreeTube.app" ;;
*) printf "Installation of FreeTube is complete. You can open it later by locating it in your Applications folder.\n" ;;
esac
# Print a goodbye message
printf "All done. Exiting...\n" |
|
If the x64 version requires a Gatekeeper pop-up and the press-Command-open trick (which it does) on macOS arm64, I don't get how compiling an arm64 version provides any different of a user experience as x64 binaries. Why are we conflating the two issues? Gatekeeper behaves similarly with the version being published by the project today, so there's no reason not to provide arm64 builds. I literally just installed the x64 build of FreeTube on an arm64 macOS system, and Gatekeeper behavior was identical to the user experience we seem heavily concerned about here. What is the perceived difference between providing an x64 binary and an arm64 binary for arm64 macOS users? Because if it is Gatekeeper, there is no difference. |
The difference from my understanding at least is that Gatekeeper is a lot stricter for arm64 binaries on arm64, so the "press-Command-open" trick doesn't work, instead you have to run a command in your terminal every time you download a FreeTube binary. |
|
Maybe the right solution is that we provide arm64 macOS builds but only if the people in this thread agree provide support for the users that struggle with the arm64 macOS builds. Of course if you don't hold up your end of the bargain we could always stop providing arm64 macOS builds from that point onwards... |
|
Or we just ship a README_TO_USE.txt file in the arm64 builds with the following text: |
|
I'm confused I use pika's homebrew tap, and have never needed to run anything from the terminal after an update. I might make more sense to advise people to either use homebrew or follow the following instructions |
|
@lil5 If you followed the instructions in the README of that homebrew tap you would have passed the |
|
@psiberfunk The main issue with your idea is that people are highly likely to forget to run it after an update, especially if they aren't particularly technical. Even if we stick it in the README, on the website near the download button, in the docs and in the release notes of every future release we do, people will still forget and come and complain about it not working. So if you are willing to personally handle any issue or discussion that anyone opens about that in the future, ideally without us having to remind you about it, then sure we can add an arm64 macOS build to the release. TL;DR You want us to do something that will cause more support burden and seem to be expecting us volunteers to just happily do more work because of you, when there are already ways to get an arm64 macOS build. |
|
So, I think we have this problem no matter what we do, we already have to tell people to right click and open… And Apple is inevitably going to apply this same gatekeeper stuff to all binaries. So we need some sort of solution that is easier to use that helps people install this With a minimal number of ways to go down the wrong path … I swear I’ve seen something like this with a installer package or scripted solution .. I’ll Have to start digging, but we have to confront this reality sooner or later. in the meantime, do you know how universal binaries are treated? That’s potentially a stopgap solution? |
Probably the same, as universal apps are just the x64 and arm64 binaries glued together and macOS just picks the appropriate slice from the binary (so yes they are double the install size), although someone with a mac would have to test that. |
I’ll test if if you can throw a universal build at me somewhere ? |
|
Another thought , make the arm64 builds available but make people look on GitHub for them via an extra click or two that makes them realize they need special instructions for now ? |
|
I am completely lost with this ongoing debate. I dig FreeTube, but I opt to download and install my stuff manually, not through Homebrew. LibreWolf has had a faq about applying Apple silicon attributes and for me, since I'm a manual kind of guy, I cut and paste the terminal command after each update. https://librewolf.net/installation/macos/ |
To put it simply there's a debate over whether to make it easy to get an ARM/Apple-Silicon build for most people even though that means they'd need to go through some extra steps to use it. Most people arn't quite handy enough to build it themselves, and relying on forks and downstream ports is a bit clunky and potentially offers a path for bad actors to exploit for malware insertion. |
The homebrew tap is maintained by one of the FreeTube maintainers, so if you are that worried about them adding malware, you should probably stop using FreeTube from the upstream repository too. |
We could do it for the nightly builds, that way most people wouldn't use them. But then all of you would be even more mad because we would only be doing it for the nightly builds. Basically at this point it comes down to whether @psiberfunk is going to agree to pick up the inevitable extra support burden. |
I'm not sure that's a good idea for a wide variety of reasons, but I do think we ought to figure out a way to mitigate this issue which is inevitably coming for regular binaries too. It's not great to rely on x86 translation as the offering for mac users when you can produce the arm binaries as it both consumes more power and is just kicking the can down the road. The nightlies would be better than nothing certainly... and you could bury the ARM version at first to see how much support issues it actually creates at first. I don't really see how people needing to read instructions to right click and hold option is any different than the terminal dance.. they're both more or less the same level of hassle. |
|
What about a one-double-clickable shell script that does all this for the user ? I'm thinking something like this in the DMG : |
|
While I personally use and recommend the Homebrew Tap, not everybody wants to use Homebrew. You could test the waters by updating the README to point people to the Homebrew Tap, or, as mentioned above, its releases page (which mentions the quarantine issue and provides a link to learn how to remove it). It can be interesting to see how other projects deal with this issue. I just came across this method from I suppose, in addition to updating the README, it could be added to the issue template with a link to https://support.apple.com/en-us/102445#openanyway. Because if someone landed there, they didn't handle it in Terminal. |
|
Well, this is now a problem for everyone running the latest macOS. As of Sequoia , the problem applies to both intel and ARM binaries, as far as I can tell: https://arstechnica.com/gadgets/2024/09/macos-15-sequoia-the-ars-technica-review/17/#h1 "In macOS Sequoia, users will no longer be able to Control-click to override Gatekeeper when opening software that isn’t signed correctly or notarized," the brief note reads. "They’ll need to visit System Settings > Privacy & Security to review security information for software before allowing it to run." The right-click/control-click option for easily opening unsigned apps is no longer available. Users who want to open unsigned software will now need to go the long way around to do it: First, try to launch the app and dismiss the dialog box telling you that it can't be opened. Then, open Settings, go to the Privacy & Security screen, scroll all the way to the bottom to get to the Security section, and click the Open Anyway button that appears for the last unsigned app you tried to run. The time has come .. we've got to deal with the same problem for all macOS users now. |
|
Why not give people the choice - a this-is-dead-but-easy-to-use-x86-rosetta-osx and a osx-arm64 build. I can chose what's best for me, don't make a 2 year discussion out of it. |
This install script rocks, after testing it out. I think it's the best solution offered so far. |
Is it for homebrew arm version or manual installation by running the script? |
|
The script psiberfunk created is for people who manually download and install PikachuEXE's builds - https://github.com/PikachuEXE/homebrew-FreeTube/releases . Hoping to see v0.22.0 Beta for silicon soon. I've got to ask, is there a macOS mainstream audience downloading and using FreeTube, since it isn't in the Mac App Store. Only the hardcore geeks will know how to navigate around Sequoia macOS 15 hand-holding (aka Windows Vista UAC). At least someone already figured out a means to get around Sequoia's screen capture permissions - https://goodsnooze.gumroad.com/l/amnesia . |
|
To be fair, does anyone who self-describes themselves as having no "computer skills" use this application? |
I personally just don't see not having notarization being an issue if we explain to the end user who we assume has "no computer skills" that it's just Apple being unjust and backing out of their deal to keep macOS "open". |
Couldn't agree more 👍 |
Same here. |
and others
Guidelines
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
The text was updated successfully, but these errors were encountered: