“testflight the requested app is not avaliable”

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

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 r

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

For me, the issue is NOT resolved in Xcode 26.5 beta. I downloaded it and created a 26.5 simulator, but I can NOT paste into it from macOS 26.4 host.