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.