“file uri scheme”

[quote='880876022, akshit_ak, /thread/814494?answerId=880876022#880876022, /profile/akshit_ak'] Based on the code you linked to, there might be a bug [/quote] OK. In that case my advice is that you file a bug with your evidence so that the relevant engineers can look at this. Please post your bug number, just for the record. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='819975021, tiandt, /thread/819975, /profile/tiandt'] I’m seeing what looks like a compiler / macro-expansion / build-pipeline issue. [/quote] Agreed. I recommend that you file a bug about this. Please post your bug number, just for the record. If you use Xcode to expand the macro, what does it show? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Filed under FB22312002

[quote='820017021, marrgd, /thread/820017, /profile/marrgd'] I would like to open … in Swift Playground on iPad [/quote] I don’t think there’s a good way to do that these days. The copy of The Swift Programming Language (TSPL) you’re working from, the one published via Apple Books, is very old. Specifically, it’s associated with Swift 5.7 and the latest version, available on the Swift site itself, is for Swift 6.3: The Swift Programming Language Note The Apple Books version hasn’t been updated because TSPL moved to a DocC production pipeline, and that isn’t able to easily render to the document format required by Apple Books. Given the age of that copy of the TSPL, it’s not a surprise that the link it references [1] no longer works. I went looking for the equivalent link on the most recent TSPL, but there isn’t one. Here’s the corresponding page, but the note box with the link is gone. I think you could reasonably argue that we should bring this back. Normally I’d suggest you file a bug requesting ex

An other, related issue with CGSetDisplayTransferByTable() - this is probably not the best place to note this, but since macOS Tahoe there is an inconsistency in how the API works. The 26.4 RC is also affected. Before macOS Tahoe CGSetDisplayTransferByTable() redefined the color table of the SDR range and clipped the HDR range (much like custom color profiles in macOS usually do the same). In macOS Tahoe it does the same thing for most displays – except for the built-in XDR displays, when auto brightness is enabled and the display is in EDR mode (meaning: there is some HDR content on screen). When this happens (XDR + auto brightness + EDR mode), the contents of the CGSetDisplayTransferByTable is being used to multiply the entire EDR (SDR+HDR) gamma range instead of overwriting the SDR range and clipping the HDR range. This might be a blessing in disguise for some apps (that use this feature for color adjustments or brightness upscaling like BetterDisplay - as this allows avoiding HDR clipping when a custom co

Can you file a bug on this and upload the full spindump there? I opened one last week. Case-ID: 18860388 ...this is almost CERTAINLY caused by your ES client. Yes. The question here isn't what revisiond is doing, it's who revisiond is waiting on. Some other thread locked that lock and is now stuck, which is the real issue you need to sort out. It definitely revisiond (well, APFS), that's holding the lock. There are dozens of threads where the shared lock points at revisiond [426] thread 0xc0616d), both for reading and writing. *940 apfs_vnop_getattr + 312 (apfs + 604336) [0xfffffe000beacff0] *940 IORWLockRead + 144 (kernel.release.t6000 + 496568) [0xfffffe00088e53b8] *940 ??? (kernel.release.t6000 + 497548) [0xfffffe00088e578c] *940 ??? (kernel.release.t6000 + 619452) [0xfffffe00089033bc] *940 ??? (kernel.release.t6000 + 624472) [0xfffffe0008904758] (suspended, blocked by krwlock for reading owned by revisiond [426] thread 0xc0616d) *940 apfs_vnop_read + 708 (apfs + 555972) [0xfffffe000bea1304] *940

This is actually possible, though it requires a different approach than the typical single-AVAudioEngine setup. The key insight is that iOS allows multiple AVCaptureSession instances to coexist under certain conditions. You can configure two separate audio routes: Use AVCaptureSession with the AirPods as the input device for your speech recognition pipeline. Set the audio session category to .playAndRecord with .allowBluetooth option. For video recording with the built-in mic, use a second AVCaptureSession (or the camera API you are already using). The built-in mic can be explicitly selected as the audio input for this session. The catch is you need to manage the audio session category carefully. The .mixWithOthers option is essential here — without it, one session will interrupt the other. Another approach that avoids the dual-session complexity: use a single AVCaptureSession that captures from the built-in mic for video, and run SFSpeechRecognizer (or the new SpeechAnalyzer on macOS 26 / iOS 26) on the same

AFAIK there’s no magic here. And I tried reproducing this on my main work Mac and didn’t have a problem. @DTS Engineer When I have this issue, it also comes with a prompt that appears offering to download the device support files, but this fails because the files aren't available from the software update server. Given that you're an Apple employee, is it possible that your work Mac has access to an internal software update server that offers the required device support files, but that the public software update server doesn't?

Yeah, that's probably a bug in the iOS Simulator runtime that incorrectly annotated some of the files within the data directory. I bet if you look in that directory, you'll see some leftover spotlight files. I think you can delete them manually with sudo rm -rf ~/Library/Developer/CoreSimulator/Devices/...