In my project I have a host application and a husk application.
What I want to do is, every time the user launches a new view in the host application, I want to create one more dock icon by launching another instance of husk application. Then the husk application behaves like it is the view itself by monitoring the event of click/quit and send them to the host application through XPC.
The XPC tutorial tells me an XPC service embedded in an application is invisible to the processes outside the bundle. To communicate between two foreground applications it seems that I need to create a third helperTool/agent/daemon which venders a Mach/XPC service.
But I wonder if I can put husk application inside the bundle of the hose application. So they can directly connect to the XPC service which is also embedded in the same bundle.
If the answer is no, maybe NSDistributedNotificationCenter is much better and simpler in my scenario?
Cecil1345
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
Post
Replies
Boosts
Views
Activity
I am developing a cocoa app for macOS and was manipulating the app's dock menu.
I realize there are universal menu items such as "Options", "Show All Windows" and "Hide" in every app's dock menu.
In my case, those items/buttons do not work so I want to remove them. For example, "Options -> Keep In Dock" won't work because the executed application is a cloned one and will be deleted after quit(I know it is weird but that's what the app does).
Is there anyway that I can remove one or all of them? I think it might be impossible but a consultation won't do any harm.
On our remote crash collect server(Microsoft AppCenter) we found a lot of crashes happened when executing "[AVCaptureDevice defaultDeviceWithMediaType:AVMediaTypeVideo]". Unlike other issues, 100% of this crash happened only after macOS Ventura. We cannot found any case happened on macOS Big Sur or Monterey. We do not know the steps to stably reproduce this issue. The Count-to-Users ratio is relatively much higher than other crashes. So we suspect the probability to reproduce this issue is high only on specific Mac hardware. Our feedback from customers has opened lots of tickets on this crash. We would like to know if this is a known issue of macOS Ventura. Have Apple's macOS developers seen similar crashes on Ventura?
crash report sample1.txt
crash report sample2.txt