Electron and Notarization randomly failing.

You can expect that most uploads will be notarised quickly. Occasionally, some uploads are held for in-depth analysis and may take longer to complete. As you notarise your apps, the system will learn how to recognise them, and you should see fewer delays.

Having said that, the problem you’re describing doesn’t seem to match the pattern I’d expect to see. If you post some sample request UUIDs, I’ll do some more digging.

Specifically, I’d like a see a timeline like:

1. Here’s the last request UUID that worked well.

2. Here’s the first one that took a long time.

3. Here’s the first one that worked well again, after updating to the latest Electron.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

1. Last request that worked well:

createdDate: 2025-04-22T17:57:17.900Z
id: b37d6c51-4aca-4ae5-9441-03f61ce31f27
name: xxxxxxxxxxxxxxxxxxxxxx.dmg
status: Accepted

1a) The only difference between this one and id b37...f27 is the version string in the package.json and package-lock.json. And this one failed because it couldn't mount the dmg.

createdDate: 2025-04-22T18:39:47.671Z
id: bbd84685-ac02-4f3a-976e-92e368e8be17
name: xxxxxxxxx.dmg
status: Invalid

1. First one that took a long time. Infact, it's still in progress after a week

createdDate: 2025-04-15T12:40:23.734Z
id: 057bc62e-4cef-4585-ac53-03c035b7615e
name: xxxxxxxxxxxxxxxx.dmg
status: In Progress

1. First one that worked well after updating to the latest Electron

createdDate: 2025-04-15T13:59:13.840Z
id: 9d53d0bc-84b2-48a1-b385-7e1572cb8077
name: xxxxxxxxxxxxxxxxxx.dmg
status: Accepted

Thanks in advance for the help!

Thanks for that.

I suspect you’re hitting a known issue with the notary service (r. 134264492). And that’s quite a coincidence, because I only learnt about this today, and via a completely different channel.

Anyway, I’m working to confirm this suspicion and I’ll get back to you when I know more.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I’ve confirmed that it you are hitting the issue I mentioned yesterday.

I don’t have a lot of info to share about this. As far as we can tell it’s not related to the Electron version per se, but rather to how your app is packaged. And that’s nothing to do with what you’re doing, but an issue on our side.

I would, however, like you to run an experiment. Currently it seems like you’re notarising a disk image (.dmg). I’d like you to try notarising a zip archive (.zip). So, rather than this sequence:

1. Build and sign your app.

2. Put it in a disk image.

3. Sign the disk image.

4. Notarise the disk image.

5. Staple the disk image.

do this:

1. Build and sign your app.

2. Put it in a zip archive. See Packaging Mac software for distribution for the exact command to use.

3. Notarise the zip archive.

4. Staple the app.

5. Put the stapled app into a disk image.

Does that avoid the problem?

Now, I realise this runs counter to the general advice in Packaging Mac software for distribution, so I’m not gonna recommend that as an actual workaround, at least not yet. But it’d still be interesting to know if it avoids the problem.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Our build process that uses electron-builder builds a .zip and a .dmg. The .zip contains the .app. The sign and notarize happens after the build is complete.

I took the zip that contains the .app, and I signed and notarized that. The apple UUID for the notary is 9fea337f-94dd-49bb-9f75-6aeebc904cf3.

I then unzip the zip to get access to the app, and I run the staple command

xcrun stapler staple xxxx.app

The output I get is

Processing: /path/to/output/xxxx.app
Processing: /path/to/output/xxxx.app
The staple and validate action worked!

Then, I create a disk image from the .app by

hdiutil create -srcFolder "/path/to/output/xxxx.app" -o /path/to/output/xxxx.dmg 

//output
...............................................................................................
created: /path/to/output/xxxx.dmg 

This seems to work.

We're running into a different outcome than expected though. When I double click on a dmg, usually, the end user gets a splash screen prompting the user to drag the app to the applications folder. Do you have any instructions to create this splash screen?

Thanks for running that test. I’m glad to hear that it worked the way I expected.

Do you have any instructions to create this splash screen?

There’s no Apple mechanism for setting this up, but it’s a popular option for third-party tools.

Coming back to your main issue, my reading of our bug about this is that you’re submitting a disk image in UDF format. Is that correct?

If so, why is that? It’s… well… unusual, to say the least.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Coming back to your main issue, my reading of our bug about this is that you’re submitting a disk image in UDF format. Is that correct?

If so, why is that? It’s… well… unusual, to say the least

Yes, that is correct. It's a legacy bit of code that we had in place a couple years ago for backwards compatibility.

Do you have a format that would be better recommended?

Do you have a format that would be better recommended?

Yes. Use HFS Plus.

I’m actually surprised that the notary service works with UDF disk images at all. I suspect it’s just an artefact of the implementation. Generally Mac software is distributed on HFS Plus or APFS disk images [1]

So, yeah, my final advice here is that:

• It’s fine to continue distributing your software on a disk image.

• But change that disk image to HFS Plus.

That should avoid this notary service bug, and HFS Plus is a better option in general so I have no qualms about recommending this change.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Well, assuming it’s on a disk image at all. There are, of course, completely different options, like an installer package.