“Apple Maps Guides”

[quote='882249022, vishalsehgal, /thread/815465?answerId=882249022#882249022, /profile/vishalsehgal'] In case error remains nil, can I still receive Data as null? [/quote] Yes. That indicates an EOF. As I mentioned earlier, the doc comments are the best source of truth for this stuff. Quoting the doc comment for nw_connection_receive_completion_t from : The content may be NULL in two cases: The receive context (logical message) is now complete, and the callback is only delivering the completed event The connection encountered an error and there is no data to deliver. Note that the content may be non-NULL even in the case of an error if there was some data received before the error was encountered. The caller should process all content it receives, and not necessarily ignore data in case of errors. I don’t think this can happen with UDP because UDP doesn’t support the concept of EOF. [quote='882249022, vishalsehgal, /thread/815465?answerId=882249022#882249022, /profile/vishalsehgal'] Is there any performance/e

FB22362166 Thanks! AFAICT this is Just A Bug™. I’m seeing a similar issue with my Xcode 26.4 install (a public release of Xcode 26.4 running on a public release of macOS 26.3.1). I suspect it’s due to the recent work to synchronise documentation between Apple > Developer and Swift > Documentation. However, we won’t know for sure until your bug has had more chance to find its way through our systems. ps 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. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='882281022, Pavel, /thread/820632?answerId=882281022#882281022, /profile/Pavel'] [outside of MDM] is there any programmatic way to influence which proxy receives the flow first? [/quote] No. And, in practice, the order you get is very much an implementation detail, one that changes from Mac to Mac and OS release to OS release. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='882312022, dopey, /thread/820940?answerId=882312022#882312022, /profile/dopey'] We are actually seeing seeing this happen in practice. [/quote] OK. [quote='882312022, dopey, /thread/820940?answerId=882312022#882312022, /profile/dopey'] it's not deterministic. [/quote] Right. It’s hard to say what’s going on without more logging, but the most likely cause is a memory pressure exit, and that’s very non-deterministic. [quote='882312022, dopey, /thread/820940?answerId=882312022#882312022, /profile/dopey'] I will open a bug and post the bug number. [/quote] Much appreciated. Ideally this would include a sysdiagnose log taken: On a device with extra CryptoTokenKit logging enabled (see below) Shortly after seeing the problem But that might be hard to get, so you should feel free to file a bug with only your ‘kill ctkd’ step as evidence. On the logging front, our Bug Reporting > Profiles and Logs only has a CryptoTokenKit profile for iOS. However, you can install that profile on macOS, and I think it’ll ju

[quote='882371022, Arebus, /thread/820871?answerId=882371022#882371022, /profile/Arebus'] I thought it would be easier to write a CLI than … [/quote] Yeah, I know what you mean, but recently I’ve moved away from that approach: For low-level stuff, I tend to put the test code into a unit test. This is just as easy to debug as a command-line tool, but it has the advantage that, as you exercise various code paths, you build up a corpus of unit tests that ensure that things continue to work in the future. For GUI stuff, I lean into Xcode’s preview feature. Or just do my experimentation in an target. And there’s Xcode’s UI testing support. I don’t use that a lot but, in my defence, UI stuff isn’t my focus. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='882274022, Davidbaraff2, /thread/820572?answerId=882274022#882274022, /profile/Davidbaraff2'] Do you know of any off the shelf VPNs that can be configured in the way you describe? [/quote] No. But my expertise is in VPN APIs, not VPN products. [quote='882274022, Davidbaraff2, /thread/820572?answerId=882274022#882274022, /profile/Davidbaraff2'] If you could point me [at code to] open sockets that will only use cellular [/quote] To start you off: Extra-ordinary Networking > Network Interface Techniques > Binding to an Interface explains how to bind a socket to a specific interface. Extra-ordinary Networking > Network Interface APIs > Network Interface Type explains how to identify the WWAN interface. [quote='882274022, Davidbaraff2, /thread/820572?answerId=882274022#882274022, /profile/Davidbaraff2'] We have total control of our local network. [/quote] So what happens if you don’t deploy a DHCP server on that network? I would expect that you’ll still be able to communicate with your iPads us

