Universal build fails on non-ARM64 hardware, and M1 target DMG is 'damaged'

[Webreaper]

I've got an app which I build hosted in an Electron container, to give me some native/filesystem interop. It works well.

However, for some reason, if I build the M1/ARM64 version (or a Universal build) on GitHub actions, I get a 'damaged' DMG file (for the ARM64 build) and an odd Javascript/Node error for the universal build:

TypeError [ERR_INVALID_CALLBACK]: Callback must be a function
at makeCallback (fs.js:136:11)
at rmdir (fs.js:671:14)
at Promise (internal/util.js:274:30)
at new Promise (<anonymous>)
at rmdir (internal/util.js:273:12)
at MacPackager.doPack (/Users/runner/work/Damselfly/Damselfly/Damselfly.Desktop/node_modules/app-builder-lib/src/macPackager.ts:123:15)

You can see the build failure for the Universal version here. The ARM64 build completes, but the resulting App fails to start, with MacOS saying it's 'damaged'.

Building locally on my M1 MacBook pro works fine. My hunch is that the GitHub Actions runners aren't MacOS ARM64 hardware, so can't build the M1 versions. But that's weird, because my understanding is that electron-builder should be able to build ARM64/Universal targets on an Intel Mac (as per this issue. I'm sure it used to work about 3-4 weeks ago, and I haven't seen any references to Electron build needing to run on M1 hardware to build M1 targets.

I'm using Electron 11.0.0, electron-builder 22.10.4, node 10.24.1. The OS that I'm running this on is 11.4 beta, on an M1 Macbook pro.

[mmaietta]

Intel-based Macs can still build arm64 versions of your app, and universal builds as well when adding lipo for creating fat universal binaries. electron-builder uses @electron/universal package for accomplishing that.

Re: GitHub action failure. Pretty sure promisify is where it's failing.

electron-builder/packages/app-builder-lib/src/macPackager.ts

Lines 131 to 133 in 6237e67

	const rmdir = promisify(require("fs").rmdir)
	await rmdir(x64AppOutDir, { recursive: true })
	await rmdir(arm64AppOutPath, { recursive: true })

Would you be willing to try node 12? And while you're at it, update to 22.10.5?

[Webreaper]

Thanks. Those upgrades solved the build issue for the Universal binary, so that's one thing solved. However, now I have two binaries - Universal and ARM64 - that both fail to launch, because MacOS thinks they're 'damaged':

“Damselfly” is damaged and can’t be opened. You should move it to the Bin.

Logs here.

[mmaietta]

• skipped macOS application code signing reason=cannot find valid "Developer ID Application" identity or custom non-Apple code signing certificate, see https://electron.build/code-signing allIdentities=

I think Big Sur and/or M1 require signing to be present, otherwise, it'll say it's damaged. Do you have the proper signing identity being provided?

Not sure if the "damaged" issue is occurring for all users or just for your local computer. If the latter, then this could help https://apple.stackexchange.com/a/372208

[nurpax]

The same build steps work for x86 though. At least in my tests, I don’t sign for either x86 or ARM.

In my case I built on x86 mac and shared the dmg to another person who tried it on M1.

[Webreaper]

I think Big Sur and/or M1 require signing to be present, otherwise, it'll say it's damaged. Do you have the proper signing identity being provided?

This is not correct. If you don't sign, the first time you open an app OSX will prompt that it's from an unverified publisher, but you can continue to run it anyway. I've never signed this app, and the x64 version works fine on Intel and M1 Macs. The Universal one is now working too. The M1 version works fine if I build it on my M1 mac, it just doesn't work (and gives the damaged error) if I build it on an Intel mac in Github Action's pipelines, and the M1 build used to work fine through Github, so something changed recently that broke this.

Do you have any anecdotal examples of people who can successfully build arm64 electron apps on Intel Macs?

Not sure if the "damaged" issue is occurring for all users or just for your local computer.

It occurs for all users.

[mmaietta]

Do you have any anecdotal examples of people who can successfully build arm64 electron apps on Intel Macs?

Build for arm64 on an Intel-based mac? I already can on electron-builder 22.10.5 + node 12, been doing so for quite some time now.

[Webreaper]

Yes, I used to be able to do this as well, but something has broken recently (which is, if I may be so bold, why I raised this issue...).

[mmaietta]

Your OP shows version 22.10.4. You say it broke recently, are you reporting an issue for 22.11.1?

[Webreaper]

In my second post I mentioned that I tried the upgrade you suggested in your first. Didn't realise there's an even newer version. I'll try it - are there specific fixes in that ver that are likely to help?

[Webreaper]

