etcher: regression: all releases after 1.5.121 are not 'universal' for both Intel and ARM/AppleSilicon Macs anymore

Why is Balena incapable of building & signing either Universal binaries of Etcher or building x86_64 AND arm64 builds?

Thank you everyone for your patience while we research, understand, and plan a path forward for this open-source project. As pointed out by some commenters, this is a free product, and with the source code provided in this repo, you can certainly build, fix, improve, or iterate a version locally that meets your needs.

As electron builder provides a simple way to build for multiple platforms from one place, native modules can be built only on the same platform as the target. Etcher uses multiple native modules.

To have a working Mac M1 (Arm64) we will either need to replace those native modules, or add an M1 Mac to our build pipeline. The universal build is just packaging the x64 and arm64 together, also doubling the size.

If you are looking to perform a native Arm64 build on your M1, the process would look like:

• Install Xcode
• Git clone this repo
• npm i
• Check if all native modules “node-gyp”-ed correctly … If not go to the folder of the module (inside node_modules) and run electron-rebuild
• npm run webpack
• ./node_modules/.bin/electron-builder
• (no additional parameters are needed, as you are running on the target architecture)
• You output .dmg file will be located in the dist folder

Add me to the issue, when can we expect to have a universal binary back?!>?!?

Same here I can confirm that 1.7.0, as downloaded from https://www.balena.io/etcher/ STILL requires Rosetta 2 to work and is NOT Apple Silicon/M1 native.

What’s the deal here? I understand we had native Apple Silicon support with Version 1.5.121 (1.5.121) support and then it was removed? Why?!

When will it be back?

The Mac Pros are the only Intel Macs left and they’ll be replaced with an M1 counterpart soon enough, even Apple said themselves that they will transition to Apple Silicon completely with in 2 years, and we are only a few months out from that. Also that Mac Pro design was released in December 2019: so yeah as NO NEW Intel macs are being released Intel Mac code is is de facto legacy support.

My comments are no more “unproductive” than your’s: Take your own advice.

Simple solution could be to publish two builds for now (also on homebrew.)

@thundron Thanks for the update.

I decided to look into this a little bit, and compared the versions between https://github.com/balena-io/etcher/compare/v1.5.121...v1.5.122.

The only thing that stands out is the resin submodule update: https://github.com/balena-io/scripts/compare/d1b05ad312e65ea82b1c16b31f5af3c0b5fa2777...8dfa21cfc23b1dbc0eaa22b5dbdf1f5c796b0c2c. Everything else looks completely unrelated to this issue.

So I dug into those changes. The thing that stands out to me is if you search for platforms on that page, I see a lot of changes related to that within the docker/build.sh file. Is that related? Maybe the platforms are excluding Apple Silicon, where before it was undefined so it would build for all platforms? No idea. All questions that I think are above my head at this point, and without digging into why those changes were made, and what some of those variables are set to, it’s difficult to know why things are failing.

Makes me wonder if reverting that submodule update and attempting again, would produce an Apple Silicon build. That would at least narrow things down. But that raises other questions that I’m not sure about, such as: were there behind the scene changes to the CI system where these submodule changes are required now?

I might try to dig into this a bit deeper later on and try to run some of the things myself. But I’m pretty unfamiliar with the CI system here. Loading https://ci.product-os.io/builds/95676, produces a spinning Loading page that never completes. But that doesn’t even look like a recent deployment build necessarily.

However, it sounds like @thundron probably has a lot more context here about what is going on than I do. So I’m not sure me spinning my wheels on it will produce a solid outcome and solve the issue.

Wish I could help more. Really want to support the open source community and get this resolved for everyone (and myself 😉). But @thundron if there is anything else I can do to support this effort, please let me know. Would be happy to try to run some of this locally and debug further, but might need some support in getting pointed in the right direction to get that setup.

ok works perfectly. I will need to enable signing and some other stuff for real releases but it works without any issue on my MacBook Pro 13 M1.

Also, are you open to release contributions for this platform? I’m a founder / maintainer of an opensource project(s) and can build these for you and contribute back.

