Using a smaller version of the app that didn't include the main content packs the app needs to ultimately run, I was able to create an app at around 1GB in size. This successfully was able to be sent to notarization and be successfully notarized. I looked back at our last submission, which was on Mar 4, 2022, and it turns out we were using altool at the time for submission and notarization. It would seem that notarytool has a regression that you're already aware of in this regard. How can we work around this to get our application notarized?

@Quinn -- Thank you so much! We reverted to using altool and were able to successfully notarize our application for our update build. We should be good at this point. As requested, I filed a bug about notarytool (FB12080461)

I have been testing variations of our setup for the past couple of days, and have a little more information to report back -- in some way, this seems to be account specific. We have several accounts added in Xcode on the build server. Some have access to one developer account, some have access to many. We finally managed to get a few builds to succeed: (App A) One build succeeds by using an account that is logged in on Xcode. (App B) One build succeeds ONLY if the -authenticationKeyPath (and related args) are supplied, and no accounts with access that project exist in Xcode. (Said another way: the same command will begin failing when I add any account with access to the app we're uploading, and begin succeeding the moment those accounts are removed from the preference pane.) A few thoughts: The Developer Team that fails for the "App B" example above is fully paid for, and has all outstanding agreements signed. This machine was upgraded from macOS 13 -> 14, and also upgraded from Xcode 14 -> 15. I'll be looking into seeing what is necessary to "factory reset" Xcode in an attempt that some latent data from the Xcode update is causing the issue.