Apple’s notarytool can’t handle ZIP64 files

In short: if you have any file in your app (or whatever it is you’re trying to get Apple to sign) that is over 4 GiB, you must use a disk image (DMG) to package it for notarytool, not a zip file.

This is because support for files larger than 4 GiB requires using the “ZIP64” zip file format, which would be fine except Apple’s notary servers can’t handle them. If you give them such a zip file, you’ll see notarytool fail something like this:

$ xcrun notarytool submit "MyScreenSaver.saver.zip" --apple-id user-id --team-id team-id --verbose --wait --password lovesecretgod
[02:33:46.871Z] Debug [MAIN] Running notarytool version: 1.1.0 (39), date: 2026-07-13T02:33:46Z, command: /Applications/Xcode.app/Contents/Developer/usr/bin/notarytool submit MyScreenSaver.saver.zip --apple-id user-id --team-id team-id --verbose --wait --password private<String>
Conducting pre-submission checks for MyScreenSaver.saver.zip and initiating connection to the Apple notary service...
[02:33:46.943Z] Info [PREFLIGHT] Confirmed that MyScreenSaver.saver.zip (4.61 GB) is likely a PKZip file.
[02:33:46.943Z] Debug [PREFLIGHT] Finished completing determination of file type for MyScreenSaver.saver.zip. Operation took 71ms.
…
[05:09:56.690Z] Info [API] Preparing GET request to URL: https://appstoreconnect.apple.com/notary/v2/submissions/some-uuid?, Parameters: [:], Custom Headers: private<Dictionary<String, String>>
[05:09:56.690Z] Debug [AUTHENTICATION] Using cached token value for app-specific password request: team-id:user-id
[05:09:56.691Z] Debug [AUTHENTICATION] Authenticating request to '/notary/v2/submissions/some-uuid' with WebServices Token. AppleID: user-id, Team ID: team-id, Token: private<String>
[05:09:56.692Z] Debug [TASKMANAGER] Starting Task Manager loop to wait for asynchronous HTTP calls.
[05:09:57.115Z] Debug [API] Received response status code: 200, message: no error, URL: https://appstoreconnect.apple.com/notary/v2/submissions/some-uuid?, Correlation Key: some-key
[05:09:57.115Z] Debug [TASKMANAGER] Completed Task with ID 37 has received a parsable response.
[05:09:57.116Z] Debug [TASKMANAGER] Ending Task Manager loop.
[05:09:57.116Z] Info [API] Received new status: Invalid
Current status: Invalid....................................
[05:09:57.116Z] Info [API] Submission in terminal status: Invalid
Processing complete
  id: some-id
  status: Invalid
[05:09:57.138Z] Debug [CTXMGR] Removed temporary directory: Optional(file:///var/folders/v3/6w91zvg53dqgh_3fl858wtrh0000gn/T/TemporaryItems/NSIRD_notarytool_36y4rY/)

If you check the log, you’ll see absolutely nothing useful:

$ xcrun notarytool log --apple-id user-id --team-id team-id --password lovesecretgod some-uuid
{
  "logFormatVersion": 1,
  "jobId": "some-uuid",
  "status": "Invalid",
  "statusSummary": "Archive contains critical validation errors",
  "statusCode": 4000,
  "archiveFilename": "MyScreenSaver.saver.zip",
  "uploadDate": "2026-07-13T05:02:27.652Z",
  "sha256": "cbafd582f7b3221af5f2930b9a97019da5275116610c46ad3874e7b392fd7196",
  "ticketContents": null,
  "issues": [
    {
      "severity": "error",
      "code": null,
      "path": "MyScreenSaver.saver.zip/MyScreenSaver.saver/Contents/MacOS/MyScreenSaver",
      "message": "The signature of the binary is invalid.",
      "docUrl": "https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/resolving_common_notarization_issues#3087735",
      "architecture": "x86_64"
    },
    {
      "severity": "error",
      "code": null,
      "path": "MyScreenSaver.saver.zip/MyScreenSaver.saver/Contents/MacOS/MyScreenSaver",
      "message": "The signature of the binary is invalid.",
      "docUrl": "https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/resolving_common_notarization_issues#3087735",
      "architecture": "arm64"
    }
  ]
}

The ‘help’ URLs it links to are useless, since the problem is an outright bug in Apple’s infrastructure, not the input binary or bundle. Indeed, Apple’s own tools confirm this:

$ codesign -vvv --deep --strict /Users/me/Documents/MyScreenSaver.saver 
/Users/me/Documents/MyScreenSaver.saver: valid on disk
/Users/me/Documents/MyScreenSaver.saver: satisfies its Designated Requirement

The only workaround I’ve been able to find is to package within a DMG instead.

For the record, Apple, this is a stupid error on your part. 😡 While trying to figure out what the hell was actually going on, I spent multiple hours scouring the web, and experimenting, to no avail. It took Claude Fable 5 a couple of hours too, but it finally cracked it.

It’s especially irritating that I was only using zip files as a workaround for a design flaw in Apple’s notarytool, whereby it won’t accept the app bundle directly. And it’s Apple themselves that recommend using zip files specifically.

And lastly, it’s flabbergasting that this problem exists given that ZIP64 was first released & publicly documented in 2001. It’s 25 years later – why aren’t Apple supporting it?! How did they even find a zip library that doesn’t support it? Did they write their own specially just to remove support for it? I cannot fathom how they’ve created this problem.