Hi Quinn, Following up on your earlier advice about using NEAppProxyUDPFlowHandling and the async readDatagrams / writeDatagrams API. I’ve updated my DNS proxy as follows: I now implement NEAppProxyUDPFlowHandling and handle DNS over UDP via the async API. For each flow, I store the Network.NWEndpoint that comes from readDatagrams() and then pass that same endpoint back into writeDatagrams. I no longer use NWHostEndpoint / NetworkExtension.NWEndpoint anywhere in this path. Relevant code (stripped down): private func readFirstDatagrams(from udpFlow: NEAppProxyUDPFlow, into flow: Flow, channel: Channel) { Task { let (pairs, error) = await udpFlow.readDatagrams() if let error = error { // handle error... return } guard let pairs = pairs, !pairs.isEmpty else { // retry... return } let (firstData, firstEndpoint) = pairs[0] let size = firstData.count MainLogger.shared.log(message: UDP recv (pairs.count) datagrams, first size=(size) from=(firstEndpoint) type=(type(of: firstEndpoint)) ) // Force a hostPort endpoint l

[quote='821109021, JTechHyd, /thread/821109, /profile/JTechHyd'] Are there known issues with aggressive optimization (-O) affecting … ? [/quote] Yes. If you’re using a C-based language it’s very easy to rely on undefined behavior, and the exact behaviour you get can change based on the optimisation level, the compiler version, the OS version, and so on. This is true in safer languages as well, but it’s less common. For example, Swift is generally safer than C but there are still sources of undefined behaviour, including unsafe pointers [1] and concurrency [2]. Is sounds like you’re building this third-party library from source. Is that right? If so, you can dig into the library to see if you can isolate the cause of the problem. This is no different from tackling a hard-to-debug problems in your own code. You can use both build-time tools (like the Clang static analyser) and runtime tools (like the standard memory debugging tools). It’s also possible for problems like this to be caused by bugs in the compiler

[quote='821027021, Pavel, /thread/821027, /profile/Pavel'] For debugging purposes, I am trying to run the daemon's executable directly from the terminal [/quote] This won’t work. For your launchd daemon to work correctly, it must be started by launchd. I explain why that’s the case in XPC and App-to-App Communication. My general advice for debugging a launchd daemon is: Structure your code so that you can do most of your debugging in unit tests, rather than in your daemon. That’ll make your life much easier. To unit test your XPC code, use the technique in TN3113 Testing and debugging XPC code with an anonymous listener. To debug integration issues: Using LLDB’s --wait-for option to attach to the daemon shortly after it starts. There’s a similar option in Xcode, under Debug > Attach to Process by PID or Name. Or if you absolutely need to debug from the first instruction, add the WaitForDebugger property to your launchd property list. See the launchd.plist man page for details. [quote='821027021, Pavel, /th

froglike6, It’s not clear whether your response was addressed to me or Skygreed. If it’s for me, be aware that my comment above was purely administrative. Skygreed added a reply to your thread, so I wanted to make sure that anyone finding this thread was aware of their thread. As to the technical aspects of this issue, and similarly for Skygreed’s issue, I’m not the right person to address that. I don’t have any in-depth experience with HID stuff. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

How are you distributing your programs? Directly, using Developer ID signing? Or via the Mac App Store? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

NWConnection is quite generic, so you shouldn’t be surprised that not all of its options make sense for all connection types [1]. However, in this case the .waiting state does make sense for UDP. Consider a connection created like this: let connection = NWConnection(to: .hostPort(host: example.com, port: 80), using: .udp) If you run this on a device with Airplane Mode enabled, the connection will enter the .waiting state. That’s because it’s waiting for DNS to come online so that it can resolve example.com to find out what addresses it should attempt to ‘connect’ to. But that’s just an example. I suspect that are a number of other cases where you’ll see this. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] The new NetworkConnection API improves this situation, using the Swift type system to vary the operations supported on the connection based on the underlying protocol. However, there are limits to how much you can improve this