Since moving to Xcode 27.0 (27A266a) with the visionOS 27.0 simulator runtime (24M362), generating a mesh with several parts through MeshResource.generate(from: MeshResource.Contents) makes the simulator go black for a couple of seconds and restart. The app does not crash; the simulator's render server does:
Thread ... Crashed :: com.apple.CoreRE.ResourceFetchManager-service-queue
0 DirectResource specialized static IndexValidation._validate_neon(_:vertexCount:)
1 DirectResource DRValidateIndices
2 CoreRE re::(anonymous namespace)::validatePrivateData(id<REMeshPayload>, unsigned char const*, unsigned long)
3 CoreRE -[REMultiBufferMeshPayload initWithCoder:]
4 Foundation _decodeObject
Environment: MacBook Pro (M1 Pro, 16 GB), macOS 27.0 (26A428), Xcode 27.0 (27A266a), visionOS 27.0 SDK (24M361); failing runtime visionOS 27.0 simulator (24M362); working: the visionOS 26.5 simulator runtime (23O470) under the same Xcode, and an Apple Vision Pro on visionOS 27.
What I have established:
- It reproduces with a fully synthetic mesh: one model, three parts (1330 / 20 / 24 vertices, 9513 / 72 / 120 indices), random positions, normals, UVs and triangle indices. Only the part layout matters.
- The mesh is valid: every part's indices are within its own vertex count, counts are multiples of three, attribute buffers match. RealityKit's app-side validator agrees and lets it through (it does reject a broken part with REMeshPartDescriptor: index buffer payload range is invalid), then the render server's validator traps on the accepted payload.
- Single-part meshes of any size, primitives, and compiled .reality scenes are fine.
- Same mesh, same Xcode: fine on a simulator device created on the 26.5 runtime, fine on a visionOS 27 device. Only the 27.0 simulator runtime traps.
FB number: FB24831983.
Workarounds so far: a simulator device on the 26.5 runtime, or generating one MeshResource per part. Has anyone seen DRValidateIndices trapping on the 27.0 simulator?