I recently circled back to a SwiftUI Document-based app to check on warnings, etc. with Xcode 16 and Swift 6 now released. I just found a suite a new errors that indicate that ReferenceFileDocument is now expected to be Sendable, which seems very off for it fundamentally being a reference type. I followed the general pattern from earlier sample code: Building Great Apps with SwiftUI, which goes from an Observable object to adding conformance to ReferenceFileDocument in an extension. But then the various stored properties on the class cause all manner of complaint - given that they're not, in fact, sendable. What is an expected pattern that leverages a final class for the ReferenceDocument, but maintains that Sendability? Or is there a way to "opt out" of Sendability for this protocol? I'm at a bit of a loss on the expectation that ReferenceFileDocument is sendable at all, but since it's marked as such, I'm guessing there's some path - I'm just not (yet) clear on how to accomodate that.

While I was recently profiling some code from a Swift library, I noticed that XCTest added in signposts for the measurement tests, which I found really helpful to "home in" on the code I wanted to profile digging around in the stack trace. I tried to add my own signposts to provide just a bit of my own markers in there, but while it compiles and profiles equivalently, the signposts just aren't showing up. This is with Xcode 16.1, macOS Sequoia (15.1) and a swift library, using XCTest and profiling within one of the unit tests. Is there something in this sequence that doesn't allow the library to set up signposts and have instruments collect them? The flow I'm using: import os let subsystem = "MyLibrary" class MyClass { let logger: Logger = .init(subsystem: subsystem, category: "fastloop") let signposter: OSSignposter init() { signposter = OSSignposter(logger: logger) } func goFast() { let signpostId = signposter.makeSignpostID() let state = signposter.beginInterval("tick", id: signpostId) // ... do a bunch of work here - all synchronous signposter.endInterval("tick", state) } } Is there something I'm doing incorrectly in using this API, or not enabling to allow those signposts to be collected by the profiler? I do see the signposts that XCTests injects into the system, just not any of the ones I'm creating.

What are the possible transitions within NWConnection.State? Are cancelled and failed both terminal states? (Implying that I should drop the connection and attempt to set up a new one if I want to reconnect?) The common flow of setup -> preparing -> ready I've observed, but I wasn't sure how waiting fit in. What transitions are legal (and managed) by NWConnection? (mermaid couldn't handle this diagram - but I wrote it out anyway) Are these transitions all valid? [*] --> setup cancelled --> [*] failed --> [*] setup --> preparing preparing -> ready preparing -> cancelled preparing -> failed ready -> waiting ready -> failed ready -> cancelled waiting -> cancelled waiting -> preparing waiting -> failed

I’m exploring enabling speech-to-commands processing for a game, but would like to try and do a baseline of voice recognition within that to allow two people in close proximity to interact , but not interfere with each others voice commands to this system. (it’s for an accessible game idea)