A single static library file is not a framework. Frameworks, just by themselves, can't be notarized. Anything that can be notarized must use the hardened runtime and a secure timestamp. So even if you had provided the secure timestamp flag, you wouldn't have been able to notarize this archive.

Technically, the guidelines say "should" not "must". And obviously that is wrong. It looks like it is just copy-and-pasted from the iOS app icon guidelines. The What's new in HIG page - https://developer.apple.com/design/human-interface-guidelines/macos/overview/whats-new-in-macos/ even shows examples of Apple apps that violate the rounded corner design on purpose. If you go to the Resources page, you can download template files that have the exact specifications you need.

You have to do that from the recovery console.

Sorry, but none of that makes sense. It sounds like you are going through a lot of effort to a make a simple process difficult. And what is "System.ServiceModel.Web.dll"? Silverlight? .NET? I suggest you ask Microsoft. Nobody here has any idea about that stuff.

The dylibs and exe file is zipped and sent to the notarization tool. What does that mean? You can't just stuff files in a zip file. Notarization is designed for specific structures, such as apps, installer packages, and dmg files. Maybe this is why you keep referencing "<my_lib.dylib>". Maybe you should start by explaining just what you are attempting to do - at very high level. Forget about notarization. What are you distributing here? also do the smoke test as you suggested. I didn't say anything about a "smoke test". There is only one way to verify notarization. One of the primary things people do that breaks notarization is inventing new ways to build and use dylibs. It sounds like you fall into that category. What is being broken in this case is not the signature or the scripts, but the process of loading dylibs and executing code. That can't be tested with a script on the build machine. However, it sounds like you aren't even making it that far. You are attempting to validate a dylib or something? I don't know if you can even notarize a dylib by itself.

I'm sure it is providing more specific details about the failure than that.

Argg!! I forgot about the mark down. The tool is "install&#92;&#95;name&#92;&#95;tool"

The libraries and the executable are packaged and sent to the notarization service, and the response is that the notarization is successful.  What do you mean "libraries and the executable"? The libraries should be bundled inside the executable. If not there, they should be bundled inside an installer package, or perhaps something even more esoteric. Checking with codesign, all looks to be good: Really? What about "test-requirement: code failed to satisfy specified code requirement(s)"? I strongly recommend against using that "notarized" requirement or the "--check-notarization" flag. I had to double check these because I didn't recognize them. I did find one of those flags in the codesign man page and I saw Eskimo reference the other one. So, they are valid, but that doesn't mean they do what people think they do. There is only one way to check notarization. You have to download the notarized file and run it. If it works, then the notarization is successful. There is absolutely no other tool, command-line trick, or codesign operation that will suffice - absolutely nothing. You must download the app with Safari, run it, and it must work. There are quite a few validation stages that a notarized app must pass. I don't know anything about your software, so I can't begin to speculate about where the problem lies with that particular build. Generally speaking, if you correctly build an app in Xcode, archive the app, and the submit the app to the notarization service, then it works perfectly 99.999% of the time. I can't say 100% because I'm sure there is always some oddball case or the notarization service is down. When people have problems with notarization, here are the top explanations: 1) the notarization service is down 2) the Xcode project is not correctly structured and is hacked up 3) the developer isn't building the project with Xcode and did something wrong 4) the developer isn't building the project with Xcode, is using some crazy 3rd party development tool, and has no idea what can of worms they have opened up upon themselves My guess is that you are in category 3, or maybe 4. People who report notarization problems are almost always category 4.

Sure. It's possible. But why would you bother? Why not just do whatever you need to do inside your app? Of course, I know the answer to that question. Whatever you are trying to do in python is likely more than just a basic python script. Such a task would be difficult, if not impossible, to do using the system-provided python. It might not even be possible if you bundle your own Python. Why do people insist on bundling Python or Java or Electron into everything? Why not just write the app? Yeah. Writing apps is hard. But trust me, getting self-contained, 3rd party runtime machines working in the app sandbox is harder. I'm sure someone will eventually cobble together some "recipe" to help others do it. But all that does is spawn yet another generation of abandon-ware apps. We got plenty of those already.

You don't need Python to compile apps. The previous post by crlab is optimistic at best.

If you are that low on free space, you should go ahead and assume catastrophic failure. Since you are already at the catastrophic failure stage, it doesn't matter anyway. Get a new Jenkins machine.

Never heard of BlueJ. It is apparently a Java app. Such things are extremely fragile. You should assume that it won't work. Depending on what Mac you buy (Intel vs. Apple Silicon) you may be able to hack on it and get it working. No guarantees though.

You can't put code in a Resources folder. 3rd party umbrella frameworks are also not supported. The .net framework will need to be a sibling framework. Since you are doing this manually, you may also need to manually adjust the paths of your framework using "installnametool" so that it can find the sibling framework.

Submitted a bug report and DTS ticket. I have a demo app that easily demonstrates the issue. At 1.0 quality, all other formats, including JPEG, are apparently lossless. HEIC is obviously lossy.

I get the error when I try to use clang from llvm formula from brew in my CMake project. What do the developers of brew and CMake say about this problem?