We were just bitten by this same issue. Three years and the documentation is still apparently wrong. 😠 Deleting the entitlement solves the problem. I'm glad to have stumbled onto this discussion. Filed FB13758049.

Thanks. I've procured a Developer ID-signed release build that elides the step of replacing the container app (instead I first invoke the latter to activate the extension prior to starting the daemon)—and this works. Interestingly however, when I then tried to re-prove the original scenario by cp -a a locally-stashed copy of the container app into /Applications and re-activating the extension without disturbing the running daemon, it continued to work. (I expected this procedure to be tantamount to what the daemon was doing initially, and that once I replaced the container app the XPC would fail. It did not.) Therefore my hypothesis of container app replacement being the issue seems to be incorrect, or at least incomplete. On a related note, this same behaviour appears to now also affect Monterey, as of the 12.6.8 update released this week. (Prior, this MDM installation worked on Monterey but not Ventura.) Can you speak to whether the recent security updates might affect this area?

(Pardon my delay getting following up; I was away for a couple of weeks.) There must be at least three components in play here: Your daemon Your sysex, which includes both NE and ES subsystems Your sysex’s container app Right? That's correct. If you (temporarily, just for testing) disable that part of your product, does TCC behave itself? Indeed, when I rebuild all the components on my development machine with that bit patched out, it does! However, when I then do same with the original configuration, it actually also seems to work. You'd be forgiven for assuming this is what was doing heretofore, but in fact I'd been testing with the existing production builds. I'm sort of working at arm's length on this, because the production build pipeline is under someone else's control, and don't personally have the Developer ID cert for this org in order to be able to simulate a complete release build locally. Could the deployment signing or provisioning be playing a role here?

You mean “via launchd”, right? Whoops! Yes. The daemon is added using launchctl. So where does your Endpoint Security client code live? In the network extension (which also contains NEFilterDataProvider and NEFilterPacketProvider implementations). Its entitlements include: com.apple.developer.endpoint-security.client = true com.apple.developer.networking.networkextension = ["content-filter-provider-systemextension"] I should note that the architecture is slightly strange in that each time the daemon is launched it first [re-]downloads the container app from a remote server, installs it in /Applications (possibly overwriting the prior version if there was one), and then invokes it to solicit the user interactively to grant the permissions (if not already in effect). Nonetheless it looks like the extension is launching properly; the Console.app shows a continuous spew of its log messages indicating its event ring buffer is full (due to not being serviced by the daemon).

I just came across the same problem while trying to implement NSTableViewDiffableDataSource, and figured out the reason: NSTableView is misspelling the selector. Rather than the advertised NSTableViewDataSource method tableView(_:draggingSession:willBeginAt:forRowIndexes:), the table view is instead attempting to call tableView(_:draggingSession:willBeginAtPoint:forRowIndexes:). Note that willBeginAt: is spelled willBeginAtPoint:. I figured this out by bottlenecking responds(to:) to examine what protocol methods the table view was trying to interrogate of its data source. Implementing a method with the misspelled name makes drag & drop work as it should. I don't know why a regular NSTableViewDataSource implementation doesn't suffer from this problem. Besides this significant and strange bug, perhaps a larger problem is that NSTableViewDiffableDataSource was designed without any regard for drag & drop support, requiring the developer to write a springboard subclass as you, I, and surely others have had to do.

Hi Dragan, I was faced with the same issue, and came across your posting while searching for an approach. I want to drag whole-row images regardless of which column was targeted by the mouse. Building on techniques described at https://www.mail-archive.com/cocoa-dev%40lists.apple.com/msg108722.html (for some reason this web app won't let me format that as a link) and here, I came up with this: func tableView(_ tableView: NSTableView, draggingSession session: NSDraggingSession, willBeginAt screenPoint: NSPoint, forRowIndexes rowIndexes: IndexSet) { session.enumerateDraggingItems(options: .concurrent, for: nil, classes: [NSPasteboardItem.self], searchOptions: [:]) { (draggingItem, index, stop) in // Get the row index for this drag item. Could cheat and map `index` to `rowIndexes`, but this is cleaner. guard let pasteboardItem = draggingItem.item as? NSPasteboardItem, let rowIndex = pasteboardItem.propertyList(forType: "com.example.RowIndexPasteboardType") as? Int else { stop.pointee = true return } // Compensate for the dragged column offset. let dragPointInWindow = tableView.window!.convertPoint(fromScreen: screenPoint) let dragPointInView = tableView.convert(dragPointInWindow, from: nil) let columnIndex = tableView.column(at: dragPointInView) let columnRect = tableView.rect(ofColumn: columnIndex) draggingItem.draggingFrame.origin.x -= columnRect.origin.x + 7 // The 7px error is a mystery to me (on 12.6 at least). // Register a provider that will render a bitmap image of the whole row. draggingItem.imageComponentsProvider = { guard let rowView = tableView.rowView(atRow: rowIndex, makeIfNecessary: false), let imageRep = rowView.bitmapImageRepForCachingDisplay(in: rowView.bounds) else { return [] } imageRep.size = rowView.bounds.size rowView.cacheDisplay(in: rowView.bounds, to: imageRep) let image = NSImage(size: rowView.bounds.size) image.addRepresentation(imageRep) let component = NSDraggingImageComponent(key: .icon) component.contents = image component.frame.size = image.size return [component] } } } It seems to work well enough, and is implemented in the data source (no subclassing required). How's it grab ya?

