eskimo

[quote='809951021, Ionnier, /thread/809951, /profile/Ionnier'] I have a .app that runs as LaunchDaemon and configured to be an Agent (LSUIElement) that is stored in /Applications. [/quote] Wow, that’s quite a combo. Lemme see if I understand this correctly: You have a launchd daemon. That’s embedded in an app-like wrapper. Its Info.plist contains LSUIElement. Presumably because the daemon displays UI. And the daemon is run via a launchd property list in /Library/LaunchDaemons. Is that right? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='869193022, DTS Engineer, /thread/809830?answerId=869193022#869193022'] That's the classic” UNIX system machine swap [/quote] Well, I’d argue that the classic Unix swap involved a swap partition. None of this fancy, new fangled anonymous pager stuff (-: Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Sorry for the delay responding. I’m running out of workdays for 2025, so I can’t address everything upthread. Instead, I want to post some general guidelines. If DevForums blocks you from posting reasonable content with the message “This post contains sensitive language”, I’d appreciate you filing a bug about that. For instructions on how to do that, see the end of this post. After that, you’ll need a workaround. Here’s how to use a binary search to find the problematic text: As part of the bug reporting process, you saved a copy of your post to a text file. Make a copy of that file. Open it in your text editor of choice. Select half of the file and delete it. Copy the remaining text and try to post that. If it works, undo the delete, select the other half, delete that, and go back to step 4. Make sure to click the Edit button next to your post rather than posting a second reply. If it fails, go back to step 3 and continue dividing. Eventually you’ll get down to something super small and you can usually find

Mr. Eskimo, huge thanks for a great response. Not 100% about mode to the networking layer, do you mean basically add Thread.sleep on the server when testing? I will take your suggestions to heart. It's great since i'm also rewriting my objc networkhandler in Swift. Just a final belt/suspenders-question: If i understand you correctly, most applications should just perform the request regardless, wait for the API response/timeout and not bother at all with NWPathMonitor ?

[quote='868983022, scottbonar, /thread/809596?answerId=868983022#868983022, /profile/scottbonar'] We now are looking at the WifiNetworkType [/quote] The what now? That’s not an API I recognise. Can you point me at its documentation? Coming back to your main issue, this is iOS, right? So you’re using an Network Extension packet tunnel provider, right? If so, I’m a bit confused as to why you need this. You wrote: [quote='868983022, scottbonar, /thread/809596?answerId=868983022#868983022, /profile/scottbonar'] But, once our Custom VPN app is running the Primary is now the VPN TUN [/quote] Right. [quote='868983022, scottbonar, /thread/809596?answerId=868983022#868983022, /profile/scottbonar'] instead of the Cellular interface, which we need to pass data [/quote] But inside your packet tunnel provider NECP should prevent you from accessing your VPN interface, and thus your data should run over WWAN. Is that not working in general? Or not working solely in the CarPlay case? If you’re not familiar with NECP, I link

Sorry I didn’t reply earlier; I was hoping to do an full test of this but have been struggling to find the time to set that up. It’s best not to think it terms of AWDL. It’s an implementation detail of Apple’s peer-to-peer Wi-Fi feature. That implementation has changed in the past and it’s not hard to imagine it changing again in the future. So, while the existence of AWDL is not a secret, and it’s certainly useful to know about it when looking and logs and so on, the feature we’re talking about is Apple peer-to-peer Wi-Fi. [quote='869042022, captadoh, /thread/808917?answerId=869042022#869042022, /profile/captadoh'] true peer to peer with no wifi network works with iOS devices [/quote] Correct. [quote='869042022, captadoh, /thread/808917?answerId=869042022#869042022, /profile/captadoh'] without cellular [/quote] I’m not sure why you think cellular is a factor here. It is not. Peer-to-peer Wi-Fi is independent of cellular. [quote='869042022, captadoh, /thread/808917?answerId=869042022#869042022, /profile/capta

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. Invalid Response Status: 14501 I wasn’t able to find any info on that )-: My Bug Report number is FB21299192. Thanks. Honestly, I think that’s the best path forward here. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='869071022, JianbinWu, /thread/808040?answerId=869071022#869071022, /profile/JianbinWu'] How does the system detect that the adapter has been connected? [/quote] Settings is a built-in component of iOS and thus not limited to using just APIs. Earlier I wrote: [quote='868933022, DTS Engineer, /thread/808040?answerId=868933022#868933022'] On macOS you have a lot more options, including both System Configuration framework and I/O Kit. [/quote] If you were trying to solve this problem on macOS, it’d be easy to do with those APIs. However, those APIs are not available on iOS [1]. Moreover, I’m skeptical we’ll ever make them available on iOS [2], which is why my suggestion above wasn’t to file an ER for those APIs but rather a bug report against the functional type values. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] The frameworks might be available but the specific APIs you need not. [2] Because of the privacy imp

This isn’t something we can help you with here on the forums. For info on how to proceed, see this post. 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

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

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

First up, please understand that I’m not claiming that local network privacy (LNP) is bug free. I’ve seen enough reports like this to understand that there are real issues in play, especially on the Mac where the platform’s greater flexibility makes LNP’s job much harder. However, my experience is that it’s difficult for LNP bugs to get traction unless they come with strong evidence, and ideally a reliable set of steps to reproduce. And that’s going to be the focus of my response here. It also means I’m gonna start with the first pathology, primarily so that I can be sure that we’re aligned when it comes to testing. You wrote: On a clean install of macOS Tahoe (our test setup used macOS 26.0.1 on a Mac mini M2 8GB), we upload the app (version 5.1). We run the app, make sure the selected NIC is the proper one, and open the multicast socket. The app asks us to allow Local Network, we allow it. The first divergence I see is at this step. I don’t have your accessory on my network so no local traffic is generated,

[quote='868778022, JianbinWu, /thread/808040?answerId=868778022#868778022, /profile/JianbinWu'] How to distinguish between those … and the real ethernet adapter which insert on my iPad? [/quote] Unfortunately I can’t see a good way to do that on iOS [1]. I think you could make a reasonable case that those additional interfaces should not be returning IFRTYPE_FUNCTIONAL_WIRED, but instead something more indicative of their purpose (like IFRTYPE_FUNCTIONAL_INTCOPROC). If you’d like to see that change, I encourage you to file a bug along those lines. And if you do file a bug, 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] On macOS you have a lot more options, including both System Configuration framework and I/O Kit. Neither of those are API on iOS or its child platforms.

[quote='868809022, Mathias_, /thread/808401?answerId=868809022#868809022, /profile/Mathias_'] just fire off the request blindly and wait to see what happens? [/quote] Yes. And use an expiration handler to deal with the case where the network is super slow. That last bit is critical, because it crops up in practice. In most cases an immediate network request — that is, one without waitsForConnectivity set — will finish promptly. It’ll either succeed or it’ll fail immediately. But there are networks out there in the real world where such requests take a long time. Sometimes that’s caused by bad network conditions. The network is moving packets just fast enough to convince iOS to use it, but not fast enough to get anything useful done. But in other cases it’s caused by weird network configurations. For example, a Wi-Fi accessory might publish a network that goes out of its way to convince iOS that it has a path to the wider Internet when it actually doesn’t. Now, unless you have access to such a network then tes