Ok, we managed to solve the issue. I describe briefly the solution here in case it might help other people which have to go "the hard way" in saving a week of trials and investigation.There was actually something in how the Qt Frameworks were copied inside the .app folder and we did not figure out exactly why it failed doing it by hand (we tried both with finder and calling 'cp -R'), but the issue was solved when we upgraded Qt to 5.14.1 and copied the frameworks to the bundle using 'macdeployqt' command.We submitted the app on Monday and notarization succeeded with no issues.Thanks for your help

Thank you for the link, I somehow managed to miss it while looking for answers. As I told your colleague, I tried to structure the Qt frameworks "the Mac way" and this time there were no notarization issues, but I could not open the executable because in some frameworks runpaths there was some reference to /Versions/5 folder which I was not able to replace with install_name_tool. Curiously enough, as soon as I tried to add a Versions/5 symlink I was not able to sign the bundle (unsealed content error), and I hope the link you provided will shed some light on this issue.I get that what we're trying to do is not really standard, and there might be something else going on, and this is why I would have hoped/expected to receive more hints about the error and what is causing it

I am sure there is something wrong with my Qt Frameworks structure, and I am attempting to explain you why I am convinced of that. After I replied to you I tried to structure the Qt frameworks I am including in the bundle as any other working framework:QtFramework.framework Versions A Current (symlink pointing to A)I signed the app folder, zipped it and sent it for notarization, and when it came back I inspected the json result and there were no issues in it (neither errors nor warnings).Unfortunately, I still can't execute it because removing the Versions/5 folder inside the framework invalidates some entry in the frameworks @rpath path. I verified that if I runotool -L QtFramework.framework/Versions/A/QtFrameworkthe first entry I get is@rpath/QtFramework.framework/Versions/5/QtFrameworkand I have not been able to correct it with install_name_tool. If there are other Qt frameworks found with the otool command instead, they are correctly referenced with "@rpath/QtOtherFramework/Versions/A/QtOtherFramework".So yes, I think I get what you say about building a framework from scratch and I was going for it but I just am missing something in the process because I haven't been able to correct all the needed runpaths so far. And I am quite convinced that this is more on the Qt people than it is on you (after all, frameworks are used only on Apple, why Qt people structured them differently from standard goes far beyond my understanding), but you were the ones who replied me first.Once again, I don't think this app is ever going to be ported to iOS: it is a (desktop) cross platform tool used for research purposes by people who don't need to have any specific computer backgound, they ideally just need to double-click and run it (whether they are on Mac, Windows on Linux), and before this Gatekeeper and Notarization enforcement we were able to successfully build and execute the bundle.And I am not saying this enforcement is wrong, I can see how safe it is from a user point of view.RE: There is no "as well". The app bundle is "the executable".Fine, I trust you on that, but there are (too) many other posts saying otherwise (including https://developer.apple.com/library/archive/documentation/Security/Conceptual/CodeSigningGuide/Procedures/Procedures.html#//apple_ref/doc/uid/TP40005929-CH4-SW5), and since as you can see I am not an expert it can be misleading.And once again, thanks because at least you replied

Thank you for your reply. We could not go with the "within XCode" option and this is why we are trying to figure out how to do without it.RE: Everyone else using Qt might be posting questions on these forums asking about specific edge cases for the last date they can get notarized under Apple's special extension and whether or not that download will still be notarized later. Hopefully you aren't doing that too.Of course I am not, that would have saved me 2 days of banging my head against a wall. But no, I might have to release a new version in the future so I want to understand how to do it the proper way. And yes, I have a Mac and I am building it from there: 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.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/ folderRE: The only thing you need to sign is the .app folderAnd 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 codesignThanks