Swift test + RealityKit custom component decode mismatch (has == true, typed decode == nil) — minimal repro

Development Package Manager
, , , ,
1

Hi all,

I’m seeing what looks like a mismatch specifically when running tests via SwiftPM CLI (swift test), and I’m not sure whether this should be tracked as SwiftPM, Swift Testing, or RealityKit.

I made a minimal repro repo:
https://github.com/mesqueeb/swiftpm-realitykit-custom-component-repro

It’s intentionally tiny:

  • one custom RealityKit component (ReproComponent)
  • one tiny local USDA file with that custom component attached
  • one test that loads the entity and checks raw-vs-typed component access

Repro command:

swift test --filter componentsPresentButNotDecodableInSwiftTest

Observed:

  • entity.components.has(ReproComponent.self) == true
  • entity.components[ReproComponent.self] == nil
  • test reports raw=1, decoded=0

Expected:

  • if has(...) is true for that registered custom component, typed lookup should decode and return non-nil.

In my main project, this difference affects E2E behavior, and running via xcodebuild test appears to behave differently from swift test.

Question:

  • Is this best reported/triaged from the SwiftPM side, or should I file/move this directly as a RealityKit issue (Feedback Assistant)?
  • Any known constraints around custom component decoding in SwiftPM test runtime?

Thanks for any guidance.

2

I don't see anything here that suggests a bug in Swift Testing. While it may be a bug in SwiftPM (I'm not an expert on that part of it) I would start by filing feedback against RealityKit with Apple about it. If it does turn out to be a SwiftPM issue, they can send the bug report along.

1 Like
3

Submitted as FB22099519.
I never know why people post these though, as I'm pretty sure it's not possible to make the ticket "public". :thinking:

4

It helps other people file similar reports, they can then reference this number.

1 Like
5

I can't find where to edit the original post.

I wanted to edit to clarify, as I think the message is a bit unclear.

In just 3 lines, the issue boils down to this:

When a custom RealityKit component is present (eg. ReproComponent) in swift testing we observe:

  • :white_check_mark: entity.components.has(ReproComponent.self) → true
  • :cross_mark: entity.components[ReproComponent.self] → nil
    (expected: a ReproComponent value)

that's the bug

6

Update, six months on: this still reproduces on macOS 27.0 (26A428) and it has escalated from a wrong result to a crash.

Running the same repro package now terminates with SIGSEGV instead of failing the expectation. The faulting frames are all inside RealityKit's USD importer, re-encoding the component it just created:

Foundation         JSONWriter.serializeString(_:)
RealityFoundation  encodeComponent(_:_:_:)
CoreRE             convertToEntityAssetData(...)
CoreRealityIO      StageSceneLibraryAssetBuilder::run

Two findings that change the framing of this thread:

  1. It is not SwiftPM-specific. A single Swift file with no package, bundle or test framework crashes the same way: register a Codable component with a String field, write a .usda with a matching RealityKitCustomComponent prim, and call Entity(contentsOf:). It also crashes under xcodebuild test when the raw .usda is in the bundle.

  2. The component instance is uninitialized memory, not a failed decode. Swap the String for a Float and the load succeeds, has is true, and the typed lookup returns -4.170893e+07 rather than the USD value or the Swift default. A String made of arbitrary bytes crashes on first read, which is what the "has == true, typed == nil" symptom on macOS 26 was hiding.

The reason xcodebuild test looked fine in a real project is that Reality Composer Pro compiles .rkassets into a .reality file, which never goes through the USD importer. swift test ships the raw USD instead. Loading the same content compiled with xcrun realitytool compile works under swift test too, so that's a workaround if anyone needs SwiftPM in the meantime.

Filed as FB24852723 with the single-file repro and crash report. @grynspan was right that this belongs with RealityKit rather than SwiftPM or Swift Testing.

1 Like