I can do the same thing using fork.
The system attaches entitlements to a process when it execs, so a simple fork doesn’t trigger this issue. A
posix_spawn is (by default) a fork/exec, and it’s the exec that’s causing you problems.
I am working on a cross-platform infra project. We try to follow
things we have done under linux.
macOS and Linux have
very different architectures when it comes to GUI process management. For example, macOS works hard to prevent the user from running a second instance of an app, but instead expects a single instance of the app to do all of the app’s work.
So, why do you want to run multiple instances of your app? What’s the higher-level goal here?
My experience is that folks often run into problems like this when they’re working at the wrong level of abstraction. For example, let’s say you’re building an app and you want a helper process to be responsible for the content of one of its windows. Having the helper process display a window directly (using
NSWindow) is definitely a mistake on macOS. For example, when the user clicks on the app in the Dock the system brings all of the app’s windows to the front but this won’t include the helper process’s window because it’s not part of the app. And let me stress that this is just an example; there are many other places where things will go wrong.
A better alternative is to have the helper process render to an
IOSurface that it shares with the app. The app still owns the window, but the
IOSurface allows it to efficiently display content generated by the helper.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"