That thread is 5 years old. Try a simple example without fastlane. If that works, then it's a fastlane problem.

That behaviour would break several Household Name apps. You can implement your own stricter code signature checking. Don't forget to check for code injection. You don't really have to worry about malicious apps. That's more of a social media thing. It's the software pirates you have to worry about. That's your threat.

That's not a fair comparison. You are doing codesign on Xcode. 😄 Checking the code signature on a normal app takes a fraction of a second and can be done on a background thread. Things can spiral. In the past, there was a possibility that an attacker could modify the operating system itself. I don't know if this is even possible with the sealed volumes in Monterey. It is possible to check for unexpected dynamic libraries injecting code. One trick the pirates did was wrap my app with another app having an identical icon, inject changes between the OS and the app, and then run my app in the new environment. So my code signature was always valid. I had to check for a wrapping app and unexpected dylibs.

Thanks!

This thread is 5 years old. Since then, macOS has become even more like iOS, which has no framework version at all. Check the frameworks used by Apple and 3rd party developers on your Mac. Do you find any that use a version other than "A"? This is one of those things that, in theory, should work. And maybe it did work 20 years ago. How much effort do you want to spend, and how long do you want to wait, before just changing the version to "A" and moving on?

That is true, but you did specifically say, "Validating your app’s code signature on launch is never going to fly performance-wise." Unless gmorimoto is shipping an app of the scale of Xcode, then validating that app's code signature would be fast and easy.

But that's the entire point. It sounds like you are doing things correctly. Yet it isn't working. You are going to have to develop additional expertise to figure that out. Let's go ahead and assume you fix it. What value does that additional knowledge of AppleScript edge cases in the Mac App Store bring to your app, your employer, and to you personally? You are just paying the minimum monthly payment on your technical debt and kicking the can down the road to be someone else's problem later.

Normally helpers are in a "Helpers" folder alongside the "MacOS" folder. I don't know if that's the cause of the problem. It shouldn't even matter as far as AppleScript is concerned. It doesn't care if the target is running or not. It will launch it if it needs to. In this case however, Mac App Store security restrictions might break something that was already broken, yet working by accident, outside of the Mac App Store environment.

This thread is 2 years old. You should start your own question for your problem.

For C++, you will need to use "clang++"