Qt application for macos not being launched

I am working on an application written in Qt for macOS environment. In order to generate release build i have set up external server.

I am seeing this:

After generating build, if I download and install the application on Applications folder, when opening it, first I see the popup asking if I am sure to open app downloaded from Internet, so I click Open and then app dies.

App works fine if I open it from CommandLine in Terminal. Maybe is due to the fact there I don't see the popup asking if I am sure to open it.

But I am kind of lost because I don't know where I can check logs or the error I am having

Could someone help me please ?

Thanks is advance

Replies

If that's the route you want to go, I can't give you better advice than what eskimo is saying. I can tell you that said Tech Note 2206 includes a link to the "SignatureCheck" tool that may provide more insight than spctl. I'm just guessing though. I haven't tried to run it.


I also suggest that your first step would be to thoroughly study the bundle structure of your app and see exactly how it is launching.

Yep I already run SignatureCheck and it passes the checks. This is why I was asking. Could be possible that problem is not in Gatekeeper ?

The problem was never Gatekeeper. The problem was always the Qt app.

I was not saying that problem was in Gatekeeper. I just said that after running all signture checks I got all of them passed. So maybe problem is not related to signature (i meant that when I said gatekeeper, sorry).

I thought about gatekeeper because if I remove manually the quarantine app runs.

Basically my question was what else I could check to find the problem.

I have checked also the folder structure and it is the same that regular macOS app.
I am reading to Notarize the app. Could that be possible solution ??

Thanks

What else can I check ?

Nothing immediately springs to mind. To offer further advice I’d need to take a look at the structure of your app, and that’s not something I can do here on DevForums. My recommendation is that you open a DTS tech support incident and we can pick things up there.

Make sure to reference this DevForums thread, just for context.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

I was just assuming there was something strange about the folder structure based on what I have seen from other popular open-source apps that have been ported to the Mac. If you are saying your folder structure is the same as other Mac apps, then I'm totally off-base. Follow eskimo's suggestion to open a DTS ticket.

Just in case. This is my folder structure:

Inside .app I have Contents folder. Inside Contents:

Folder called _CodeSignature

Folder called Frameworks with dylib and framework files

Info.plist file

MacOS folder with the main executable file and another executable (tool needed)

PkgInfo file

Plugins folder

Resources folder


This organization is correct, isn't it?

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.

MacOS folder with the main executable file and another executable (tool needed)

Contents/MacOS/
is the canonically correct place to put helper tools. As john daniel mentions, you should make sure that
CFBundleExecutable
points to your main executable.
Plugins
folder
Resources
folder

The presences of these directories is fine, but you need to make sure that the contents of these is structured correctly.

Again, I recommend that you open a DTS tech support incident so that I can help you out on a one-to-one basis.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"