Qt application for macos not being launched

Most of those open-source ports have a funky bundle structure that does not conform to what Xcode produces. So Gatekeeper blocks the primary executable and prompts you to confirm. But then the secondary executable is being launched via some shell script and that does not invoke Gatekeeper properly.

The solution is to avoid those open-source UI frameworks on macOS.

So only solution is to drop Qt?

I have to add that first time app dies as I described above but then if I try to launch again the app it works. So the problem I am seeing happens only first time app is launched after being downloaded

Any other ideas ?

Well, Gatekeeper is not exactly an innovation. It's been around almost 8 years now. And the basic structure of an app bundle is about 19 years old now. I wouldn't recommend attempting to update Qt either. macOS has more years behind it than in front.

Usually these open-source apps are built on a single computer and run from there. Gatekeeper never gets triggered in that case. If you are "downloading" from a build server, you might want to try a script that removes the quarantine flags and allows the app to bypass Gatekeeper.

For future work, I recommend UIKit. It is still in its infancy on macOS, but it will be mandantory well before anyone is ready for it.

https://en.wikipedia.org/wiki/Qt_(software) check the "Applications using Qt" section

Same issue over here

So only solution is to drop Qt?

No. The “funky bundle structure” that john daniel refers to presents deployment challenges, but it is possible to use a non-standard bundle structure and be compatible with modern versions of macOS [1].

You need to look to your tools vendor for support here. They should be keeping abreast of the latest platform developments and updating their tools accordingly. For example, Oracle seems to do a good job of this on the Java front. And if your tools vendor is not keeping up with platform developments, that’s something you need to factor into your tooling choices.

Now, if you want to fix this for yourself — or, perhaps, cooperate with other members of the community that rely on the same tools — then my #1 recommendation is that you look at how your built binary complies with the rules in the Nested Code section of Technote 2206 macOS Code Signing In Depth. That is by far the most common cause of problems like this.

If you find that your built binary isn’t following the nested code rules, you may be able to fix that using the technique outlined in this post.

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

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

[1] In most cases. Some things, like self-modifying apps, are just not supported.

But there something I dont understand here. If problem with signature was the problem application would never run, right? not only first time.

Because after dying first time then I can launch it without any problem

Yes, that is weird. Gatekeeper does a bunch of extra checks on the first launch of your app on first launch, and it’s possible that these checks are triggering this failure. Normally I’d expect that this failure would cause Gatekeeper to re-run its checks, but it’s possible that the failure occurs after Gatekeeper has recorded a success.

Does the failure generate a crash report? If so, post it here and I’ll see if I can learn more.

Regardless, my previous point stands: A common cause of weird code signing / Gatekeeper / notarisation failures is incorrectly nested code, and that’s the place where I recommend that you start this investigation.

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

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

I have checked in Library/Logs/DiagnosticReports and there are no crash reports there.

Looking at console logs displayed I have seen this line "LSExceptions shared instance invalidated for timeout. " I dont even know if it is relevant. Any idea related to that ?

Thanks

I doubt your app is crashing. I also doubt you are going to find any meaningful information in the logs. And I'm not sure what you mean by "looking at console logs displayed". That suggests you might be unaware of significant changes to the macOS logging infrastructure over the past few years. You can't use Console.app like you would have years ago. It has to be up and running before you do your test. Otherwise, you have to use the new "log" command line tool as well as its predicate language for searching for relevent log entries in the past. It's not a trivial task.

When doing any kind of testing on Gatekeeper or other system-level interactions, I strongly recommend testing in a VM. A decent VM will support snapshots, making it easy to roll back to an inital state and test again.

I'm not going to take the same diplomatic approach as eskimo. Qt is just a dead end on the Mac - end of story. If you want to keep using it, fine. Please see my earlier suggestions on how to do an end-around of Gatekeeper.

That code signing documentation was first written in 2008 and has not been updated in over two years. In particular, it doesn't say anything about Notarization. About six months ago, Apple announced that Notarization was going to be mandatory. The other day, Apple finally announced when Notarization was going to be required and a number of popular developers are freaking out over it today. Or, if nothing else, they are enjoying a noticeable uptick in blog traffic 🙂.

But my point is that it is going to be difficult to beat your old Qt app into conformance with modern, and constantly evolving, security practices and infastructures. In my opinion, I don't think it is worth that level of effort. It would better to just identify the bottleneck, Gatekeeper, and change your processes to avoid it. That's an easy, 5-minute fix.

But if you do plan to distribute this app publicly, then a more thorough review is in order. Stripping out Qt would be a high-cost, but low-risk solution. Beating code signing into submission would be a moderate-cost, moderate-risk solution. Which is best for you? What other value, if any, does Qt bring to you? What other value would an alternative, but more mainstream approach, bring?

I am using Qt because the app is cross platfom and so far it is not up to me to drop it.

I have more info, after downloading the application if i do ls -la on it it has extended attributes. Checking them i see that app is marked as com.apple.quarantine which is logical as it was downloaded.

If I remove the quarantine with xattr -dr com.apple.quarantine <path> app runs with no problem.

Could you help me to see what is going on ?

Yes, I realize why people might use Qt to try to get a free cross-platform app. However, nothing is free. You pay the cost with problems like this. Many popular open-source Mac ports have similar problems. There have been many attempts to develop a cross-platform framework for app development over the past 3 decades. All of them have failed. Every. Single. One.

I say just write a little shell script that downloads your app via curl and then immediately runs that xattr command. That will get you over this problem until the next time Qt causes your app to fail. That will happen in about two months.

If you want, you can inspect the app bundle and compare what is different between your Qt app and a native app. Most likely, there is some stub, possibly native app wrapper that immediately launches the Qt version. More likely, it does that via a shell script instead of a native stub. It could have done a fork/exec, or maybe an XPC, or maybe just launch an embedded helper to bootstrap the Qt version. All of those would have likely made it through Gatekeeper unscathed. But I'm just guessing.

Unfortunately, there is no easy answer. Maybe I'm wrong and you can figure out what is going on with Gatekeeper. Maybe you can get it working without any hacks. But I still expect it all to fail again in some novel, unexpected way in 10.15. Maybe you might be able to hack that and get it working. Maybe the Qt folks will do that after several months. Had you posted an innocent question about using Qt years ago, I would have told you the same thing. Those things work until they fail. And when they fail, either you have to fix them or the community has to fix them. The community isn't very big and they don't care much for Macs to begin with.

Is there any way to see the output of GateKeeper in order to find out where & why it fails ???

Is there any way to see the output of GateKeeper in order to find out where & why it fails ???

You can use the

spctl

Note that TN2206 discusses this tool in a section entitled Checking Gatekeeper Conformance. I strongly recommend that you read that entire doc in detail. It contains a wealth of knowledge of about how to resolve issues with a “funky bundle structure”, knowledge uncovered by a colleague here in DTS who spent many years of toiling on the code signing coal face.

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

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

have run the three tools recommended in the site and according to them signature is valid:

codesign --verify --deep --strict --verbose=2

check-signature

spctl -a -t exec -vv

What else can I check ?