I also just installed Xcode 11 on my MacBook Pro 2013: exactly the same problem.Xcode 11 is unusable on any machine.

40 GB RAM300 GB free space

Thanks Quinn,In the end, John Daniel suggested the simplest solution: that I don't actually need to unzip anything (you can see posts at the bottom).This eliminates the possibility of the original signed app to be altered in any way.After running altool, I can delete the zip file and staple the original signed app.Thanks again for taking the time to look into this issue.Leo

> Please use the command-Line tool "man" in the Terminal.app to review usage of the "ditto" tool.I've been using ditto for many years - and, like I mentioned, do use it to automate notarization.My point is that if zipping is necessary to authorize the app, then Apple tools should do this - and whatever else is needed - under the hood. Developers should not have to be deeply and intimately involved in every minutia of the notarization process.> There is no unzipping step. When you notarize a zip file, you are notarizing the app it contains. > It is not practical to upload an app bundle which is just a complex directory tree. You are only zipping for uploading. > After uploading, you delete the zip. Then you staple the app.Well that's indeed some very important and helpful info!When I read it first, it took me time to understand how is it if I'm notarizing the app that zip archive contains I then can delete the zip file that contains the very app I just notarized.But then it nudged me to realization that altool does not notarize the actual physical app bundle I'm uploading - but an abstract idea of that bundle. Which, in turn, allows me to delete the zip file with very app bundle that altool just notarized. And to staple the original signed app that was never in fact notarized by altool.I'm grateful for this clarification.With that, my position remains the same: that all these misunderstandings happen exactly due to the way notarization is implemented (and documented).Leo

Thanks for the detailed answer, John.> So eliminate that step. Problem solved.I don't see how I can eliminate unzipping. If there is a way, I'll be glad to learn about it.Anyway, I respectfully disagree with your views on automation:> I've never understood this desire to automate notarization.Manual notarization might be acceptable if you have a single app which you update once a month, if even.Like I mentioned, I have multiple apps that I update often.Manual notarization involves many repetitive, tedious tasks and is a huge waste of time and resources. Repetitive, tedious tasks are:-counter-productive, and-degrading the quality of human life.It's never acceptable for people who respect their time - be it notarization or otherwise.Fortunately, Apple understands this and does provide developers with tools to automate the process. For which I can only be grateful - even though it doesn't fix the major principal flaws of the notarization process.> I have yet to see a single one of these notarization threads that wasn't caused by a developer doing any number tasks that > range from merely unnecessary to just outlandish.Exactly - and that's a part of the bigger issue I'm talking about.It's like "you're holding it wrong" issue with iPhone 4. Obviously, the way you're holding a phone shouldn't make a difference in the first place.Similarly, if notarization was implemented the way it should, you wouldn't even see those threads. Because developers wouldn't even have a chance to run into these issues.> Yes, it is 2020. But the nature of zip files on the Macintosh hasn't changed much since day one. (etc.)Once again - exactly what I'm talking about.Your excursion in the history of zipping is part of the problem. Because the issue of zipping shouldn't even come up on the level of developer implementation.If notarization process requires something to be zipped/unzipped, then Apple tools should do it automatically under the hood - without having to involve developers in the details of this process. > ...my suggestion would be to review Apple's published instructions for customizing the notarization workflow. > What does it say about unzipping?I guess there's a caveat in this question but - you tell me. I don't see anything. Needless to say, I find Apple's notarization documentation inadequate and detached from the way developers work in real life. But that's a different topic.Don't get me wrong - I'm just as Apple fan as anyone else here, using Macs since 1994 and developing since early 00s. But when it comes to notarization, Apple isn't at its best so far. Apple can - and should - do better.Leo

Hi John,I investigated further - and here's an update:I found out that technically you're indeed right. The ._Info.plist file is in fact created when unzipping the app using the unzip binary (via NSTask) - prior to the stapling stage. I elaborate on this more in the new reply to eskimo.The invisible file is indeed not created when unzipping manually in the Finder.This, of course, still doesn't mean that we should do things manually - because it's simply out of the question.But I believe that the mere fact that we have this discussion is a part of a bigger issue: that the entire notarization process is just not well designed and implemented. Because if it was well designed and implemented, we wouldn't have to go that deep into this rabbit hole and split hair about what zipping tool is more suitable in order avoid some obscure invisible files in the year 2020.Leo

