A Summary of the WWDC25 Group Lab

(For posterity and web searches) One can create a serial queue by using the default initializer for DispatchQueue: private let serialQueue = DispatchQueue(label: some.custom.label) I'm then initializing the Connection Group like: connectionGroup = NWConnectionGroup(with: multicastGroup!, using: params) and finally starting it with: connectionGroup.start(queue: serialQueue) It's that last line that's super important because the default global() queue will give you a concurrent queue rather than a serial one.

Ah yes, great point! I think that's exactly what it was. I had fixed the issue initially by processing in a serial queue, but your comment made me go back and realize the connection group was getting started like this: connectionGroup.start(queue: .global()) Which is, of course, a concurrent queue. With the serial queue in place I was able to flood the device with thousands of UDP messages without issue. Thanks so much!

I’m glad to hear you’re making progress. [quote='847078022, FT-cfoy, /thread/791083?answerId=847078022#847078022, /profile/FT-cfoy'] The completion handler is spinning up a new thread [/quote] I noticed that the crashing code is being called out of Network framework. One thing to watch out for there is the type of queue that you pass into Network framework when you create your NWConnection [1]. Network framework will accept either a serial queue or a concurrent queue. Internally it does its own serialisation, so it doesn’t care. However, for your own sanity it’s important to use a serial queue. If you use a concurrent queue, it becomes very hard to reason about your code. Similarly, if you have multiple connections running simultaneously, it often makes sense to use the same serial queue for all of them. Oh, and be wary of concurrent queues in general. See Avoid Dispatch Global Concurrent Queues. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.c

I’m not sure I can properly help you with this, because I’m not confident I understand QA1277, which is problematic because I originally wrote it! Honestly, I’m not sure I fully understood it back then either )-: Regarding your issue, my understanding is that these credentials are generated on successful authentication. However, I’ve never looked into the exact point that generates them, that is, are they generated by the act of successfully gaining a right, or by successfully running a rule, or by the builtin:authenticate method. You can almost certainly work this out by looking at the code for the authorisation engine in Darwin. A good place to start would be here [1]. WARNING You have to be careful when digging into Darwin. It’s full of implementation details, and encoding such implementation details in your product is not the path to long-term binary compatibility. However, in this case I think it’s reasonable. Authorisation plug-in development is already a field full of compatibility pitfalls. If you’re

Thank you for that very insightful response! I appreciate it, and learned a lot. Responding to your question below. Hopefully this will give a bit more context to what I am doing and why. What are you actually waiting on? In general, I've become very nervous anytime I see code that uses dispatch groups because they seem to be used as a slightly awkward band-aid trying to make something work that doesn't really want to work. Case in point here, the main reason an NSE would be waiting is network activity, in which case the simpler solution would be to simply set the right timeout on that network activity. For example, let's say 3 async things are happening: Call a reporting API Call a service metric API Download an attachment I don't want to call contentHandler until I have given them all adequate time to complete. My understanding is once contentHandler is called, the system will kill the NSE process. Alternatively I could not call the contentHandler, and let the full ~25-30 seconds run and let the sy

You can use the Foundation Models instrument, in the Instruments app, to analyze the use of the framework and details about your session: it features a column reporting the number of input and output tokens, which you might want to check to see if they're consistent with your expectations. This WWDC25 video can be useful too.