“testflight the requested app is not avaliable”

[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

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,

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

Hi Kevin, thanks for replying 😊 I am indeed using the kNAUIOptionKey option. Thank you for pointing that out - I would have never found this on my own 😊 Removing this option now works for mounting but kind-a defeats the purpose of calling NetFSMountURLSync since it now shows 3 dialogs (even after the initial approval, and storing the credentials in keychain - it now always asks all 3 questions): Asking for Approval Asking for username and password Asking which share to mount Basically everything one would want to avoid from happening especially when considering that mounting the the default /Volumes path, and that using mount_smbfs totally ignores this new feature. Note: I did report this unexpected behavior in Feedback Assistant (not sure if that would even be the correct place to do this). For now I'll disable this option (mounting to a custom mountpath using NetFSMountURLSync). Just being curious, what do you mean with Any location inside an app’s own container ? Again; thank you very m