“xcode github”

swift test (SwiftPM CLI) fails to decode RealityKit custom components from USD files, even though entity.components.has(MyComponent.self) returns true. Typed access via entity.components[MyComponent.self] returns nil. This forces projects that use RealityKit custom components to use xcodebuild test exclusively. Minimal repro: github.com/mesqueeb/swiftpm-realitykit-custom-component-repro Repro steps git clone https://github.com/mesqueeb/swiftpm-realitykit-custom-component-repro cd swiftpm-realitykit-custom-component-repro swift test --filter componentsPresentButNotDecodableInSwiftTest Observed ✅ entity.components.has(ReproComponent.self) returns true ❌ entity.components[ReproComponent.self] returns nil Expected If has(...) returns true for a registered custom component, typed lookup should decode and return non-nil. Notes Running the same test via xcodebuild test works correctly The component is properly registered and the USDA file correctly references it This affects any project that relies on custom Reality

When running parallel Swift Testing tests that each create their own in-memory ModelContainer, the first xcodebuild test run succeeds but all subsequent runs fail with DefaultStore save failed validation errors — unless DerivedData is deleted between runs. Setup Each test suite creates an isolated in-memory container with a unique name: ModelConfiguration(UUID().uuidString, schema: schema, isStoredInMemoryOnly: true) The @Model class has non-optional properties (e.g. var v: String, var entityDicMoveNr: Int) that are always set in init. Symptoms on second run SwiftData.DefaultStore save failed with error: Error Domain=NSCocoaErrorDomain Code=1560 Multiple validation errors occurred. NSValidationErrorKey=v, NSValidationErrorValue=null NSValidationErrorKey=entityDicMoveNr, NSValidationErrorValue=null NSValidationErrorKey=historyBackup, NSValidationErrorValue=null The errors appear before test code executes — during SwiftData's internal DefaultStore auto-save. Properties that are always initialized in Swift show

When I chose a watchOS Test and set the watch with latest watchOS on Xcode Cloud, I could not pass the CI because it showed xcodebuild: error: Unable to find a destination matching the provided destination specifier: { platform:watchOS Simulator, id:9863C79E-3793-483E-BAA1-F96A0BD34005 } I've change some destination, but it's not worked. Is there any idea what I can do? The watch app is along with the mobile, not standalone.

Hello Developers, I am facing an issue while trying to sign in to a newly created Apple Developer account on my Mac/Xcode. Error message: “This device is already associated with other accounts in the Apple Developer Program or the Apple Developer Enterprise Program. Please use a different device.” Details: The Apple ID works correctly in browser login Apple Developer membership/payment is completed The account is accessible on the Apple website The issue only appears while signing in on the Mac/Xcode I already contacted Apple Support and received a case ID, but no response yet after 24+ hours Things already tried: Signed out/in from Apple ID Restarted Mac Tried different network Cleared related account settings Has anyone faced this issue before? Is this a temporary device association/security restriction from Apple’s side, or does it require manual reset by Apple Support? Any guidance would be appreciated. Thank you.

When interacting with RealityView’s realityViewCameraControls .orbit and setting a new RealityViewCameraContent .cameraTarget, the resulting camera target and camera orbit is incorrect. This can be demonstrated where one finger is orbiting the RealityView, and another pushes a button which changes the camera target. Instead of the camera facing the new target, some point in the scene is the new effective camera target and orbit point. This only occurs when an orbit interaction is currently taking place. If you stop interacting with the orbit, change target, then start orbit interacting again, everything works as expected. Though this example uses two-touches, any change of the camera target has this conflict with orbit interaction. This means interacting with orbit will result in the wrong camera view which is unexpected for users and difficult to reconcile or detect, for developers. Expected: Interacting (orbiting) the scene while setting a new camera target with the buttons on screen (at the same time), the

Hey all, Ran into a fun one on macOS 26.4.1 / Xcode 26.4.1, and I think I've narrowed it down enough to be worth sharing. Symptom: HSplitView's divider drags fine, but the cursor never changes to the resize cursor on hover. Just stays as the regular arrow. The cause (in my case): the HSplitView was conditionally rendered via an outer if let: struct PlayerDetailsView: View { let theme: Theme var playerVM = PlayerViewModel.shared var body: some View { let grayscaleCM = ColorMap(table: .grayscale) ZStack { VStack(spacing: 0) { Rectangle() .fill(LinearGradient(colors: [Color.black.opacity(0.45), Color.black.opacity(0)], startPoint: .top, endPoint: .bottom)) .frame(height: 8) Spacer() Rectangle() .fill(LinearGradient(colors: [Color.black.opacity(0.45), Color.black.opacity(0)], startPoint: .bottom, endPoint: .top)) .frame(height: 8) } .allowsHitTesting(false) if let disc = playerVM.disc { HSplitView { DiscInfoView( disc: disc, theme: theme, ) .frame(minWidth: 720, alignment: .topLeading) .buttonShadow() .f

I first started observing this behaviour through the crash logs of one of my App Store apps which are downloaded by Xcode. Then 3 days ago the same crash happened when launching one of my other apps on my own Mac. On the next try, the app launched correctly. The crash logs don't show any of my app's symbols, only a single thread that does something with libsecinit. I have no idea what the problem is, and since these crashes are also downloaded by Xcode, one would get the impression it’s a fault in my programming… but without any hint as to what I’m doing wrong, I have no chance to fix it, and so I get the feeling that it’s actually a macOS bug. I created FB22712334. crash