“eskimo”

[quote='882729022, PavanGulla, /thread/821002?answerId=882729022#882729022, /profile/PavanGulla'] we received approximately 48 hours of past metric payloads [/quote] Oh, interesting. I’m not 100% sure what’s going on here but this behaviour doesn’t surprise me. Internally, MetricKit uses an XPC activity to drive metric delivery [1], and XPC activities a very much a best effort kinda thing. [quote='882729022, PavanGulla, /thread/821002?answerId=882729022#882729022, /profile/PavanGulla'] could u comment if MetricKit works for NE Process? [/quote] Well, I think you have pretty solid evidence that it doesn’t (-: I’m going to talk about what’s going on in a sec, but before I do that I want to give you some concrete advice: If you want MetricKit to work in your NE system extension, I encourage you to file an enhancement request that describes your setup and why MetricKit is important to you. Once you’re done, please post your bug number here, just for the record. As to why this doesn’t work, consider this: % find /

Interesting. Honestly, I’m skeptical that the specific flavour of API you’re using will affect this. The APIs you call are just wrappers that convert the old flavour of endpoint to the new flavour, or vice versa. For example, the -writeDatagrams:sentByFlowEndpoints:completionHandler: method is marked as ‘refined for Swift’ [1] and then there’s a Swift version that looks like this: func writeDatagrams(_ array: [(Data, Network.NWEndpoint)], completionHandler: @escaping (Error?) -> Void) { let datagrams = array.map { $0.0 } let endpoints = array.map { oldEndpointFromNewEndpoint($0.1) } __writeDatagrams(datagrams, sentByFlow: addresses, completionHandler: completionHandler) } where: oldEndpointFromNewEndpoint(…) is a function that converts from the NW to the NE endpoint flavour, and __writeDatagrams(…) is the ‘hidden’ version of the original Objective-C method. But that leaves me at a loss to explain the behaviour you’re seeing. I had a look at the original of the The datagram was too large string, and it’s ti

[quote='882610022, VictorPetitjean, /thread/809211?answerId=882610022#882610022, /profile/VictorPetitjean'] The just released 26.5 beta (build 25F5042g) seems to … solve FB21858319 [/quote] That’s great news. Thanks for testing on the beta seeds. [quote='882610022, VictorPetitjean, /thread/809211?answerId=882610022#882610022, /profile/VictorPetitjean'] when multiple versions of the app coexist on a machine, the latest … won't receive Local Network traffic after macOS reboot until its socket is closed and reopened [/quote] Hmmm. First up, as you’re aware, having multiple copies of an app installed is an ongoing source of local network privacy grief. I wish there was a better story on that front )-: However, your specific case sounds interesting. Lemme see if I understand it: You have Mac with multiple copies of your app installed. You restart the Mac. You launch one copy of the app. It’s immediately able to access the local network. You quit that. You launch the other copy of the app. It’s unable to access the

Thanks for bringing this to the forums. [quote='821286021, vpoinot, /thread/821286, /profile/vpoinot'] But would you be aware of a reason that would explain the delay observed by these customers? [/quote] No. And the fact that this only happens at specific sites makes it hard to offer useful insight. What I can do is suggest a path for investigating this. IMPORTANT I’m gonna assume you’re familiar with the system log. If not, read Your Friend the System Log. I’m also going to suggest an approach that’s kinda like the one I outlined in Using a Sysdiagnose Log to Debug a Hard-to-Reproduce Problem, so you might want to read that for more background. The canonical tool for investigating issues like this is a sysdiagnose log. In a case like this that’s only going to work if you have a customer who is reasonably technically savvy and willing to help you debug. A further complication is that NE content filter data providers can’t log to the system log when signed for distribution. They can only add stuff to the syst

Are you actually building a VPN product? I suspect that’s not the case, given that you’re using a placeholder for tunnelRemoteAddress. And if that’s true then… well… there are limits to how much I can help you here. My experience is that developers often try to use a packet tunnel provider for things that are not VPN. DTS doesn’t support those efforts because they tend to be very brittle. One of my erstwhile colleagues even wrote a technote about this, namely, TN3120 Expected use cases for Network Extension packet tunnel providers. If you’re trying to use a packet tunnel provider for something that isn’t VPN, I recommend that you watch WWDC 2025 Session 234 Filter and tunnel network traffic with NetworkExtension, where one of the engineers from the NE team explains the various alternatives that are available to you, including the new URL filter provider. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Are you sure that your accessGroup calculation is working as expected? AppIdentifierPrefix isn’t a standard Info.plist key, so for this to work you must be adding it to your Info.plist yourself. Also, is your app using a unique App ID prefix? Or your Team ID as the App ID prefix? The docs say to use the Team ID, but I think that’s a case of them just assuming the modern world where the App ID prefix is always the Team ID. If you’re using is using a unique App ID prefix I’m not entirely sure what’ll happen, so lemme know in that case. [quote='821305021, markkolan, /thread/821305, /profile/markkolan'] I have tried adding the identity separately [/quote] You’ll definitely need to do that. The keys you’re passing to SecPKCS12Import, kSecAttrAccessGroup and kSecReturnPersistentRef, don’t do what you’re hoping they’ll do (I suspect they’re just being ignored). My advice is that you call SecPKCS12Import and then call SecItemAdd. If that process is failing, it’s likely that you’re falling in to one of the many pitfal

Hmmm, it sounds like this is a new effort, in which case I’m going to ask you to start a DTS code-level support request so that we can have a short private conversation about this. Once that’s done, I’d be happy to respond to any remaining questions here. IMPORTANT When you open the support request, the form will ask whether anyone from Apple sent you that way. Enter the URL of this forums thread into that field. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

You can expect that most uploads will be notarised quickly. Occasionally, some uploads are held for in-depth analysis and may take longer to complete. As you notarise your apps, the system will learn how to recognise them, and you should see fewer delays. For lots of additional info about notarisation, see Notarisation Resources. Specifically, it links to a Q&A with the notary service team that’s quite instructive. [quote='821270021, northofm25, /thread/821270, /profile/northofm25'] This was working fine up until about the 28th March 2026. [/quote] My experience, based on helping folks here in the forums, is that the majority of people reporting “held for in-depth analysis” delays are new developers. However, that’s not universally true. See my comments here. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Let’s focus this discussion on your other thread. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Thanks for the post, very interesting the entitlement worked until now without changing your provisioning profiles or being expired and renewed again? I would recommend you to contact that team for them to check on your entitlement: https://developer.apple.com/contact/topic/SC1102/subtopic/30072/solution/select That link is to a specific support topic selection under our support pages. Manual navigation: https://developer.apple.com/contact/ > New Issue > Development and Technical > Entitlements. Also, first you should go over Eskimo's post about entitlement as has steps to check on the entitlements: https://developer.apple.com/forums/thread/799000 Hope this helps. Albert Pascual
  Worldwide Developer Relations.

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.

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 if this diagnostic payload test fails, then we

[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 identities. I talk ab

Honestly, this is all a bit of a mystery |-: I’d like to make sure I understand this bit correctly: [quote='882421022, Leo_Nagano, /thread/820771?answerId=882421022#882421022, /profile/Leo_Nagano'] with this code I still consistently hit [/quote] So you see this every time? Or are there some cases where this works? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

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