We could not go with the "within XCode" option and this is why we are trying to figure out how to do without it.
Are you sure about that? I'm not saying you need to rewrite your app in SwiftUI or anything. But you can have a mostly empty app project with a "main" function that does nothing but call out to whatever cross-platform frameworks you are using. Xcode will make a proper application bundle and give you lots of additional features, like notarization, for free. You can even do your building on the command line with xcodebuild. Some of my dependencies are in CMake and crazy Google-written build systems. It is relatively easy to re-do those in an Xcode project, which makes lots of problems just go away.
the reason why we need Qt is that the application we're working on is a cross-platform one and before all this notarization stuff happened it looked like the best option for us.
Appearances can be deceiving, but I'm not going to belabour that point. But I will tell you that the Mac platform is changing. If you want to avoid problems in the future, ask yourself one question - "what do I need to do to port this to iOS?" If Qt solves that problem, go for it. If not, then you will have problems in the future. [Note: apparently Qt does have an iOS version. I'm just joking here. Anyone building a new Mac app in 2020 needs to build a native iOS app instead and port that to the Mac - end of discussion.]
Yes, I have looked into a "valid" framework, and the only difference I saw was the structure of the Versions/ folder: in the "valid" case, it had the A/ folder and a Current/ symlink pointing to it, while in my case instead of Versions/A there is Versions/5, and this is a known issue with Qt Frameworks. I haven't very clear the difference between symlink and alias, what I can tell you is that I created them with the "ln -s" command. Anyway, the files I said I have removed are not really removed, but I moved them to the Versions/A/Resources/ folder
In theory, you can have multiple versions of framework. In practice, nobody does that. Apple isn't using versions for frameworks on iOS (hint, hint). What "valid" case are you looking at?
I didn't think that you were using a Finder alias, but these things have to be absolutely precise. Yeah, I'm being annoyingly pedantic. But I'm being far less annoyingly pedantic than Apple's servers or Gatekeeper framework is going to be. The structure of a framework is documented here. One of the first things it mentions is versioning. Maybe, if you do it perfectly, you could get that to work. But I suggest starting with just version "A" and getting that to work first. You can build a framework entirely from scratch with a shell script.
I am attempting to download Qt to look at that. That is proving to be a challenge. Not a good sign.
And what about the plugins, dylibs and framework? My understanding was that they needed to be signed as well, and that it was not too much of a good idea to use the --deep option for codesign
There is no "as well". The app bundle is "the executable". You sign the app bundle and that's it. If it doesn't work (through the entire notarization flow), then your app bundle is invalid. If you build things using Apple's tools and with Apple's technologies, then there is nothing to worry about. Everything is pretty straightforward and will be identical to every other app. But if you try to do something funky, then you have to be careful. Open source projects frequently do funky things and frequently have problems. Qt seems to be unique. Is it open source or proprietary?
OK. I did get some of Qt installed, not the full 200 GB worth, but enough to see the frameworks. Aside from the "5", they look OK. But there are 59 of them. And Qt doesn't seem to actually build stand-alone bundles. It is relatively easy to embed a framework from within Xcode, and Xcode will do all of the work necessary to make it work. If you don't use Xcode, you'll have to do all of that yourself. While I'm certainly no fan of Qt, and even less so after having seen it, it doesn't appear to be doing anything wrong. It definitely isn't doing enough to make a deployable app bundle for you. It seems like they are leaving all the hard work up to you. Those .prl files look like some kind of Qt version of pkg_config or something. I doubt you need them at runtime.
It sounds like all you have done is corrupt the frameworks. I'm not sure what you are doing, but I think that your overall build procedure is not valid.