The issue is "and another executable (tool needed)". There should only be one executable in that folder. I'm not sure what you mean by "tool needed". The "CFBundleExecutable" in the Info.plist file identifies the executable.
In theory, you can have anything you want in that folder as long as "CFBundleExecutable" specifies the executable. That executable can do anything it wants, including launching other executables to do handle the app's logic.
But that is a theoretical world, whereas we live in a practical world. Recent and upcoming versions of macOS may not respect that logic. Gatekeeper, for example, may cause problems. I can't say definitively that it will cause problems, but when you deviate from the norm (i.e. what Apple normally tests against) you raise your risk of encountering problems like this.
If you do encounter problems, you have a number of choices:
1) File an Apple "radar" bug report and hope for a fix. If a fix does arrive, which is very unlikely, you should expect it to take 1-2 years. If you are extraordinarily lucky, Apple could fix a bug in 1-2 minor releases. But for this, you have to demonstrate a significant failure of expected functionality and someone at Apple has to find that problem, recognize it, and decide that they really screwed something up and should fix it straightaway.
2) Dig into the details of app launching and Gatekeeper and idenfify exactly how this is failing. Ideally, if you do #1, Apple would really appreciate it if you did #2 as well and sent your results in your #1 radar submission.
3) Dig into the details of app launching and Gatekeeper and identify exactly how this is failing. Make necessary changes in your app to correct the problem. Ideally, you should also do #1, and include your results in yoru radar report, so that other people don't encounter this problem in the future. Maybe you should also submit your changes to Qt so that they can fix their system in case Apple does nothing.
4) Don't use Qt. Regardless of platform, it is a good idea to separate your app's core logic from your app's user interface. If nothing else, this will give you a command-line version of your app as well as a GUI version. And maybe you'll get a stand-along framework that could be used in other apps, or perhaps as part of a web service. And if you are doing this, it isn't too difficult to write a native Mac user interface that wraps that underlying code. And maybe, for good measure, you write an iOS app that uses the aforementioned web service.
With a moderate amount of effort, you should be able to figure out and fix the problem. But you have a very good chance of having even more serious problems with 10.15 comes out. And then, when the expected Arm version of 10.16 arrives, your app is completely dead and maybe you are out of a job.
Or, you could do a little bit more work, eliminate your dependency on Qt, make your underlying functionality more reliable and more testable, and deploy to two additional popular platforms (iOS and the web). And you will be the one responsible for it all.
