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.

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.

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

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.

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.

Argg!! I forgot about the mark down. The tool is "install\_name\_tool"

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

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.

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.

You have to do that from the recovery console.

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.

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.

The error in the log is like this... Like what? In all honesty, it probably doesn't matter what the error in the log file is like. Have you confirmed that it is even possible to access shared memory in a sandboxed XPC service? Personally, I don't know. It sounds like you are trying to do something really tricky, over and above shared memory in a sandboxed XPC service. What does this app do anyway? Have you confirmed that it is something that will obviously pass app review even if you can get it working? And why are you asking about the hardened runtime? I'm sure Apple wants all developers to adopt the hardened runtime and I wouldn't dispute that it is a good idea. But it should be an afterthought that you wouldn't even see the point of mentioning. The fact that you did mention it suggests you are trying to do something clever to get around Mac App Store sandbox limitations. If that is true, it is dead in the water.

We have an app in the store Then none of that applies to you. We cannot upload a new app as it will take a tremendous amount of time to rewrite it, and if broken we will have a serious production issue as lots of customers are still using it. This doesn't make any sense. If you did need to resubmit for some reason, it should only take a couple of minutes. What do you mean by "rewrite"? You don't need to rewrite the app to submit a new version. This particular issue does not apply to you as Apple manages certificates in the store. However, it sounds like you could have some very serious problems with your app. You should investigate what is going on. Ensure that you can re-build the app and resubmit it in a couple of minutes should the need arise. If there is any reason why you can't do that, then you are in serious, serious trouble.

It contains UIWebview etc. where in order to submit a new review will make us change a lot of code. We don't want to touch it, just leave it alive as long as it will take by itself. This app will likely stop working entirely when Apple removes support for those deprecated APIs. Apple has gotten much more aggressive about this sort of thing recently. It would be better to just pull the app if you are not supporting it.