Okay, tried with 22.11.1 here: https://github.com/Webreaper/Damselfly/actions/runs/825677557 - if you download the Desktop-Dist.zip, you'll see the Universal DMG works, but the M1 (ARM64) DMG is damaged. Are you able to look at the ARM64 package and see why it's damaged, in case that'll give a clue what's broken in the build?

[mmaietta]

Can you try 22.11.4? We recently updated to use fs/promises re: your original issue.

For the arm64 dmg, are you assembling the dmg on an intel machine or on an arm64 machine?
M1 deprecated HFS+ and must create APFS dmg's, whereas building on an intel machine will still generate HFS+ (maintains backward compatibility)

I don't have access to your build's artifacts because I waited too long to respond to this. If you're able to generate new ones, I'd recommend checking what the filesystem type of the dmg is. That could help isolate where the related electron-builder code would be

[Webreaper]

The universal build works with 22.11.4. I can no longer repro the problem with ARM64 builds, because I've removed it from my project (I only build universal now).

[Billiam]

I'm running into this issue as well with 22.11.7.

Building on github actions in a mac env (which should be using intel), I'm unable to create a non-damaged arm64 build. No issues with non-m1 mac builds.

[alectrocute]

+1. Stuck here currently. Anybody have further advice? Thanks!

[Webreaper]

The only advice I can give is to use github actions to build on a non-M1 host, and/or build universal. That's what I did to workaround it. Hoped the electron team might have fixed it by now though!

[mmaietta]

Would anyone be willing to try this patch on v22.11.10? I'm curious if the M1 devkits had a limitation that the production devices don't (or no longer have).
dmg-builder+22.11.10.patch

