{"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...

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.

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.

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.

"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).

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.

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

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

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

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.