@danielktdoranie

Last post was over a month ago.

Kinda hard to say this when a LOT of people take a lot of time off during December…

Intel Macs aren’t being made any longer so any Intel code for Macs at this point is by definition legacy support.

This is categorically false. Just because Apple hasn’t released any new Intel Macs, doesn’t mean they aren’t being made any longer. Intel Macs are still being manufactured to this day. And more importantly remain for sale from Apple.

Instead of trying to figure out why the universal binary doesn’t work, why not just release an arm64 Mac version on the Releases page?

Making an educated guess here. The amount of effort that would require would likely be just as substantial as fixing the issue.

---

Remember. This is open source software. Normally I’d be very sympathetic to your case. Pushing companies to stay current with technology is critical.

However, it is open source. You can go and create your own build for native support just fine. No issues. In fact I’ve done that myself.

Or you can spend the time required working to fix or pinpoint the issue yourself.

It’s not like this project has seen a lot of major updates recently and this is just on the back burner. It clearly looks like a resources issue, not a priority issue. Which makes complaining about it unproductive.

Also echoing why native Apple Silicon (Universal) support was lost? Running latest version of Etcher 1.7.1 (1.7.1).

MacBook-Pro ➜ pwd
/Applications/balenaEtcher.app/Contents/MacOS

MacBook-Pro ➜ file balenaEtcher
balenaEtcher: Mach-O 64-bit executable x86_64

Add me to the issue, when can we expect to have a universal binary back?!>?!?

Signing complete. Release 1.7.8 is now signed.

Link to my community build (also shared in other issue.). https://github.com/Augmentedjs/balena-io-etcher-builds/releases/tag/v1.7.7

so 1.7.6 released… STILL NO UNIVERSAL binary back.

Clearly a huge priority for the team

Clearly they don’t give a F*( to fix it and they CAUSED the issue in the first place

so 1.7.6 released… STILL NO UNIVERSAL binary back.

Okay, so still no Native support of Apple Silicon? We had working Apple Silicon support in 1.5.121… what happened? Why was this dropped?

Yes, @nodesocket it needs a native build. I’ll wait for the release storm to finish and I’ll try again to build.

Confirmed, no build produces a package despite successful compile. Tried on x64 as well.

@thedocbwarren Unfortunately I’m getting the same error.

However if you manually run xattr -rc /Applications/balenaEtcher.app then it’ll work.

Thank you @dtischler, @thedocbwarren @fishcharlie, and everyone. Created and pinned issue #3714 , we will update the list with your build @thedocbwarren if you are willing to share.

@thedocbwarren – Excellent work! We are determining the best way forward here, and will report back to you shortly! 😃

so 1.7.6 released… STILL NO UNIVERSAL binary back.

Clearly a huge priority for the team

@danielktdoranie Wasn’t dropped intentionally. See the previous comments. @thundron mentioned that although some CI changes were made, nothing should have impacted Apple Silicon support. Although clearly something did.

I posted a summary of some work I did to pinpoint the issue above.

All of your questions have been previously answered in this thread tho.

@fishcharlie sure! unfortunately there’s not much information yet that we can safely point to as the root cause; there have been some changes to our CI system, but none of those changes should’ve impacted the universal build in any shape or form; moreover, there have been some dependencies updates but again, none of those dependencies/changes were pertaining to the macOS universal package, or the package build at all (if not for how dependencies are packed), so we’re still investigating!

@thundron Could you share the CI build configuration? I think there’s enough motivated people here to get it working again if we can get the details.

1.73 and STILL no universal binary…

@fishcharlie sure! unfortunately there’s not much information yet that we can safely point to as the root cause; there have been some changes to our CI system, but none of those changes should’ve impacted the universal build in any shape or form; moreover, there have been some dependencies updates but again, none of those dependencies/changes were pertaining to the macOS universal package, or the package build at all (if not for how dependencies are packed), so we’re still investigating!

@thundron Any chance you could please provide a status update here? 😃