diff --git a/node_modules/dmg-builder/out/dmg.js b/node_modules/dmg-builder/out/dmg.js
index 0c479c8..ebf4520 100644
--- a/node_modules/dmg-builder/out/dmg.js
+++ b/node_modules/dmg-builder/out/dmg.js
@@ -173,13 +173,7 @@ async function createStageDmg(tempDmg, appPath, volumeName) {
     if (builder_util_1.log.isDebugEnabled) {
         imageArgs.push("-debug");
     }
-    let filesystem = ["HFS+", "-fsargs", "-c c=64,a=16,e=16"];
-    if (process.arch === "arm64") {
-        // Apple Silicon `hdiutil` dropped support for HFS+, so we force the latest type
-        // https://github.com/electron-userland/electron-builder/issues/4606
-        filesystem = ["APFS"];
-        builder_util_1.log.warn(null, "Detected arm64 process, HFS+ is unavailable. Creating dmg with APFS - supports Mac OSX 10.12+");
-    }
+    const filesystem = ["HFS+"];
     imageArgs.push("-fs", ...filesystem);
     imageArgs.push(tempDmg);
     // The reason for retrying up to ten times is that hdiutil create in some cases fail to unmount due to "resource busy".

[Julusian]

Try running sudo xattr -r -d com.apple.quarantine something.app for your built app.

From what I found when looking into arm builds a few weeks ago is that must be signed or they claim to be damaged. That command above should remove the flag indicating it is untrusted and will allow it to run.

The reason the builds work when produced on M1 is because they were built on that machine. If you were to download the dmg over http, they will also be reported as damaged.

I havent tried universal binaries, so I don't know how they behave.

[Julusian]

For reference, read the first paragraph under 'Code Signing' at https://developer.apple.com/documentation/macos-release-notes/macos-big-sur-11_0_1-universal-apps-release-notes/

[Webreaper]

Mac apps don't need to be signed (it's only a requirement if you're pushing to the AppStore). If you don't sign them, the first time you launch you'll see a dialog confirming you're happy to use an unsigned app, but they don't come up as 'damaged'. I've never signed any of my apps, and they've worked on OSX just fine.

The universal builds that I'm creating also work fine too. So this isn't a code-signing issue; it's a problem with the DMG that electron-build is producing.

[Julusian]

@Webreaper if you read the link I provided, you will see this is no longer the case.
Once I setup signing, apps were no longer 'damaged' and ran fine

[alectrocute]

My issue ended up being @electron/universal improperly lipo'ing native node modules with x64 and x64 instead of x64 and arm64 - resulting in broken arm64 builds. I imagine if I were building on an M1 Mac, I'd have this problem in reverse. I'll make a ticket over on @electron/universal eventually. I also had to use the VSCode team's fork, but that's another story. Spent so many hours on this...

I had to manually create fat modules with lipo for every single module in my project, for example after using electron-rebuild to generate arch-specific binaries:

lipo ./node_modules/sqlite3/bin/darwin-arm64-85/sqlite3.node ./node_modules/sqlite3/bin/darwin-x64-85/sqlite3.node -create -output ./node_modules/sqlite3/build/Release/node_sqlite3.node;

Why is this relevant here? I got an "App is damaged" message and "You do not have permission to open this app" errors while trying to open my Universal app with x64-only .node modules. Could be a clue for someone here looking for an answer if all your apps are signed correctly (verified with codesign -dvvv ./myApp.app).

[alectrocute]

@Webreaper I'm sitting in front of an M1 Mac right now and can confirm without a doubt that codesigning is required. An unsigned app will simply not run. On my Intel Mac, I'm able to still run unsigned apps albeit with a warning dialog. Refer to my comment above perhaps if you're using native modules.

[Webreaper]

I'm sitting in front of my M1 MacBook Pro and my universal builds are running just fine without being signed. My dotnet apps also run fine without being signed. You get prompted to allow them to run, but you can run them.

The only thing I can think is that universal apps don't fall under this signing rule, and the dotnet apps don't count because they're x64 running under Rosetta 2.

When yours don't run, do you get an error saying the apps aren't signed by a verified publisher, or do you get a "damaged DMG" error?

[Billiam]

I'm sitting in front of my M1 MacBook Pro and my universal builds are running just fine without being signed

In the case of a universal build appearing to work, could it be that the m1 machines are running the non-arm version?

[Webreaper]

In the case of a universal build appearing to work, could it be that the m1 machines are running the non-arm version?

How is that possible? If Macos identifies them as universal, it must execute the arm64 package.

[alectrocute]

I'm sitting in front of my M1 MacBook Pro and my universal builds are running just fine without being signed. My dotnet apps also run fine without being signed. You get prompted to allow them to run, but you can run them.

If it’s the same machine you’ve built it on, then AFAIK it’ll let you run it. Try building on a separate machine and then trying running the app on your arm64 MBP - you should then see the error we describe. If not, please let me know.

[jamezrin]

We are still experiencing this issue over at https://github.com/notion-enhancer/notion-repackaged (tracked here notion-enhancer/notion-repackaged#9), if there is anything we can do to help debug this issue, let me know.

[stale]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[Stanzilla]

Still an issue

[arevi]

Experiencing this same issue on my M1 Macbook building an application with electron-builder 23.1.0 on MacOS 12.4

[Kelier]

Still an issue

[jkroepke]

Mention that this issue is not fixable by electron. To avoid this error, you have to code-sign and notarize your application.

To sign and notarize a native M1 application, you have to setup an Apple ID and enter the developer program of Apple (99$/year).

[Webreaper]

If that's the case, how come a universal apple Electron app works just fine? I haven't paid apple anything and have been using a universal app built on M1 without this error since I first reported the issue.

[bojanczyk]

As mentioned by julusian, code signing is different for arm and intel macs. On an arm mac, if an app is not code signed, then the os will claim that the program is "damaged" and want to delete it. (On an intel mac, you will only get a warning that it is unsigned, which you can then overwrite.) If you do not have a pad Apple developer account, you can work around this by using something called "ad hoc" signing, which decorates the program with some kind of empty signature (the hyphen after -s stands for an ad hoc signature):

codesign --force --deep -s - name_of_your_app.app

This will eliminate the "damaged" message on arm macs, and revert to the intel situation, where the user can run the app once they have agreed to use it from an unidentified developer.

This issue is unrelated to GitHub actions.

[divefox]

I fixed this problem by upgrade my mac osx version to 12+

[JerryI]

The problem is that most people are still using an older OSX on M1/2/3. Is there any way to fix this without paying 99$/y to Apple?... Or just force people to update to Sonoma Beta?

[henri9813]

Hello,

Does someone have a fix ?

I'm absolutely not elated to electron, but I have the same issue ( for a Golang app ).

It's very disturbing but this thread is the most advanced one I found.

[JerryI]

Hello,

Does someone have a fix ?

I'm absolutely not elated to electron, but I have the same issue ( for a Golang app ).

It's very disturbing but this thread is the most advanced one I found.

I believe its related more to Apple policy. You may still ship x86 Intel builds, which will run on Apple Silicon with limitations.

I gave up and paid Apple for the license subscription. It solved all issues

[henri9813]

Okay,

Haha alright, thanks, I will ship intel based built.

Best regards

[rahulbansal16]

As mentioned by julusian, code signing is different for arm and intel macs. On an arm mac, if an app is not code signed, then the os will claim that the program is "damaged" and want to delete it. (On an intel mac, you will only get a warning that it is unsigned, which you can then overwrite.) If you do not have a pad Apple developer account, you can work around this by using something called "ad hoc" signing, which decorates the program with some kind of empty signature (the hyphen after -s stands for an ad hoc signature):

codesign --force --deep -s - name_of_your_app.app

This will eliminate the "damaged" message on arm macs, and revert to the intel situation, where the user can run the app once they have agreed to use it from an unidentified developer.

This issue is unrelated to GitHub actions.

@bojanczyk can it be done via windows as well.