“testflight the requested app is not avaliable”

It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits. (Fortunately you @ mentioned me, otherwise I would’ve never seen this.) Do you know if it's still true that NEDNSProxyProvider is incompatible with Always-On VPN? This has not changed. When the Always On VPN [1] session activates, it specifically stops any existing sessions with the reason NEProviderStopReasonSuperceded. This includes sessions for normal VPN, Personal VPN, DNS proxy, and content filter. AFAICT this interaction isn’t documented in the Apple Platform Deployment guide, and I encourage you to file a bug against the doc to improve that. Please post your bug number, just for the record. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] Hmmm, sometime in the last 9 years Always On VPN lost its hyphen.

Hi Quinn and those following along: The just released 26.5 beta (build 25F5042g) seems to - mostly - solve FB21858319 (After macOS reboots, multicast traffic might not be received by app even with Local Network permitted), what a relief! Now after a reboot, apps directly receive Local Network traffic, no need to toggle permission off and on or restart the app. I've tested a couple of apps across many reboots, seems to behave as expected. One issue (at least) remains: when multiple versions of the app coexist on a machine, the latest installed version won't receive Local Network traffic after macOS reboot until its socket is closed and reopened. The previously installed versions receive Local Network immediately, only the latest version needs a socket restart. It's already much more stable than previously (users had to toggle off and on the Local Network permission and restart the app for traffic to appear), we can now programmatically res

same issue happening no message nothing its so hard to debug

Thanks for all the extra info. Just for the sake of debugging, I want to focus on this: [quote='882548022, PavanGulla, /thread/821002?answerId=882548022#882548022, /profile/PavanGulla'] Both didReceiveMetricPayloads: and didReceiveDiagnosticPayloads: are implemented [/quote] When an app crashes, MetricKit delivers the diagnostic playload immediately after the user relaunches the app. This is great way to test whether the basics are working: Start your app. Kill it from Terminal: % killall -ABRT Test821002 replacing Test821002 with the name of your app. Wait for the crash report window to show up, and then dismiss that. Relaunch the app. You should see the diagnostic payload delivered promptly. Please try this and let me know what happens. ps I realise that you’re primarily interested in metric payloads rather than diagnostic payloads. The purpose of this test is to confirm whether the basics are working. If they are, we can return to the metric payload issue. But i

[quote='882440022, KenH-Rave, /thread/821074?answerId=882440022#882440022, /profile/KenH-Rave'] Directly to customers. [/quote] OK. So you’re signing your code with a Developer ID Application signing identity? And, if you have any installer packages, you sign those with a Developer ID Installer one? If so, I wouldn’t anticipate you hitting any problems with updating your Individual team to an Organization team. Developer ID signing identities are very stable. We don’t revoke them willy-nilly, because that would ‘break’ shipping products [1]. So your existing shipping code should continue to work. I’m not 100% whether the existing signing identities will continue to work for new code. I suspect they will. But even if that’s true, it’d make sense for you to generate new ones because your existing ones have your Individual team name embedded in them, and it’d be nicer if you they had your Organization team name instead. Note that you have to be careful when creating new Developer ID signing ide

Hi Quinn, I have an additional clarification about the logs from the target Mac, now that I’ve instrumented the code more precisely. On this machine I actually see two different behaviours for NEAppProxyUDPFlow.writeDatagrams: In the main DNS path (NEDNSProxyProvider → NEAppProxyUDPFlow → TCP upstream via SwiftNIO), writeDatagrams always fails with The datagram was too large, even for very small responses (for example 33, 50, 66, 67, 147, 193 bytes). The only writeDatagrams OK entries I see in the logs come from a separate passthrough handler that talks directly to a fallback DNS server (8.8.8.8) and uses a different code path. So, for the specific flow we are discussing (the proxy that forwards DNS over TCP to our upstream and then sends the response back to the client), writeDatagrams never succeeds on this Mac: every attempt ends with The datagram was too large, regardless of the actual payload size. This seems to match what you described about the subtle differences between endpoint types and how the depr

If you use Apple Development signing for your day-to-day development, you can set up a reasonable debugging workflow. I explain how I do this in Debugging a Network Extension Provider. This still requires you to deactivate and then reactivate your sysex every time you change your code. That’s necessary because activating a sysex copies it from your app to a protected location on the file system, so without reactivation you end up running your old code. Debugging a Network Extension Provider discusses two key techniques for reducing the hassle associated with this process, namely: Unit tests Well-considered logging Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='882567022, WangZiYuan, /thread/817264?answerId=882567022#882567022, /profile/WangZiYuan'] But when I disable the content filter, the process does not stop. [/quote] OK. That’s not unexpected, give my understanding of how NE relates to the sysex infrastructure. [quote='882567022, WangZiYuan, /thread/817264?answerId=882567022#882567022, /profile/WangZiYuan'] When I manually kill the original process … the process ID definitely changes, but the issue persists. [/quote] Blat! I was hoping that the bogus state would be stored in the sysex process, and thus this would clear it. Given this finding, the only path forward I see is a bug report. [quote='880612022, kunal_a, /thread/817264?answerId=880612022#880612022, /profile/kunal_a'] I submitted FB19734992 [/quote] Thanks. I can’t go into all the details here, but the executive summary is: For internal reasons, we have an internal bug tracking the fix (r. 172870187). That fix is not in any currently released or seeded version of mac