I am being careful. You're wrong. I'm not asking about the app container folder, I'm asking about the sandbox as a whole set of constraints. I don't want my binary to have any extra permissions other than the ones the XPC will have. Then I suggest research how the sandbox works with respect to entitlements and inheritance so that your questions will be more clear. Great, the only problem is apparently you can't execute them. Speak for yourself. I can execute them just fine in the sandbox. Sorry you can put two and two together. As you can too. Someone with more experience in these things than both of us put together told you to run it from the bundle. You dismissed that advice because of some other, likely unrelated, problem. That's the answer. I understand that it didn't work when you tried that. But the fact there is some other problem in your code doesn't change the fact that this is the answer. I don't care about distribution right now. Having a sandbox, regardless of distribution, is better for everyone, users, developers and other apps. On Apple's platforms, distribution is always an important factor. I agree that the sandbox is better for users, that's why it is required for the Mac App Store and recommended everywhere else. But it is not necessarily "better" for developers as it adds complications, some of which cannot be overcome even by entitlements. However, this is just a pedantic talking point. In your specific case, you are simply doing it wrong, regardless of sandboxing or distribution. The fact that it works when the sandbox is disabled does not necessarily mean it is correct. I don't know what you mean by hacking. I need a process to do something. It's not short. It's not unlawful. A "hack" has nothing to do with malware or exploitations of vulnerabilities. It simply means you are doing something in an ad-hoc, non-standard way that is likely to break under a future and/or more restrictive environment. Apple regularly increases security levels in the operating system. Sometime of these changes may impose additional restrictions even on non-sandboxed apps. Apple made major changes like this in Catalina. What you are proposing is at relatively high risk of breaking in some future update. That’s all you had to say! The rest is unnecessary and unhelpful. Good luck then!

I wrote the app in C and didn't use Xcode for this project otherwise I would have done it the simple way. Xcode can do C. If you are trying to deploy via the Mac App Store, then you must have some sort of GUI. I'm guessing this is Yet Another Qt Question, amiright? Technically speaking, I'm sure you could write a Qt app in Xcode and then make use of many of Xcode's built-in features. I don't know if that would be an easier path at this point, however. I was trying to run spctl because I read somewhere that I need to do so in order to check that everything was in order before submission. I can't provide too much help on this point because I would never attempt to deploy an App Store binary using a 3rd party environment. I can tell you that you are confusing yourself by mixing up Developer ID with Mac App Store issues. That are completely separate. You may need to do some kind of preflight step of checking the signature of your installer before you upload with ApplicationLoader? You just have to focus on doing that strictly for Mac App Store apps and keep Developer ID complications out of it. I'm not sure if spctl is ever going to give you a reasonable answer. When you submit to the Mac App Store, Apple re-signs everything. If you keep searching, you may be able to find some recent instructions on how to do this for 3rd-party Mac App Store submissions. This is complicated and I really wish I had used Xcode.  You can't do anything about the past. What's done is done and you'll never get those days back. How much time and effort from your future do you want to continue to sink into that hole?

How do I remove the quarantine? I'm not sure what you are asking here. The quarantine is a metadata flag. You can remove it with xattr, but that is unlikely to help. You can's ship with that. How do I get the system to put those process in the same sandbox the parent is using? Again, you have to be careful with your terminology. I'm pretty sure you are asking about the app's container folder here, not the actual sandbox, which is a runtime environment. Obviously you could just copy files into the sandbox, but again, that's not going to be helpful. When your process spawns another process, by default, it inherits the same runtime sandbox. That isn't helpful to you either. You are asking about a system restriction which you can't change. I'm not running it from the bundle cause it fails from there as well, probably for the same reasons. What is this "probably"? There is no "probably" in software development. Either you know the cause, or you don't. Speculations and assumptions are only useful when you have several days where you really need to be frustrated and unproductive. I suggest you stop here and investigate this failure. Then you will be able to run from the bundle and keep your complications separate. More importantly, assume I want to download plugins from the internet, from my curated website, with helpers, and deploy them to ${sandbox}/Library/Plugins/. From what you're saying I wouldn't be able to run these? Well that's a can-o-worms. What's the big picture here? Why are you sandboxing? Is this for Mac App Store deployment? Before you spend too much time on this idea, you have to make sure your app idea will pass App Review. App Review does have a category for "plugins" but it is up to you to interpret it and ensure that your app will comply. Apple won't "preclear" apps for App Review. I strongly advise making the "plugin" idea an optional afterthought that you can disable, if necessary, and still have a viable product. If you aren't deploying via the Mac App Store, then you have more options. In no case is hacking inside your app container a really good idea. You'll have to be careful with this and structure the UI such that users can drag their plugs into the folder. Your app can conveniently open the container folder for them in the Finder, but the sandbox will cause problems due the the restriction that eskimo mentioned. But if you aren't deploying in the Mac App Store, do you really need sandboxing? There are a number of ways, sandboxed or not, to make binary plugins "available" to your app, depending on your implementation.

