Perhaps the first step is to learn the correct terminology so that other people know what you are talking about. When you write "XCODE", I know you mean Xcode, so I'm not complaining about that. But it is a good example of why you aren't able to articulate what is going on in a manner that other people can understand.
When you run "under" Xcode, you are simply running the app in a debugger. At a fundamental level, your app, in that state, is completely different from the app when run from the Finder. It doesn't even use the same sequence of instructions. It's a different app - a different binary file altogether. What can go wrong there? Literally anything and everything. You can run in release mode form Xcode, but it usually isn't advisable. It won't help and will only confuse you.
What you are describing is simply a problem with notarization. There is an entire forum on the Developer forums dedicated to notarization. (See https://developer.apple.com/forums/tags/notarization/). I suggest looking for any posts by the Apple engineer known as "eskimo". He periodically creates "how to" posts covering commonly encountered problems. This post seems to be the latest such example, but he has written many, many similar posts. You should also review the documentation and the most recent WWDC video.
Unfortunately, Apple never seems to grasp just how many developers never review any of that documentation and how many are just making it up as they go along. I gave up answering notarization questions in the developer forums out of sheer frustration. I wasn't frustrated with the notarization process. Notarization is one of the easiest things to do. I was frustrated in my attempts to get other developers to read documentation and, at a basic level, understand how apps are constructed. This is not a case of something that I'm saying "should be" easy for developers because it's easy for me. It is easy if you just accept the defaults and take the easiest route. But, invariably it seems, developers who have notarization problems seem to invent unique new ways to construct apps that no one has attempted before. This is a fundamental problem. Other developers, or support engineers from Apple, can't help because all they know about is how to properly construct apps. But when developers in notarization forum finally explain exactly what they are doing, my reaction is always, "Wow. I never thought anyone would try that." Even eskimo seems to have become resigned to the problem. He rarely spends much time explaining anymore. Usually he just asks the developer to file a DTS ticket. That might be a good idea in this case too.
gordon_lister wrote:
My purpose in coming to this forum however was to learn, in particular as to the nature of the class of errors that provide no hint as to their existence when the code is executed running "under" XCODE but which nevertheless crash the program when the binary is run stand alone. We can eliminate issues related to their party libraries
I'm assuming you meant to write "third party libraries". And on that point, I am extremely skeptical.
I do not use anything that is not part of C++ or Objective-C.
That has absolutely nothing to dow with third party libraries.
So generally speaking, now we are getting down to it, do you have other more concrete suggestions to the type of issue that can escape notice in XCODE (no exceptions being thrown) but crash the binary when it is run stand-alone.
As I've said above, you have a standard case of notarization failure. You keep trying to ask some philosophical question about the nature of software development. All software ever made will behave radically differently when run outside of a debugger. Then it will behave radically differently when run on a different account on your machine. Then is will behave radically differently when run on a different computer. Then when you try to run it at scale (with hundreds or thousands of different users), those once-in-a-million crashes become an avalanche of support e-mails.
As I'm rapidly approaching the 5000 character limit here in the forums, I can't engage further on philosophical debates. All I can do is solve your problem, ignoring virtually everything you've said. Most likely your problem is because a third party library either wasn't linked properly, wasn't signed properly, or is doing something illegal. You may be able to adjust your hardened runtime entitlements to compensate, maybe not. Or maybe you are doing something "clever" outside of Xcode that just so happens to work in the debugger. One easy solution is to create a new app project using the Xcode app template. Archive it. Export it. Notarize it. Example how it is constructed and how the process works for that simple app. Now identify the ways that you are doing things differently. Start with those differences.
