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

[core-code]

1.5.121 was universal, 1.5.122 is not anymore:

%file /Volumes/balenaEtcher\ 1.5.121-universal/balenaEtcher.app/Contents/MacOS/balenaEtcher

/Volumes/balenaEtcher 1.5.121-universal/balenaEtcher.app/Contents/MacOS/balenaEtcher: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64]
/Volumes/balenaEtcher 1.5.121-universal/balenaEtcher.app/Contents/MacOS/balenaEtcher (for architecture x86_64):	Mach-O 64-bit executable x86_64
/Volumes/balenaEtcher 1.5.121-universal/balenaEtcher.app/Contents/MacOS/balenaEtcher (for architecture arm64):	Mach-O 64-bit executable arm64


% file /Volumes/balenaEtcher\ 1.5.122/balenaEtcher.app/Contents/MacOS/balenaEtcher          
/Volumes/balenaEtcher 1.5.122/balenaEtcher.app/Contents/MacOS/balenaEtcher: Mach-O 64-bit executable x86_64

[blitzcaster]

Any news on this? I'm currently stuck at 1.5.121 on MBP M1.

[thundron]

No news yet, see the other issue linked

[core-code]

same with 1.6.0

~ % file balenaEtcher-1.6.0.zip_folder/balenaEtcher.app/Contents/MacOS/balenaEtcher 
balenaEtcher-1.6.0.zip_folder//balenaEtcher.app/Contents/MacOS/balenaEtcher: Mach-O 64-bit executable x86_64
~ % file /Volumes/balenaEtcher\ 1.6.0/balenaEtcher.app/Contents/MacOS/balenaEtcher 
/Volumes/balenaEtcher 1.6.0/balenaEtcher.app/Contents/MacOS/balenaEtcher: Mach-O 64-bit executable x86_64

[thundron]

@core-code does it still open without emulation as some users reported?

[core-code]

@thundron i don't have any ARM Macs to test this. but i fail to see how a binary that only contains Intel code would run without emulation on ARM...

[btwise]

The script with universal parameter should be added to the Makefile

[core-code]

issue persists in 1.7.0

[n0rt0nthec4t]

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

[danielktdoranie]

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?

[nodesocket]

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

[fishcharlie]

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

[thundron]

@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!

[fishcharlie]

@thundron Thanks for the update.

I decided to look into this a little bit, and compared the versions between v1.5.121...v1.5.122.

The only thing that stands out is the resin submodule update: product-os/scripts@d1b05ad...8dfa21c. 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.

[thedocbwarren]

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

[n0rt0nthec4t]

1.73 and STILL no universal binary..

[robd003]

@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.

[danielktdoranie]

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?

[fishcharlie]

@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.

[danielktdoranie]

@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.

And yet we are still without native Apple Silicon support. Last post was over a month ago.

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

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?

[fishcharlie]

@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.

[danielktdoranie]

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.

[nodesocket]

Ok, gentlemen let’s stop the petty bickering. However, Intel Macs are basically end of life and Apple did say it would be a two year transition to Apple Silicon which looks more like three years now. Apple Silicon support is a must have, since I suspect Apple will be sunsetting Rosetta 2 shortly.

Let’s focus on getting the universal binary build working again instead of adding complexity for a dedicated arm64 build.

It should be fairly straightforward to git blame and go line-by-line. Also, look at the 3rd party build tooling to see if they changed any API’s or anything. My concern is perhaps this is not a regression, but intentional. Seems suspicious a regression would remove universal binary support and go unfixed for months. Perhaps running universal binary blocks something balena is currently doing (telemetry) or worse???? I’ll admit my theory is completely unfounded though.

[danielktdoranie]

Let’s focus on getting the universal binary build working again instead of adding complexity for a dedicated arm64 build.

I understand that ultimately that is the best solution for legacy Intel Mac users as well as Apple Silicon users, my thinking was if a stop-gap Apple Silicon native only build could be complied and put on the releases page it would help Apple Silicon users like myself… given we are months in at this stage.

I’d be happy for either a native or universal binary, just don’t want to run Rosetta 2. It’s a memory and battery hog. I have removed it from all of my Apple Silicon Macs.

[thedocbwarren]

Let’s focus on getting the universal binary build working again instead of adding complexity for a dedicated arm64 build.

I understand that ultimately that is the best solution for legacy Intel Mac users as well as Apple Silicon users, my thinking was if a stop-gap Apple Silicon native only build could be complied and put on the releases page it would help Apple Silicon users like myself… given we are months in at this stage.

I’d be happy for either a native or universal binary, just don’t want to run Rosetta 2. It’s a memory and battery hog. I have removed it from all of my Apple Silicon Macs.

I'd be happy to be able to compile myself if the procedure were available.

[robd003]

@thedocbwarren Awesome! Downloading it now, I'll let you know how it goes.

[robd003]

@thedocbwarren Unfortunately I'm getting the same error.

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

[thedocbwarren]

Ok, I'll work on this. I think it's signing. I promise I'll fix this.

[thedocbwarren]

