I'm trying to implement an Go2Shell or cd to.. like App and upload it to AppStore. Bad idea. Generally speaking, you should consider how your app would work on the iPhone. If that doesn't even make any sense, then your app is probably not suited for the Mac App Store. It probably isn't even suited for the Mac anymore. Put icon on Finder. By pressing the Icon, the user can launch the terminal at the current Finder path Yes. I wrote one of the first implementations of such a tool, at least 12 years ago. The crude way to implement it is like the source code here. Get the current Finder path by AppleScript return value. And then use /usr/bin/open to launch the terminal with path parameter. Fixed your typo there. According to this post ("Executing AppleScript in a Mac app on macOS Mojave and dealing with AppleEvent sandboxing "), I can't just disable the sandbox or use "temporary exception". Correct. It is always a bad idea to write software that depends on some other developer's work. You are literally dependent on them. Do they approve of this derived work? Do they support it? Will they change their API one day and break your app? Apple is "some other developer" much like anyone else. They have a certain interest in supporting your work, but they have limits. And since Apple software runs as root, Apple has more limits than other developers. The only possible way is to find the scripting targets of the Finder. But I can't find the corresponding target name by sdefcommand. Anyone know how to fix this problem? The limitations you are trying to work around are there by design. This is a case where your success would be considered by Apple to be a critical security bug. Not only will Apple not allow your app in the Store, they will literally submit an update to the operating systems of 100 million devices just to block your app. The easy answer is to just find some other app to work on. Apple has a number of authorized Finder APIs you could use if you really wanted to. However, most of the limitations I mentioned above would still apply. It is better to go your own way, write an app that people want to use, and then add support for operating system integration as you have time, in a secondary capacity. There is literally no possible downside to this approach.

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.

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.

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.

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.