This is the opposite of https://developer.apple.com/forums/thread/726354 really, and I've read both of the Recording Private Data in the System Log and Your Friend, the System Log threads, but I still can't solve my problem. The structured log always seems to redact private values to If I set OS_ACTIVITY_DT_MODE=1 in my environment (it's not set anymore by Xcode, at least not for my projects) then the logs are unredacted as I would expect, but structured logging is turned off. Is there a way to have the unredacted strings in the log when the app is running under Xcode and still get the nice structured log output? I don't want the unredacted logs when the app runs normally, but I'd like them under Xcode. At the moment, I'm having to explicitly make everything public, which defeats the whole purpose of the system.

I have the following SwiftUI view that fails to compile with the error "Generic parameter 'Content' could not be inferred" but if I comment out the line context.doSomething() then it compiles and runs fine. It also works if I remove the Context class and just pass a Binding<Bool> into the closure directly. What should I be doing to make it work, and why is the context.doSomething() line stopping the compiler from inferring what the Content parameter is? public struct BrokenView<Content: View>: View { @ViewBuilder var content: (_ context: Context) -> Content public class Context: ObservableObject { @Published var context: Bool = false func doSomething() { context.toggle() } } @State var context = Context() public init(@ViewBuilder content: @escaping (_ context: Context) -> Content) { self.content = content } public var body: some View { VStack { content(context) .padding() } } } #Preview { BrokenView { context in // Error here Text("Hello") Button(action: { context.doSomething() // Comment out to fix }) { Text("Goodbye") } } }

I have an NSTextLayoutManager set up with NSTextContentStorage and NSTextContainer. To work out the height of the content, I call the method updateContentSizeIfNeeded() which contains the code textLayoutManager.enumerateTextLayoutFragments(from: textLayoutManager.documentRange.endLocation, options: [.reverse, .ensuresLayout]) { layoutFragment in height = layoutFragment.layoutFragmentFrame.maxY return false } The first time this is called, it returns the correct height. Then I add a new character to the start of the NSTextContentStorage like so textContentStorage.performEditingTransaction { storage.replaceCharacters(in: NSRange(location:0, length: 1), with: "a") } textLayoutManager.ensureLayout(for: textLayoutManager.documentRange) textLayoutManager.textViewportLayoutController.layoutViewport() updateContentSizeIfNeeded() This time, the height returned is ~600px too big. The state of the NSTextLayoutFragment is set to layoutAvailable The next time I add a character to textContentStorage using the same code above, the height returned is correct again. I can work around this by calling enumerateTextLayoutFragments from the start of the document and not in reverse, then ignoring all fragments except the last one, but I don't know if that's the correct way to do it, or if I should be doing something else

My code that streams buffers into AVAudioPlayerNode is stuttering when the buffer is finished and before the next one is played. while engine.isRunning { let framesToCopy = min(buffer.frameLength - framePosition, Self.BufferSize) let srcRaw = UnsafeRawPointer(srcPtr) let playbackBuffer = AVAudioPCMBuffer(pcmFormat: buffer.format, frameCapacity: Self.BufferSize)! let playbackPtr = playbackBuffer.floatChannelData![0] let destRaw = UnsafeMutableRawPointer(mutating: playbackPtr) memcpy(destRaw, srcRaw, Int(framesToCopy) * MemoryLayout<Float>.stride) srcPtr = srcPtr.advanced(by: Int(framesToCopy)) playbackBuffer.frameLength = framesToCopy await player.scheduleBuffer(playbackBuffer, at: nil, options: [], completionCallbackType: .dataRendered) } I've tried to schedule multiple buffers at once using a combination of both the synchronous and async versions of scheduleBuffer because I thought the delay might be but it still stutters and the data copied into the playbackBuffer matches the source buffer. I've tried all combinations of options and completionCallbackType but no luck. I've tried increasing the buffer size but that just spaces out the stutters because the buffer is larger. What am I missing about this API?