Hello, We are currently using Apple Notarization (notarytool) for distributing a macOS app, and we are experiencing very long notarization times for large app bundles.
[Issue]
For apps with large binary sizes, notarization consistently takes around 3.5 to 4.5 hours from submission to completion.
This delay is causing practical issues in our release pipeline, especially when:
- A hotfix or urgent update is required
- Multiple builds must be notarized in a short time
- CI/CD-based distribution is expected to complete within a predictable timeframe
[Environment]
- Platform:
macOS - Notarization method:
notarytool - Distribution:
Outside Mac App Store - App size:
100 GB~(compressed ZIP) - Signing:
Hardened Runtime enabled,codesigned correctly - Submission status: Successfully accepted, but processing time is very long
[What we have confirmed]
- The notarization eventually succeeds (no failures)
- Re-submitting the same build shows similar processing times
- Network upload itself completes normally; the delay is in Apple-side processing
- Smaller apps complete notarization much faster
[Questions]
- Is a 3–4+ hour notarization time expected behavior for large macOS apps?
- Are there recommended best practices to reduce notarization processing time for large binaries?
- For example, splitting components, adjusting packaging, or specific signing strategies
- Is there any official guidance or limitation regarding notarization queueing or processing based on app size?
- Are there known service-side delays or regional differences that could affect processing time?
Any insight or confirmation would be greatly appreciated, as this directly impacts our production release workflow.
Thank you.
Notarising very large products can take a while. I usually advise folks to approach this in two steps.
The first step is to separate upload time from notarisation time. This is relatively straightforward:
- Use
notarytool, without the--waitoption, to upload your product. - Make a note of when that finishes.
- Wait for the notarisation to complete.
- Compare the upload time to the overall notarisation time.
I regularly see situations where the upload time dominates the notarisation time. If that’s the case then there’s a different path to follow.
However, in this case it sounds like you’ve already done this test and determined that the bulk of the delay is after the upload. Given that, there’s a couple of things to do.
The first is to file a bug against the notary service. I’ve seen cases where there’s something specific about the product that’s causing the notary service to enter a pathological state.
In your bug report, make sure to include:
- A request UUID showing the problem.
- The evidence you have confirming that for this specific request the upload wasn’t the problem.
Once you’re done, please post your bug number.
The second step is about mitigation. In my experience it’s rare to have product that contains 100 GB of code. Rather, most products like this contain a huge number of resources. This preponderance of resources over code is super common in games, but I’ve seen it crop up in other product types as well.
If that’s the case for you then you can use that to help mitigate this issue. There are two parts to that:
- Day-to-day notarisation, for example, when you distribute your app to in-house testing
- Notarising a distribution release that you plan to ship widely
For day-to-day notarisation you can extract your product, notarise the product without resources, and then recombine them. The exact way you do this depends on your product type. For example, in a standard app (.app) you can’t jam the resources back into the .app bundle because that will break the seal on the app’s code signature. Instead you might create a separate resources-only bundle, which doesn’t need to be notarised, and have your app access that explicitly. This usually requires some futzing, but it’s perfectly feasible.
Note One common pitfall here is Gatekeeper path randomisation, aka app translocation. See App Translocation Notes for more on that.
The situation with distribution releases is a bit more nuanced. Our general advice in this front is to notarise your whole product. Hence this comment in Packaging Mac software for distribution:
If you distribute your product using nested containers, only notarize the outermost container.
The day-to-day notarisation approach runs counter to that advice, and that’s fine because you can get away with more when releasing to a limited audience. In contrast, distribution releases go to a wider audience and you should think about whether it makes sense to follow our general advice for those releases.
However, that’s not an absolute requirement. Indeed, in some cases it might make sense to follow a completely different path. A lot of this depends on your distribution channel. Some channels have explicit support for distributing resources separately from code. Apple has specific support for this in the Background Assets framework, but your distribution channel might have other options.
IMO it’s generally best to work on this backwards: Come up with a plan for your distribution notarisation and then use that to inform your day-to-day notarisation. That should help you avoid last-minute problems when you go to distribute you product.
Finally, if you have follow-up questions about any of of this stuff, just reply here with the details.
Just following up to kindly request an update on this issue.
I recommend that you have a read of Quinn’s Top Ten DevForums Tips, and specifically tip 3.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
