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

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

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!

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

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

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

> 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 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

40 GB RAM300 GB free space

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

I meant on any of my machines of course.I can assure you there's nothing wrong with my machines or my installation. I'm using Xcode since version 2 and never saw anything like this.Xcode 10 and all other apps are working fine on the same machines.There's evidently a severe bug in Xcode 11, which doesn't affect all users.I do hope we'll get to the bottom of it eventuallty.

I understand your point.However, like I mentioned, the same problem happens on two different machines, including clean new accounts.I don't use any third-party package managers.Like I mentioned, Xcode 10 works normally under same conditions. As well as everything else.I also did invest hours of efforts doing all reasonable troubleshooting steps by now.There is a bug in Xcode 11 - because otherwise this problem wouldn't happen. And if Xcode does have a problem with installation or something else, it should clearly inform about it - instead of quitely disintegrating into a rotten mess. It's a bug either way.I do hope Apple will get back to me and work further on addressing the issue. They're usually fairly responsive when it comes to developer tools issues.Leo

I agree that there's nothing good about dealing with a rare bug in Xcode. This one is certainly rare - but I already heard from a developer on another forum who had exactly the same issue.It looks like it affects some projects that originated in earlier Xcode versions years ago.Regardless, it looks like by now I managed to isolate the issue to a very specific case in xib files.I'll post details soon. Hopefully, I now have much more specific and helpful info for Apple to deal with.

Does it occur with a new project as well ?It doesn't. But now I can trigger it even in new projects by bringing certain elements from my xibs. I'll post details soon.Are all elements, tools, … installed in the proper place ?Xcode installed everything it should.I don't see anything suspicious in the logs or Activity Monitor, and the issue happens without Xcode 10 present as well..Regardless, it looks like I could isolate it to a specific case finally - I'll post details soon.

Ok it looks like I could isolate this issue to a very specific case: a window with NSTabView.
Here's what I discovered:-If a project does not have a window with a tab view, the problem doesn't happen.
-If any of my projects has a window with tab view, the problem is always triggered once I touch this window or any of its elements in IB.
-If I don't bring this window into view and don't touch it - the problem doesn't happen. Other elements don't trigger it.
-If I delete the tab view, the problem goes away.-Bring back a tab view - problem comes back. It doesn't have to be the original tab view - even a new tab view from the Library will trigger the problem again.
-No other UI element affects the issue. Only tab view.-This only happens originally with my own projects (which all originated back in Xcode 2-4). I tried some other devs projects with window+tab view and there was no problem.-But I can reproduce the issue with projects that I didn't create - and even with brand new projects in Xcode 11 - if I copy a tab view from my project to a window in the new project.
-It's sufficient to have just a single window with a tab view and nothing else - so it's not the complicity of the xib that causes the issue.
 
 As you can see I'm having fun here. Very productive.
 I may soon share a brand new Xcode project with a xib that triggers the issue (here at least).Thanks,Leo