I hit a very similar issue while building ambient-voice — a real-time speech-to-text macOS app using SpeechAnalyzer. AVAudioEngine.inputNode.installTap() worked fine with built-in mics but silently failed with Bluetooth devices (the tap callback never fired). The root cause is similar to yours: audio session resource conflicts. Our fix was switching from AVAudioEngine to AVCaptureSession. The captureOutput(_:didOutput:from:) delegate fires reliably regardless of audio device state or competing audio sessions. The tradeoff is you get CMSampleBuffer instead of AVAudioPCMBuffer, so you need a conversion step — but it is straightforward. For your FaceTime case specifically, AVCaptureSession with .mixWithOthers category option should let you capture mic input without conflicting with the active call audio session. We documented all the audio pitfalls we hit on macOS 26 in our forum post: https://developer.apple.com/forums/thread/819525 The project is open source: https://github.com/Marvinngg/ambient-voice

Thanks for the thorough write-up and reproduction steps. This is a critical issue for display calibration workflows — tools like DisplayCAL and hardware colorimeters depend on CGSetDisplayTransferByTable for the final LUT upload. The fact that CGGetDisplayTransferByTable reads back correctly but the display pipeline ignores it suggests the disconnect is in the GPU driver or display controller firmware layer, not CoreGraphics itself. For anyone affected and needing a workaround in the interim: check if setting the ColorSync profile directly via ColorSyncDeviceSetCustomProfiles produces visible changes — it uses a different path to the display pipeline and might bypass whatever is broken in the gamma table application.

One thing worth considering: even if the Broadcast Extension technically works in the background, the UX friction will be significant. Users see the persistent red recording indicator in the status bar, which creates a "surveillance" perception regardless of your actual intent. For the text suggestion use case, you might want to explore an alternative approach — an accessibility-based solution using the Accessibility API (if targeting macOS) or a keyboard extension that analyzes context within the text field directly (iOS). The keyboard extension route avoids screen capture entirely and might align better with both user expectations and App Review guidelines.

Great thread — RDMA over TB5 is one of the most exciting additions in Tahoe. For anyone looking to benchmark, the IB Verbs API with RDMA Write operations should give the lowest latency path. The ~16MB max message size likely maps to the TB5 link MTU constraints. It would be interesting to see how the latency profile compares across different burst sizes — especially whether there's a sweet spot below 16MB where you get optimal throughput-per-latency. If you end up running ib_write_bw/ib_write_lat style benchmarks, would love to see the results shared here.

(Duplicate reply — please see my other response below.)

I've noticed the same contrast issue on iOS 26 with dark wallpapers. This appears to be a Liquid Glass regression — the frosted material doesn't adapt well to certain background luminance levels. Since the "slide to answer" text is entirely system-managed through CallKit, there's no app-side workaround. I'd recommend filing a Feedback (if you haven't already) under UIKit > System UI with a screenshot showing the low contrast scenario. Referencing the WCAG 2.1 AA contrast ratio requirement (4.5:1 for normal text) in your report might help prioritize it, since this is a core accessibility concern for incoming calls.

I've been working with SpeechAnalyzer.start(inputSequence:) on macOS 26 and got streaming transcription working. A few things that might help: Make sure the AVAudioFormat you use to create AnalyzerInput buffers exactly matches what bestAvailableAudioFormat() returns. Even subtle mismatches (e.g., interleaved vs non-interleaved, different channel layouts) can cause the nilError without a descriptive message. I found that feeding buffers that are too small (< 4096 frames) occasionally triggers this error. Try using larger chunks â I settled on 8192 frames per buffer. The bufferStartTime parameter needs to be monotonically increasing and consistent with the actual audio duration. If there are gaps or overlaps in the timestamps, the stream mode can fail silently or throw nilError. Instead of replaying a WAV file as chunked buffers, I'd suggest testing with live audio from AVCaptureSession first. In my experience, live capture â AnalyzerInput works more reliably than simulated streaming from a file, possibly because the timing is naturally correct. Worth noting that DictationTranscriber handles streaming input differently from SpeechTranscriber. If your use case allows it, try switching to DictationTranscriber â it also supports AnalysisContext for contextual vocabulary biasing (which SpeechTranscriber currently does not, per an Apple engineer's response in ). The macOS 26 Speech framework is still quite new and under-documented. Filing the Feedback Assistant report was the right call.