Ok, I isolated some additional stages - and here's another update:You're right, it's not stapler that generates the ._Info.plist file.The file is created while unzipping the app after running altool and before running stapler.The unzipping is done by running the unzip binary via NSTask. I looked again through the unzip options - but couldn't find anything that would prevent it from generating the file. The ._Info.plist file is not created when unzipping manually in the Finder.Also, I included the full hexdump of the file at the bottom (although it's now probably irrelevant considering the above).This new info, however, doesn't change the nature of the original issue.Let me lay it down again, more accurately:-The app is successfully signed, zipped, and notarized by altool-The app is then unzipped in order to be stapled - now with the ._Info.plist file inside.-The app is successfully stapled.-The app is then copied to a custom installer on dmg.-The installer is successfully notarized with altool-BUT, at the last stage, on attempt to staple the installer I get Error 65 (due to the ._Info.plist file inside the app).I still don't understand how is it possible for the app to be successfully notarized - while at the same time its signature is in fact compromised. And that developers should hunt for and delete some invisible file from the app to make it valid again.In my view, IF this invisible file presents a problem, then stapler should give an error while stapling the original app - which error would describe exactly what the issue is and advise on a possible solution.Alternatively, IF the app is successfully notarized and stapled - then it should mean that there's no problem with the app and the app won't cause any issues during further processing (such as notarizing the installer).Hope it all makes sense by now!Thanks,Leo00000000 00 05 16 07 00 02 00 00 4d 61 63 20 4f 53 20 58 |........Mac OS X|00000010 20 20 20 20 20 20 20 20 00 02 00 00 00 09 00 00 | ........|00000020 00 32 00 00 00 7e 00 00 00 02 00 00 00 b0 00 00 |.2...~..........|00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|*00000050 00 00 00 00 41 54 54 52 00 00 00 00 00 00 00 b0 |....ATTR........|00000060 00 00 00 a0 00 00 00 10 00 00 00 00 00 00 00 00 |................|00000070 00 00 00 00 00 00 00 01 00 00 00 a0 00 00 00 10 |................|00000080Leos-iMac:~ startup$ hexdump -C /Volumes/iMac/Users/me/Development/Apple/Notary/Staging/Output\ Factory.app/Contents/._Info.plist00000000 00 05 16 07 00 02 00 00 4d 61 63 20 4f 53 20 58 |........Mac OS X|00000010 20 20 20 20 20 20 20 20 00 02 00 00 00 09 00 00 | ........|00000020 00 32 00 00 00 7e 00 00 00 02 00 00 00 b0 00 00 |.2...~..........|00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|*00000050 00 00 00 00 41 54 54 52 00 00 00 00 00 00 00 b0 |....ATTR........|00000060 00 00 00 a0 00 00 00 10 00 00 00 00 00 00 00 00 |................|00000070 00 00 00 00 00 00 00 01 00 00 00 a0 00 00 00 10 |................|00000080 00 00 1a 63 6f 6d 2e 61 70 70 6c 65 2e 6c 61 73 |...com.apple.las|00000090 74 75 73 65 64 64 61 74 65 23 50 53 00 00 00 00 |tuseddate#PS....|000000a0 55 1c 35 5d 00 00 00 00 b8 e0 0c 38 00 00 00 00 |U.5].......8....|000000b0

John,Thanks for your answer! I understand where you're coming from.But:-First, like I mentioned in the last reply to eskimo, the invisible file is created at the stapling stage - not after being zipped.-Second, I have several apps and my notarization process is fully automated - so I'm of course using a command line tool (ditto in this case). These are all legitimate tools - and fortunately there are no reasons to resort to manual operations in the Finder!

Quinn,Thanks for the detailed reply.First, I ran another test and here's more accurate info:The ._Info.plist file is not created by altool - it's created by stapler (or as a result of running stapler). I found it out after checking the app contents after running each stage.The volume where all the work files are located is APFS (as well as my startup volume). The final dmg is HFS+ - albeit it's irrelevant as the Apple Double file is created before copying to dmg.Here's the file hex ump if it makes any difference:00000000 00 05 16 07 00 02 00 00 4d 61 63 20 4f 53 20 58 |........Mac OS X|00000010 20 20 20 20 20 20 20 20 00 02 00 00 00 09 00 00 | ........|00000020 00 32 00 00 00 7e 00 00 00 02 00 00 00 b0 00 00 |.2...~..........|00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|*00000050 00 00 00 00 41 54 54 52 00 00 00 00 00 00 00 b0 |....ATTR........|00000060 00 00 00 a0 00 00 00 10 00 00 00 00 00 00 00 00 |................|00000070 00 00 00 00 00 00 00 01 00 00 00 a0 00 00 00 10 |................|00000080Opening it in TextEdit also reveals this string:com.apple.lastuseddate#PSLike I mentioned, this ._Info.plist file is only created in one app so far. When I notarize another somewhat similar app this doesn't happen. I have several other apps I didn't check yet.So to summarize the situation:-The app is successfully signed, notarized and stapled on APFS volume.-And yet, the stapler's action results in addition of an invisible file that invalidates the signature.-The app is then copied to an custom installer on dmg.-The installer is successfully notarized with altool-BUT, at the last stage, on attempt to staple the installer I get Error 65.SOLUTION:Delete the ._Info.plist file from the app prior to copying it to the installer.I, frankly, can't comprehend how a successfully notarized app can end up being invalid for further processing due to the actions of the very notarization tools. And that developers should hunt for and delete some invisible file from the app to make it valid again.Thanks,Leo

I just got the same error.Never saw this error before.My app is already notarized and inside its installer. Yet, after checking the log, the error claims that "The signature of the binary is invalid."How the signature can be "invalid" if this binary is already NOTARIZED?Plus I'm doing exactly the same operations I've been doing successfully for several MONTHS.Now, my users are waiting for an important update which I can't post because of - yet another - bug in Apple's notarization process.Apple's abuse of independent developers under pretence of "notarization" continues.We, independent developers, who run our own businesses are not getting paid by the our. The waste of time due to this half-backed notarization thing has been unspeakable. Which for independent developers directly transpaltes into loss of income.Leo