it is a Java based application with openjdk 15 included in the package At least Java isn't too outlandish compared to some of the things I've seen people attempt here in the forums. Here are a few tips to try: First question, does your app even work? Many people skip this step. Bundle your app. You don't need to code sign or do anything else at this point. Zip the bundle (ideally using the Finder, but you can use ditto if you get the arguments just right). Copy the zip file to another machine running Catalina and unzip (use Finder because that is what your users will be using). (Big Sur may have some new behaviour with respect to signatures, so avoid it for now.) Make sure the other machine is pristine. Using a VM for this is very handy because you can easily reset the VM back to a freshly installed OS state. Use xaddr to remove the quarantine flags from your app. This eliminates Gatekeeper for a while. Does your app run? Many developers build apps that link to hard-coded dylibs or other files on their development machine. They they do 16 more steps and complain about the last step not working. It was wrong on day one. That is what you are trying check for here. 2. Repeat the above, but sign the app with the hardened runtime. Don't bother notarizing. Depending on your level of funkiness, you could also have failures due to the hardened runtime and/or dylibs. This would be your opportunity to investigate and fix those. 3. Now try after notarizing and stapling. Keep the quarantine bits enabled this time. If you have problems running in any of these tests, what you want to do is run Console, turn on streaming, wait a second or two for some data to show up, then, as fast as humanly possible, launch your app. When it fails, turn off streaming. If you can do that in 5-10 seconds, you might have only a few thousand messages to inspect. I'm not kidding here. You can try filtering for your app name, but that isn't reliable. There is no guaranteed that the pertinent message will have your app's name. It probably will, so it is OK to try the filter at first. What you are looking for are problems loading dylibs, environment, run paths, @rpaths, and a few dozen other things. With Java, the failures could be anywhere. At least with Java, you have some additional tricks to try. You could setup a pristine VM with nothing but the Java runtime installed. Then you could try just running your JAR file. That might narrow down the problem space a bit. Good luck!

I want to submit my python based application to apple store OK. Wait a second. Let's focus on that. Do you really want to do that? Apparently this is something that people have been trying for years and haven't gotten it working. See github.com/pyinstaller/pyinstaller/issues/2198 Also, you are trying to Notarize with a Developer ID too? Are you aware that has nothing to do with the Mac App Store? I don't know if trying to build a Notarized Developer ID version would be any easier. It may just give you a completely different set of problems. But you definitely don't want to try both. For one, it simply isn't possible. For another, you may just confuse yourself. Mac App Store and Developer ID are two separate tasks. Apple does try to get people to sandbox their Developer ID apps, but that is a different question and not something you should probably be attempting at this point. That GitHub link contains a reference to this person getting something close working: medium.com/python-pandemonium/embedding-a-python-application-in-macos-d866adfcaf94 However, in this case, the developer has generic, Objective-C Mac app running and is then using Python as the back end. That is a much more manageable problem.

What do you mean "XPC sandbox folder"? Any external tool that you are running should be either: Accessible to any app Inside your app's bundle, in an appropriate sub-directory Specified with a security scoped bookmark There is a possible #4 with a user scripts folder, but I'm don't know much about that. I can't say for certain whether an app should or should not be able to execute a random binary inside its container (if that is what you mean by XPC sandbox folder). How would you get this tool installed in that location? That's the stumbling block here. You can run a system app (usually) via #1. You can run your own app via #2. You can run some user-specified app via #3. You're trying something else?

Why are you doing this? What are you trying to do? The "Apple Distribution" certificate is something that is only used to sign an app before distributing via the Mac App Store. Normally Xcode manages this and does all the signing for you. If you are building an app and feel the need to do something (other than git) on the command line, then, in most cases, you are doing something horribly wrong. Whether or not you can run the app locally is irrelevant. Since I don't know what you are trying to do, it is difficult to give you a straightforward answer. I can state with some certainty that you probably shouldn't be doing any of this.

It isn't properly notarized. There is a general misconception that running altool to submit a binary and staple a tick is "notarization". It is not. It is submitting a binary and stapling a ticket - nothing more. Your app is notarized if and only if you can then download it and it runs properly. What's wrong? Hard to say. The fact that you specifically mentioned "stapling" is a huge red flag. This means you aren't using Xcode at the very least. What else aren't you doing properly? Again, very hard to say. I've seen many similar posts here in the forum and I've got to say that I'm always surprised at what people are actually doing and expecting to work. In many cases, it turns out that the actual breaking problem is something very subtle. That doesn't mean notarization is a subtle process. It is drop-dead, fall-of-a-log easy. You have to work - really hard - to make it fail. I'll just skip to the punch line. Submit a DTS ticket and somebody from Apple will help you. You could also just use Xcode, but many people won't do that.

Is there no way to find threads you previously participated in, other than to bookmark them in your web browser or something? Nope. The only reference to my past activity seems to be on my profile... which only mentions the number of posts I made, but doesn't mention what or where they are or provide any way to find them. Yep. On the bright side (?), it is so difficult to find new threads in over 300 separate forums that you are very unlikely to actually participate in multiple forums. So just bookmark your favourite tags and go to those to see if there is any new activity in your threads.

I guess I will be Etresoft now. I need to use my Developer account to upvote or downvote. And I need 100 points to do that. <sigh> Those 971 points in the other account aren't going to help.