Signing complete. Release 1.7.8 is now signed.

[thedocbwarren]

There appears to be an issue with webpack for mac and linux on arm for 1.7.9. I'm investigating. The build succeed but no output of DMG or AppImage is created.

[thedocbwarren]

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

[mcraa]

Strange @thedocbwarren, there were no changes effecting the mac build.
Only the fix for .deb install.
At the same time it means not having 1.7.9 on mac won't make any mac user miss out on anything, it should be identical to 1.7.8

[thedocbwarren]

Strange @thedocbwarren, there were no changes effecting the mac build. Only the fix for .deb install. At the same time it means not having 1.7.9 on mac won't make any mac user miss out on anything, it should be identical to 1.7.8

I saw that. I'll keep on it and see what could be causing it. I'll check with Debian as well to see what could be the cause. I reviewed the webpack config and didn't see anything that prevents the dist folder from getting created or updated for output.

[thedocbwarren]

Strange @thedocbwarren, there were no changes effecting the mac build. Only the fix for .deb install. At the same time it means not having 1.7.9 on mac won't make any mac user miss out on anything, it should be identical to 1.7.8

Ok, confirmed Debian does not output anything as well.

[thedocbwarren]

Strange @thedocbwarren, there were no changes effecting the mac build. Only the fix for .deb install. At the same time it means not having 1.7.9 on mac won't make any mac user miss out on anything, it should be identical to 1.7.8

I am unable to find where the issue is. Something may be different in the output process -or- something is going wrong in webpack's config to not produce a 'dist' folder. I'm less concerned about 1.7.9, as stated, doesn't do much for non-deb platforms but more for 1.7.10 or later.

[thedocbwarren]

1.7.12 builds fine for MacOS ARM, however like before the build script does not generate a DMG. Could I get new instructions for how to build this correctly?

[nodesocket]

Just installed the latest version 1.7.15 on macOS Ventura, but same thing. Running as intel emulated via Rosetta.

[thedocbwarren]

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

[thedocbwarren]

1.10.0 builds, but produces no package (DMG.) Not sure how to produce to publish a community build for Apple Silicon.

[lurch]

Looks like https://github.com/balena-io/etcher/blob/master/.github/actions/publish/action.yml#L173 might be where the magic happens?

[thedocbwarren]

@lurch What I can see with this (maybe wrong) is it's using GitHub actions to build that, meaning local builds won't produce a DMG. This seemed to be true from 1.7.9 on. I can launch via CLI to run the electron app but not install it. If this is true, I can't build a DMG to publish and they will have to build this officially in their CI.

[thedocbwarren]

I want to add, I saw somewhere those actions are x64 only so that is an issue for ARM. But just to mention, this is open-source and not being able to build and install kind of breaks that and should be corrected. Unless the new procedure is to create a start script and build and run from npm I suppose.

[thedocbwarren]

I have been able to compile recently but no DMG is built. Is GitHub actions the only way to build a DMG with the codebase?

[donluca]

• 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

I'm trying to build an arm64 native build, but I'm encountering this error after doing ./node_modules/.bin/electron-builder :

⨯ The appleIdPassword property is required when using notarization with appleId failedTask=build stackTrace=Error: The appleIdPassword property is required when using notarization with appleId

I don't care about distributing it, I just want it for myself, how can I tell electron to skip notarization?

EDIT: nevermind, I managed to disable notarization myself. Build working correctly on a Mac Mini M2 with macOS Ventura 13.4

[thedocbwarren]

Getting the same error but I can sign with my Developer ID if possible. What is the procedure? I can start building the community Apple Silicon builds again.

[dfunckt]

Closing in favor of #3728

[JordanIdler]

Getting the same error but I can sign with my Developer ID if possible. What is the procedure? I can start building the community Apple Silicon builds again.

afterSignHook.js shows it, you need to set these env variables.

if (electronPlatformName !== 'darwin' || ELECTRON_SKIP_NOTARIZATION === 'true') {
    return
 }

  const appName = context.packager.appInfo.productFilename
  const appleId = process.env.XCODE_APP_LOADER_EMAIL || 'accounts+apple@balena.io'
  const appleIdPassword = process.env.XCODE_APP_LOADER_PASSWORD

So:
export ELECTRON_SKIP_NOTARIZATION=true

[thedocbwarren]

The problem with that is, I want to sign so I can make community builds on macOS for Apple Silicon. If this has to be signed by Balena, than that's game over for Apple Silicon native till they make it happen.

[JordanIdler]

The problem with that is, I want to sign so I can make community builds on macOS for Apple Silicon. If this has to be signed by Balena, than that's game over for Apple Silicon native till they make it happen.

If you look at the code snip-it I provided. You can leave it as true, and provide process.env.XCODE_APP_LOADER_PASSWORD and process.env.XCODE_APP_LOADER_EMAIL if you wish to sign it

[robd003]

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

[thedocbwarren]

Going to give this another try and try to build a signed Apple Silicon build.

[matthewyang204]

I've tried to build an Apple Silicon version of the latest release, it keeps on spitting out errors.