I was reading through cube-image node docs and it talked about loading data from a cubemap file in ktx format. It wasn’t clear if that was only for the original KTX format, and if that node was also able to take advantage of the KTX2 format? Is this shader node only relevant for files in the original (v1) KTX format?

After watching https://developer.apple.com/wwdc24/10131, I'm curious if the semantic embeddings used to provide the "search of meaning" with this new capability are encoded with multi-lingual embeddings? In particular, if I have content that is mixed in Korean and English, can those be seamlessly indexed together and queries in one language (english) find relevant content that was offered to be indexed as Korean?

I'm trying to load up a virtual skybox, different from the built-in default, for a simple macOS rendering of RealityKit content. I was following the detail at https://developer.apple.com/documentation/realitykit/environmentresource, and created a folder called "light.skybox" with a single file in it ("prairie.hdr"), and then I'm trying to load that and set it as the environment on the arView when it's created: let ar = ARView(frame: .zero) do { let resource = try EnvironmentResource.load(named: "prairie") ar.environment.lighting.resource = resource } catch { print("Unable to load resource: \(error)") } The loading always fails when I launch the sample app, reporting "Unable to load resource ..." and when I look in the App bundle, the resource that's included there as Contents/Resources/light.realityenv is an entirely different size - appearing to be the default lighting. I've tried making the folder "light.skybox" explicitly target the app bundle for inclusion, but I don't see it get embedded with it toggle that way, or just default. Is there anything I need to do to get Xcode to process and include the lighting I'm providing? (This is inspired from https://stackoverflow.com/questions/77332150/realitykit-how-to-disable-default-lighting-in-nonar-arview, which shows an example for UIKit)

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.