“eskimo”

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

[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 macOS. Even when that fix land

[quote='882538022, AlexPan19920718, /thread/820969?answerId=882538022#882538022, /profile/AlexPan19920718'] FB: FB22384135 [/quote] Thanks for filing that. I took a look at Xcode 26.5b1 and it still seems to have the problem )-: Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='882565022, nckh, /thread/820929?answerId=882565022#882565022, /profile/nckh'] Seems to be fixed in Xcode 26.5 beta 1 :) [/quote] Yay! Thanks for the heads up, and also for testing with Apple’s beta seeds. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I’m not aware of any known issue that matches these symptoms. As you’ve noted, iOS is expected to preserve app group containers across OS and app installs. This certainly works for most apps and most users, but that doesn’t preclude there being a bug that causes this problem for some users of some apps. To investigate this we need to see a sysdiagnose log taken immediately after the user notices the problem. That’s gonna be tricky to acquire given that this problem isn’t obviously reproducible. I have a bunch of background on this in Using a Sysdiagnose Log to Debug a Hard-to-Reproduce Problem. Key to that process is the ability to quickly and reliably identify that the problem has occurred. If I were in your shoes I’d add specific code for that, code that’s not tied to UserDefaults or Core Data. Both of those are big, complex subsystems, which makes it hard to know whether you’re hitting a problem with that subsystem or something more fundamental. Rather, I recommend that you store this state in files that y

Ah, you’re using FTP. The FTP support in URLSession is based on CFFTPStream. That has known crashing bugs, and I believe that one of those bugs in causing this crash in URLSession. I recommend that you stop using FTP. If you can’t stop using FTP, you need to write or acquire your own FTP client rather than relying on Apple’s built-in one. See TN3151 Choosing the right networking API and, for even more details, my On FTP forums post. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

You haven’t asked a question here, so it’s not clear what your goal is with this forums thread. My best guess is that you’re aiming to report a bug in Rosetta. If that’s the case I recommend that you file that in Feedback Assistant. See Bug Reporting: How and Why? for lots of detailed advice on that topic. 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

I want to start by pointing you at TN3158 Resolving Xcode 15 device connection issues. This provides general background and one critical data point, namely, it shows how to identify the direct link interfaces used by Xcode. [quote='821229021, tathac, /thread/821229, /profile/tathac'] I have my web content filter … and there is also SentinelOne web content filter with same configuration. [/quote] I’m presuming that this SentinelOne filter isn’t something you have direct control over. Given that, my advice is that you remove it from the equation and replace it with a placeholder content filter that you do control. This gives you full control over the (non-Apple) bits of the stack. That’ll tell you whether this issue is fundamental to having two content filters installed, or whether there’s something specific about the SentinelOne filter that’s triggering the issue. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

My understanding is that your accessory is presenting a network interface to iOS much like, say, an USB Ethernet dongle would. In that case I’d expect iOS to assign IP addresses to that interface as long as the interface claims that it’s up. You can prototype this with an USB Ethernet dongle: Connect the dongle via Ethernet to the Internet. And then connect it to iOS. Verify that iOS has network connectivity over the Ethernet. Disconnect it from iOS. Disconnect the Ethernet dongle from the Internet, but leave it connected to your switch so that the link status stays up. Reconnect it to iOS. You should see iOS bring up the interface with link-local IPv4 [1] and IPv6 addresses. Any app running on iOS should be able to communicate over that interface. For example, if you have a configure like this: iPhone | USB Ethernet | ----+----------------+--------------- isolated Ethernet | Mac | ---------------------+--------------- Wi-Fi to Internet Safari on the iPhone should be able to connect to a web server running on

It’s hard to offer a specific answer without more context. iOS uses many different cryptographic algorithms, and the exact details vary based on the circumstances. Have you read Apple Platform Security? If not, I suggest you start there. 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. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com