“eskimo”

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

[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