Step 4 is just repeating step 3.So if you send the same message 2 times, the first time, the notification is not displayed. The second time, the notification is displayed.

Delaying either in the daemon or in the agent does not solve the issue.

As I'm observing other issues with notifications, I'm starting to wonder whether I'm not misinterpreted the documentation for the identifier property of the NSUserNotification object.According to the documentation:@property(copy) NSString *identifier;"The identifier is unique to a notification. A notification delivered with the same identifier as an existing notification replaces the existing notification rather than causing the display of a new notification."Note: The application/agent is set to display notifications as banners (by default).The way I understand it is, in the context of banners:When a notification with a unique identifier is delivered:- if a notification with the same unique identifier has been delivered and its banner is still visible, the visible banner will be replaced with the new one.- if a notification with the same unique identifier has been delivered and its banner is no more visible, a new banner will pop up.What I'm observing:- if a notification with the same unique identifier has been delivered and its banner is no more visible, no new banner pops up.And it looks like I'm facing the same case as these persons:https://stackoverflow.com/questions/38465355/objectivec-how-to-use-nsusernotification-identifier-property

From the technical side of this:is there something that prevents you from renaming the menu items in the xib or .string files?

This could be the case you're describing precisely in the post you linked to.But I still see 2 issues with having the notarization process requiring changes to the Apple Developer Program License Agreement being accepted:- from what I observed, it was still possible to codesign things. So why should the notarization process be impacted? (N.B. This is not a request to break the codesigning requests too).- changes to the Apple Developer Program License Agreement can not be anticipated by 3rd party developers. So, blocking the notarization process (until the changes are accepted) will block/break automatic processes that make notarization requests. Without reasonable prior notice.

"The only supported way to build a KEXT that loads on 10.13 is to use a version of Xcode that has the 10.13 SDK built in."This wording is quite confusing.You can build a KEXT that loads on 10.13 using a version of Xcode that has the 10.9 SDK built in or a version of Xcode that has the 10.14 SDK built in for instance. This works fine for Network Kernel Extensions for instance.You actually just need to have a non hacked version of the Xcode application (*).* which can codesign Kernel Extensions correctly (notarization support is not taken into account here since it's 10.13).

1. Just have only one column in your NSOutlineView.2. Use the Xcode view inspector or change the alignment dynamically on the appropriate NSView if your outline view is view based."As far as I understand, by default the column is set to fit the content of the cells underneath and will resize itself if the data added will be wider."Nope. The column width does not dynamically adjust to the contents of the cell. At least that's how it works when AutoLayout is disabled. And I don't remember it working differently when AutoLayout is enabled.

This has been a known security flaw of Gatekeeper since the beginning. It relied on the quarantine flag. So if you downloaded an archive or binary with curl, Gatekeeper did not see it.But… at WWDC 2019, IIRC, it was said that the checks would be performed even if the quarantine flag is not set and that checks could be performed after the first launch of the application.Check Session 701. If checking the Slides, check pages 23 and later.

It could be possible to avoid to repackage the original package by ruining the original package on purpose.Since the package is a xar file, it could be possible to:1. edit the the first 4 bytes of the original .pkg to hide its file type to the notarization server.2. from your pre or post-installation script, fix the first 4 bytes by putting back the "xar!: data.3. then you can call the installer command line tool.Side Note:Do you really need the original .pkg to be part of your payload? If it's there only to be able to run installer and then remove the original .pkg, it might be better to have the original .pkg be part of the resources of your own package.

{"timestamp":"2020-xx-xx 06:30:38.75 +0000","bug_type":"***","os_version":"Mac OS X 10.15.x (xxxxx)"}{"macOSProcessedStackshotData": "averylongstringfullofdata","notes":"xxxxxx","macOSPanicString":"what looks like to be interesting"}System Profile:Network Service: Ethernet, Ethernet, en0Thunderbolt Bus: iMac, Apple Inc., 41.3Boot Volume File System Type: apfs...

> Why do you want to do this?I have 3 processes (launch daemon : pLD, Front-End: pFE and another process : pO).pLD can be launched either by pFE or pO.If pO launched pLD, when pFE is launched, it should display a modal alert informing that pLD is running and that pFE will quit. Also pO can not launch pLD if pFE is running as usual.Unfortunately NSRunningApplication API is not part of Foundation and not powerful enough to handle this.

OK, let's call this closed clamshell mode if this is the official name.In the case I'm describing there is a screen (the Screen Sharing.app window on the other Mac) to show them. Otherwise I wouldn't notice they are not displayed.I understand your argument but then if we follow your logic, why would there be something displayed in the Screen Sharing.app at all then?

Are you suggesting to parse the output of launchctl list (*) and check whether there is a pid for the appropriate label?From what I'm quickly seeing, it requires to execute the command as root. * or check the open source implementation and do it more reliably.

Yes, pFE or pO sends a XPC message to pLD XPC listener to do something and launchd will launch it if it's no already running.

Front-End: there can be only one instance of pFE running (via the LSMultipleInstancesProhibited Info.plist key).The other process pO that can launch the daemon pLD is either a launchd agent or another launchd daemon.Supporting multiple front-ends would definitely be the solution but that would require to revisit a good part of the UX. And anyway I would still need to know whether pLD is running to avoid enabling the appropriate push button in the UI (otherwise this would end up with a Windowsish UI where you click on an enabled button and you are told that this action can not be performed because it has probably been already been triggered by another process).As I somehow mentioned, I could still send a XPC message to the daemon to know what it's currently doing. But that could result in launching it and launching it would create useless disk activity and consume CPU resources to initialize the daemon to terminate it almost immediately.