In macOS Tahoe 26.7 or Sequoia 15.7.5 (and probably other prior versions), when you install a .pkg, symlinks are followed: i.e. if your payload install a file to /Users/Shared/my-folder and, on the target volume, the /Users/Shared/my-folder item is a symbolic link to /Users/Shared/actual-folder, the file will be installed inside /Users/Shared/actual-folder. It used to be possible to tell the installation framework/mechanism not to follow symbolic links by using the followSymLinks attribute in the raw package PackageInfo file. And in this case, the symbolic link would be replaced by a real directory and the file would be installed where it was supposed to be installed. This attribute is apparently not taken into account anymore by the framework/mechanism. [Q] Is this on purpose or is it a bug (in shove for instance)? If it is on purpose, why was it considered a good idea to always follow symbolic links considering the security issues this can create?

[Q] Is it a known issue that the Xcode static analyzer hallucinates past results? Basically, the issue I've been observing for a few releases of Xcode now (including 27b) is that if you run a static analysis, fixes the reported issues and re-run a static analysis, you will get exactly the same results as with the first run. It's as if Xcode did not take into account the fixes. If you clean the builds (cmd + shift + K), and run the analysis again, this time, you will get up-to-date results.

In /usr/include/libproc.h, there are a few number of APIs listed as private but which are commonly used (e.g. proc_pidpath). I'm trying to figure out how the proc_listallpids API is supposed to be used. From the examples I'm seeing in open source projects, the idea is to: call proc_listallpids(NULL, 0) to get a hint about the number of pids currently existing. call proc_listallpids with an appropriate buffer and retry if needed (I guess if the number of processes grew more than expected between the 2 calls). OK. What I'm not getting is how the resulting array of pids is to be used. What I am observing is that the array of pids you get is a list of the existing of the existing pids in a descendant order. BUT after pid 0, there can be additional pids. Numerous projects are just skipping pid = 0, but are using the pids after 0 as if they were valid. From what I'm seeing these are not valid pids and the correct way to handle the array of pids is to stop at pid 0 (or 1 if you want to skip the "kernel"). [Q] Is the proc_listallpids like the proc_pidpath a Voldemort API? Everyone can see it but you are not allowed to discuss it and to get more info about it you need to contact DTS. Or is it possible to know the right way to use this API and its results?

In the System Settings > General > Login Items & Extensions - Extensions pane, when I select the By App tab, I can see multiple instances of extensions for different applications and sub-types. e.g. Books (from Apple) is listed twice with the Sharing subtype. For the specific extension I'm checking, I can see multiple instances listed for the File Provider sub-type. The number of instances does not seem to correspond to anything. There are 5 instances listed and it seems like these are not exact duplicates because when I disable one using the (i) dialog, the others are still enabled. This number (5) corresponds to nothing obvious: at one time, there is only 1 instance of the File Provider (a Finder Extension) installed. if I use the pluginkit command line tool to list the extensions, it only reports 3 known versions of this extension. As a developer I'm puzzled by this list with duplicates. As an end user, I'm totally puzzled by this list with duplicates. macOS Tahoe 26.5 (25F71) [Q] What is this list in the Login Items & Extensions pane supposed to represent? Is it known to be buggy when it comes to its contents?

Is there any plan to deanonymize in the near future ES_EVENT_TYPE_RESERVED_X where the range of X is [1, 8] ?

Are there workarounds for the following bugs in Xcode 16.3? I'm looking for workarounds instead of trying newer versions of Xcode because, from what I read, the Xcode release notes do not mention these issues being fixed. First bug: Resizing a NSSplitView in the UI Editor is buggy. When you try to use the divider, it just does not work as expected. In the case of a vertical split, the bottom view gets shrunk whatever you try to do. Second bug: When you type: (IBAction) in the source editor, you get the following buggy template (extra ')' on the right): - (IBAction)<#selector#>:(id)sender)

[Q] When is the kTCCServiceEndpointSecurityClient set by macOS and in which conditions? From what I'm gathering, the kTCCServiceEndpointSecurityClient can not be set by a configuration profile and the end user can only grant full disk access. I searched for documentation on Apple's develop website (with the "kTCCServiceEndpointSecurityClient" search) and did not get any useful result. Using a more complete search engine, or the forum search engine, only points to the old annoying big bug in macOS Ventura. The problem I'm investigating is showing a process being listed as getting granted kTCCServiceEndpointSecurityClient permissions in the TCC database when: it's not an Endpoint Security client. it does not have the ES Client entitlement. the bundle of the process includes another process that is an ES Client and is spawn-ed by this process but I don't see why this should have an impact. This process is supposed to have been granted kTCCServiceSystemPolicyAllFiles via end user interaction or configuration profile. AFAIK, the kTCCServiceEndpointSecurityClient permission can only be set by macOS itself. So this looks like to be either a bug in macOS, an undocumented behavior or I'm missing something. Hence the initial question. macOS 15.7.3 / Apple Silicon

