hi, We have created following apple bug - FB22708922 with help of our team. Pls help to fix the issue.

Thanks for the guidance on the logging commands. A couple of quick questions before I share the logs: 1. Log collection approach — did I do this correctly? Since the device is user-enrolled (Intune) and the standard user is not in the sudoers file, here is the exact sequence I followed: Logged in as admin, ran the two defaults write commands to enable NE debug logging Switched to the standard user login and reproduced the VPN consent prompt Switched back to the admin account to collect the NE log — the standard user does not have permission to read the NE log file either Is this the correct approach for collecting NE debug logs for a standard user repro? Or does the debug log need to be collected from within the same user session where the issue occurs? 2. Clarification on our app's launch and tunnel behaviour: Our container app is a background menu bar app — it launches automatically at login as a Login Item and runs silently. The user never explicitly opens it. startVPNTunnel() is called programmatically by the app after authentication completes.

We have filed FB22433770 (https://feedbackassistant.apple.com/feedback/22433770) as an enhancement request based on your suggestion. Two follow-up questions: While exploring alternatives for our NE process, we found that Mach APIs like task_info and proc_pid_rusage can be called directly from within any process including root-context ones, and give similar metrics — CPU time, memory footprint, disk I/O. Does MetricKit also use these same APIs under the hood, with metrickitd adding the scheduling and structured delivery on top? Is there an Apple-recommended approach for metrics collection for root-context processes or Network Extension processes in general?

Hi, We installed again via the same full PKG installer. On the very first launch after this second install, we received approximately 48 hours of past metric payloads through pastPayloads. We are not sure what was different between the two full installs. Is there something on the system side that could cause the first install to not deliver payloads, and then a subsequent install to start delivering them? Diagnostic payload test results — following your suggested steps: Host app (UI process): Launched the app Ran: `killall -ABRT HostApp Process Dismissed the crash report window Relaunched the app ✅ didReceiveDiagnosticPayloads: was called promptly on relaunch. Network Extension (tunnel process): Ran: `sudo killall -ABRT NEProcess Dismissed the crash report window Waited for the tunnel to restart automatically ❌ No diagnostic payload was delivered. didReceiveDiagnosticPayloads: was never called in the NE's subscriber. So, could u comment if MetricKit works for NE Process? Are they any additional steps to be followed to make it work for NE process?

Thanks for looking into this. Here is a complete summary of our setup and what we have confirmed so far. App configuration: macOS app distributed via Developer ID (PKG installer) — not the Mac App Store Host app runs as a menu bar agent (LSUIElement = YES in Info.plist) NSApplicationActivationPolicy = .accessory The app runs continuously as a login item — it is always alive Network Extension is a System Extension (NEAppProxyProvider), always running alongside the host app What we have implemented: MXMetricManager.shared().addSubscriber(self) is called in applicationDidFinishLaunching in the host app — as early as possible A separate MXMetricManagerSubscriber is registered inside the Network Extension process at tunnel start Both didReceiveMetricPayloads: and didReceiveDiagnosticPayloads: are implemented On startup we also drain pastPayloads and pastDiagnosticPayloads to catch anything queued while the process was not running The subscriber object is kept alive for the full lifetime of both processes What we have confirmed: Xcode's "Simulate MetricKit Payloads" works correctly in the host app. Our delegates fire, payloads are received. The code is correct. Real production payloads: zero callbacks after 24+ hours in both processes i.e Host app and NE process Our questions: Does MetricKit's real 24h payload delivery require App Store or TestFlight distribution? We are using Developer ID — does metrickitd require an App Store receipt to mark an app eligible for delivery? Does metrickitd deliver payloads to LSUIElement = YES menu bar agents (.accessory activation policy)? Since these apps never become the "active application" in the OS sense, we are concerned the delivery trigger may never fire for our process. If both of the above are blockers — is there any supported path to get real MetricKit payload delivery for a Developer ID distributed, LSUIElement menu bar app with a System Extension?

Also one more point, when i integrated metric Kit and used Xcode to simulate MetricKit payloads, i was getting the callback i.e func didReceive(_ payloads: [MXMetricPayload]) Main issue was that when i launched my app with changes and waited for more than 24 hours, but i did not get any callback, so wanted to know if it works on background apps or not? Also does it work on MacOS or not? Could u pls help to answer it