To add something that may be relevant after further testing... On another dev computer that our team has (with Mojave), stapler does work.  I don't see any relevancy. You are talking about doing development on operating systems that are 2 and 3 major versions behind. Don't do that. If you see a problem on Big Sur, that's something you need to worry about. Don't use 10.13 or 10.14 for anything except testing.

What is your question? Are you talking about Finder aliases? They are what they are - Finder aliases. They are features of the Finder and nothing else works with them except for the Finder. You can create symbolic links instead.

Your question doesn't make any sense. Can you re-phrase?

Unfortunately, the Apple Developer Forums Usage Guide specifically requires that we only discuss "Only discuss public, supported APIs." The Apple Mail Plug-in API is a strange one. No public API exists, but there is a setting in Mail preferences for plug-ins. But if you don't get any replies to your question here, this might be the reason.

Don't worry about iOS 10. That's ancient.

New projects have the sandbox turned on by default. The sandbox won't let you create an executable.

Do any of these VM products let me run another macOS while not doubling my RAM requirements? In other words can I tell them to share the parts of the system.   No. That's how they work. If you have a modern Mac with 16 GB RAM and an SSD, then you won't have any problem. That is really the minimum requirements just to run Xcode anyway. So there is no reason for a Mac developer not to use VMs. The biggest problem is disk space because a Mac VM with a modern operating system will take about 40 GB of storage. Another problem is system stability and system modifications. I use Parallels Desktop from the Mac App Store. It runs great and no kernel extensions are required. I was lucky enough to get it when it first came out, so I'm running it for free. You will have to pay a subscription. (In all fairness, I do test each update to see if it is any better than the free version I have. Haven't upgraded yet. The Mac App Store version 1.3.3 has been rock-solid. It is one of the few products I can't recommend strongly enough. The current version is good too, but I wasn't able to get my 10.9 VM working in version 1.5. That might not be a problem for you.) It is really convenient to just reset the VM. (Alas, the snapshot feature is harder to use in version 1.5.) Is this what Docker does? I've not yet used it, but it sounds like maybe I want a "container" rather than a full separate VM. ? No. Docker is something else completely. Docker only runs Linux containers anyway. And learning how to use Docker will suck up months of your time.

How can I resolve this? You answered your own question... install Python pkg from the website

My experience is limited to signing and, recently of course, notarizing Developer ID apps using the command-line utilities, overwriting any codesigning by Xcode. Xcode can notarize apps by itself. Use the "archive" feature and choose "upload". It does it all for you. I can't comment on any 3rd party apps. You should assume that using a Mac for developer is simply going to trash many system databases. In most cases, that doesn't cause any problems, especially if your app is a self-contained app that only deals with its own data. But if your app interacts with any system services, such as including a QuickLook plug-in, just as one example, then you can expect problems. The bundle ID is a critical identifier. Never ever use "com.mycompany" for anything.

I want to check network connection on mac os without ping to server(like "google.com"). That's good, because I'm pretty sure that this kind of use would be against Google's Terms and Conditions. What you should do is just assume that all network connections will succeed. Then, if they don't for some reason, you handle the error gracefully.

The codesign tool allows you to embed entitlements inside a command line tool. I don't know for certain if you can enable the sandbox that way, but there are suggestions on the internet that it is possible. However, I wouldn't advise trying it in this situation. Unless a tool is specifically designed to run in the sandbox, then it probably isn't going to work properly. A better idea is to just install a virtual machine and run these things inside that. You can restrict how much access the VM guest has to the host.

What have I done wrong? It's hard to say. This is not something that Xcode normally does. What are you using as the Bundle Identifier for this app? Are you reusing com.myCompany.MyOtherApp? Bundle identifiers have to be unique. On a developer's machine, they never are, so you should always tests in a pristine setup like a virtual machine. Depending on how your app is being launched, the bundle identifier can change the behaviour and cause some other binary to be executed instead.

I am working on an application with multiple helper apps and tools with a fairly nested structure Why? I'm not even sure this will work at all via the Mac App Store. The documentation says you can have other, standalone executables in the MacOS folder, but I don't know if other app bundles qualify. Technical Note TN2206 also specifically says you can have "helper apps and tools" inside the "Contents/Helpers" directory. Again, I'm not sure about actual app bundles though. Even if it is allowed, it seems to be risky. Few people do this. So if there is a problem, you are the only one who will notice. Could these apps be changed to single-file tools or XPC bundles? It is good that you are comparing to what Xcode does. Does that mean you aren't actually using Xcode? That's a Red Flag. But if you can hack up a reasonable facsimile of your app and observe how Xcode signs it, you should always copy what Xcode does. Ignore what you see on the internet about it unless it was written by eskimo. After checking, I see that you are actually referencing one of eskimo's how-to threads. So again, you're on the right track. In that thread, eskimo is specifically talking about signings a complex executable not using Xcode. You haven't posted all of Xcode's operations, but it looks like Xcode is doing the same thing by signing a deeply tested framework tool first. That's a more difficult question. I don't really know the answer. Normally, for the Mac App Store, you just sign your app and submit. Then Apple re-signs and publishes. If you aren't using Xcode, then you are opening yourself up to the possibility of a code-signing error on submission. Hopefully the stand-alone submission tool will catch that problem. If not, hopefully App Review will catch it. Mac App Store apps don't have to be notarized, or even use the hardened runtime. But if you want to turn all those things on anyway, it won't hurt. Plus, it seems logical that the hardened runtime will be required in the Mac App Store at some point. Perhaps it already is and I just haven't noticed it. My Mac App Store app has the hardened runtime enabled. I think I must have done that myself when I started notarizing the non-Mac App Store version, just to be on the safe side. I don't know the exact answer for this either. However, it should be easy enough to test. I can tell you that you shouldn't use symlinks. Even if it worked, don't do that. The example that you would want to follow here is LoginItems. LoginItems are full app bundles stored in "Contents/Library/LoginItems" of your app. While I don't use them in my own app, I have other apps that do. And I can see that those apps definitely share frameworks with the top-level app. The tricky part is the linking. When I do an "tool -L" on the login item, it reports that the frameworks are referenced directly from "@rpath" without any ".." parent links. So this LoginItem executable has the correct RPATH encoded in it. It is possible that using ".." might still work, but I strongly recommend using the correct RPATH. This might require some research. It is the kind of thing that Xcode does for you. If you are doing it on your, you will have to figure it out on your own. In terms of tricky linking, RPATH is where it's at. You may need to use the "install\_name\_tool" tool to set those paths inside the executable. You might need the "-headerpad\_max\_install\_names" linker flag too.

The short answer is "I don't know". A long time ago, if I remember correctly, I used package manager and I could install into the user's home directory, but it still asked for admin credentials, even though it didn't need them. Why would you need that installing an app anyway? You can just do anything you need on first run.

What is this conflicting information? You aren't going to find any notarization tools in Xcode from before notarization existed. Apple isn't going to re-release those old versions. You can notarize existing binaries that are built for 10.9 or later, but you have to have a recent version of Xcode.