“eskimo”

Thanks for bringing this to the forums. [quote='821062021, hsbc-uruguay, /thread/821062, /profile/hsbc-uruguay'] Any improvements or new tools available since the 2022 DTS post? [/quote] I’m glad you asked (-: Recently the App Store Connect folks updated their documentation to describe a technique for transferring app groups between teams. See App Store Connect Help > Transfer an app > Overview of app transfer > Apps using App Groups [1]. Given that, it’s now possible to use an existing technique — using an app group ID as a keychain access group — to preserve keychain access across an app transfer. I’ve just updated App ID Prefix Change and Keychain Access to describe this approach. Now, this is all very ‘bleeding edge’, and thus it’s possible that you might run into snags. However, it’s certainly an option worth exploring. [quote='821062021, hsbc-uruguay, /thread/821062, /profile/hsbc-uruguay'] We just finished an app transfer to our developer account. [/quote] The option I’m describing typically r

[quote='882269022, Pavel, /thread/820631?answerId=882269022#882269022, /profile/Pavel'] is there a guaranteed initialization order between them? [/quote] No, but that doesn’t matter because the launchd on-demand architecture defines away the sorts of ordering problems that plague other systems. If your NE sysex messages your launchd daemon, the system will start the daemon so that it can service the request. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[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

[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 imp

The 3 in that error is KERN_NO_SPACE, which is a pretty clear indication that the system memory allocator asked for address space and the kernel refused to give it. However, given all the constraints you’ve described, it’s not at all clear why that would be. Weirdly, the code that traps this way is not on the main branch of the Darwin open source, but I found a copy in the rel/libmalloc-792 branch [1]. Now, I don’t have time today to study that code in depth, but I figured you’d find it interesting (-: AFAICT it tries to allocate address space by using mach_vm_map to map MEMORY_OBJECT_NULL, specifying a start that’s after 16 GiB, such that it fits within 64 GiB, with a randomly applied offset. That random bit probably explains why this shows up so infrequently. It’s hard to say why this is failing. You might be able to learn more by running vmmap against the dying process. It’d also be interested to know what address was passed to mach_vm_map (with reference to the source, that’s the ptr_addr value), somethin

MetricKit definitely works on macOS. I’m not sure about how it interacts with Network Extension processes. Let’s start with some basics: Is your NE provider packaged as an app extension or a system extension? If it’s an sysex, are you distributing it directly? Or on the Mac App Store. TN3134 Network Extension provider deployment talks more about NE provider packaging and deployment options. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com