I'm currently observing a problem similar to this thread https://developer.apple.com/forums/thread/737334 The difference is that this is happening after updating a system extension. Basically same error, sysextd complains it can not check that the system extension is notarized: macOS Error 3 + Error code=-67050. I think macOS (Sequoia 15.3.2 or 15.7.2 if it matters) is wrong in this case for the following reasons: when using spctl assess -t install, the system extension is reported to be correctly notarized. when restarting the Mac, the updated system extension is correctly checked and staged. if I run spctl assess before sysextd tries to check the system extension, it works. I'm currently thinking of 2 reasons why the check does not work: sysextd is somehow trying to work with a cached assessment that has become invalid after the system extension was updated. macOS needs way more time between the update of the files and the request to update the staged extension. I tried adding a 5-second delay. This does not seem to work or at least reliably. I tried just touching the system extension, no positive result. Unfortunately, in macOS Sequoia, it is not possible anymore to reset-default using spctl and see if it solves the issue, at least the next time the update is performed. [Q] Is there some magic operation that would help macOS correctly check the notarization of an updated system extension?

In the online documentation for InstallerJS, it is stated that the unit for the availableKilobytes property of the target field is kilobytes. Isn't it actually bytes because of a bug in the very first release of macOS that supported InstallerJS? [Q] Has there been a fix in the recent years regarding this property that would explain why the documentation says it's kilobytes? Even though at the time of this writing, the unit is still bytes when you call my.target.availableKilobytes I'm using this call to dump the value of this property in install.log: system.log(my.target.availableKilobytes + ''); Ref. https://developer.apple.com/documentation/installer_js/target/1811975-availablekilobytes (FB20448952)

[Q] Has there been a change in macOS 15.3.2 and later that can explain why some UDP traffic is not seen by some Network Extensions when it is in previous macOS minor and major versions?

[Q] How many instances of the same NEFilterDataProvider subclass can there be in a single running Network Extension at any given time? I would expect that there can be only 1 instance but I'm looking at a memgraph where 2 instances are listed. As it's the Network Extension framework that is responsible for creating, starting and stopping these instances, this is rather strange.

I have 2 basic questions related to Launch Constraints: [Q1] Are Launch Constraints supposed to work when SIP is disabled? From what I'm observing, when SIP is disabled, Launch Constraints (e.g. Launch Constraint Parent Process) are not enforced. I can understand that. But it's a bit confusing considering that the stack diagram in the WWDC 2023 session is placing the 'Environment Constraints' block under SIP, not above. Also the documentation only mentions SIP for the 'is-sip-protected' fact. [Q2] Is the SpawnConstraint key in legacy launchd plist files (i.e. inside /Library/Launch(Agents|Daemons)) officially supported? From what I'm seeing, it seems to be working when SIP is enabled. But the WWDC session and the documentation don't really talk about this case.

I just noticed that when you check the online documentation for Foundation using the delicious Objective-C flavor, some values are no more the expected ones: https://developer.apple.com/documentation/foundation/filemanager/copyitem(at:to:)?language=objc#return-value true if the item was copied successfully or the file manager’s delegate stopped the operation deliberately. Returns false if an error occurred. Considering that a BOOL used to be YES or NO for the last quarter of a century, I have the following question: [Q] What is the idea behind the disturbing changes of the Objective-C documentation?

The newly introduced enum value NEProviderStopReasonInternalError (macOS 15.1) is not documented (assuming being documented means having at least a sentence describing the enum value). [Q] What kind of situation is the NEProviderStopReasonInternalError enum value supposed to describe? An internal error that requires to try to restart the provider? A fatal error that requires to reinstall macOS? A fatal error that requires to purchase a new Mac? Something less serious but with a human friendly description in the headers (I'm using Xcode 16.2) and online documentation.

In the good old days, it was possible to retrieve dynamically the UnknownFSObjectIcon.icns icon using: [[NSWorkspace sharedWorkspace] iconForFileType:NSFileTypeForHFSTypeCode(kUnknownFSObjectIcon)]; Now, this solution is considered to be deprecated (but is still working) by recent macOS SDKs. [Q] What is the modern equivalent of this solution? Notes: Yes, reading the file directly works but is more fragile than using a System API. Yes, Xcode suggests to use the iconForContentType: method but I haven't found which UTType should be used.