@Matt: No it doesn't; NEDNSProxyManagerError is an enum representing error codes in the NEDNSProxyErrorDomain, but the error returned is not in that domain. (Even if it were, its integer value exceeds the enum.) @Quinn: Thanks for confirming this. Filed FB12017478.

Has this situation changed in 2022 with iOS 16 and/or policy reconsiderations? The reference linked above no longer appears to contain the cited language, and notes that I made earlier this year (but prior to WWDC) indicate the same statement while Google no longer returns any such results.

Thanks for that suggestion @DaddyWarbucks. I never got around to trying it again in conjunction with the Xcode beta, but I am happy to report that the over-the-air install finally worked this week with beta 5. Maybe they fixed something in the bootstrapping. Of course, the release notes make no mention of it, nor has there been any comment whatsoever on my ticket filed in June (FB10421553). 🤷🏼‍♂️

Thanks Matt for reminding me about Developer Mode; that indeed was the impediment to debugging locally. (It's been over a year since I've had occasion to work on this extension, and was doing so on another machine, so I'd forgotten all about that necessity.) Having done so, the call succeeds and ES seems to work. Something remains amiss in that our current production version does not work properly under Ventura, but it's been difficult to triage the source of the problem because I unfortunately do not have debug symbols for the deployed build. (I've also observed some anomalous behaviours of System Settings; e.g. it will sometimes put up an empty alert after authorizing the extension.) If I'm able to narrow any of this down I may return with further questions.

Are you able to debug a fresh build? When I attempt to do so (build & run from Xcode), the system throws an alert “App containing System Extension to be activated must be in /Applications folder” when attempting to activate the extension. Obviously that would be expected in a production build, but this happens in debug when building with development provisioning on Ventura; the same does not occur on Monterey, where the development build will load and activate from its build location. My recourse in the interim has been to drag the build product into /Applications, launch manually, and then attach the debugger. Despite this, even after allowing the extension in the “Privacy & Security” panel of System Settings, and ensuring that both entries are enabled under Full Disk Access (yes, there are two, identically named; one with the app icon, and one with a lego brick extension icon), the call to es_new_client() still fails. Perhaps I have something wrong with the debug workflow on my Ventura machine, but even so, the current production version of the app (built months ago) does not activate under Ventura either.

Following up on this, I sought advice at a WWDC22 Security Lab this week. The engineer I spoke with (Pepjin B.) advised filing a Feedback Assistant report describing our needs, and suggested it would be most effective to do so from an AppleSeed For IT managed Apple ID. As I don't have an AS-for-IT account myself I had a colleague do so on my behalf; the ticket is FB10144188. Looking forward to what may come of this!

I erred in the title of this post; it's actually an A12X, but it appears that they share the same .ipsw image. The model (as per the back shell) is A1980. I tried again via both Finder and Configurator, to no avail (ensuring to try a full restore rather than an upgrade). No dice. Bricked, and had to reinstall 15.5 again. It seems that this iPad model is unsupported, despite the documentation.

The user's “Edit Profile” page offers a suite of checkboxes, purporting to offer e-mail notifications: (I don't know how long these have existed, but I discovered them a couple of days ago when tweaking my profile.) In any case, they don't seem to work. As evidenced by the screen shot, I have them all turned on; however, I received a reply to a recent forum posting “about 5 hours ago” (per its dateline), but haven't received any e-mail. (I examined my server logs, and no relevant inbound SMTP attempts were made.) Is there a significant delay in notification, or is this feature broken?

The objective here is to passively observe flows (or packets), inbound and outbound, for the purpose of auditing and security monitoring. I can see that a packet tunnel provider sans VPN endpoint won't afford this (even setting aside whether or not it's expected or recommended), without a means to redeliver the packets to the physical interface, given that binding to a raw socket is prohibited on iOS. It also appears that it's not possible to set up an IP-level NWConnection (by trying to set a nil defaultProtocolStack.transportProtocol on its NWParameters, for example, which has no effect). Can you suggest another approach?