Explore lighting: by default, ARView applies an image based light (HDRI, or skybox) to the environment, which would make colors appear lighter. In order to remove the default lighting, apply a black image instead: class MyARView: ARView { required init(frame: CGRect) { super.init(frame: frame) Task { let iblResource = try await EnvironmentResource(named: "black") environment.lighting.resource = iblResource } } } See EnvironmentResource and Construct an immersive environment. Search for how to create IBL resources for RealityKit.

I filed feedback FB22335783, "Regression: reduced editor tab density in Xcode 26".

There is a general strategy to run rendering and physics at different scales: scale the parent entity before the physics step, then scale it back after the physics step. Example: import RealityKit import Combine var subscriptions = Set<AnyCancellable>() func setupPhysicsScaling(scene: RealityKit.Scene, physicsAncestor: Entity) { let willSimulate = scene.subscribe(to: PhysicsSimulationEvents.WillSimulate.self) { event in physicsAncestor.setScale([10, 10, 10], relativeTo: nil) /// do work to prepare for simulation } willSimulate.store(in: &subscriptions) let didSimulate = scene.subscribe(to: PhysicsSimulationEvents.DidSimulate.self) { event in physicsAncestor.setScale([1, 1, 1], relativeTo: nil) /// do work to prepare for rendering } didSimulate.store(in: &subscriptions) } With the setup above, entities that are children of the physics ancestor entity will physically behave as if they were 10 times bigger, but their rendering will remain at nominal scale. This strategy works but needs careful setup. The key is to reason in terms of per frame update. Before a physics tick, prepare for simulation and maintain coherence. After the physics tick, set the rendering goal.

I have the same question, but for RealityRenderer: how to set a different physics origin entity than an ancestor, using RealityRenderer?

This reminds of an error I got while setting up SKRenderer for this project: SKRenderer Demo. See code and comment in SKOfflineRenderer.swift: // If I dont use a depth/stencil texture, rendering crashes on simulator, device, and Mac // Without it, rendering only works on Xcode Live Preview let depthStencilDesc = MTLTextureDescriptor() depthStencilDesc.pixelFormat = .depth32Float_stencil8 depthStencilDesc.width = pixelWidth depthStencilDesc.height = pixelHeight depthStencilDesc.usage = .renderTarget depthStencilDesc.storageMode = .private The code is inside the init, check how the depthStencilTexture is setup for SKRenderer, it may help you.

I have filed report FB22117916, titled "Reduced tab density in Xcode 26.3".

In order to control physical entities within a physics simulation, you can explore the topic of proportional-derivative (PD) controllers. The principle: User input provides a target position Each frame (use the willSimulate event), a control system applies forces or impulses to drive the body toward that target This answer provides a sample implementation with SpriteKit. The same principles apply to RealityKit.

I have submitted feedback FB21685578, titled "ARView does not support multi-touch". Currently, in order to access UIResponder's touch callbacks and respond to simultaneous touches on ARView, I have to either: Overlay an UIView on top of ARView and forward the touch events from the overlay to the ARView Attach a gesture recognizer to ARView, use the touch callbacks inside it to track touches, and handle the recognizer’s states Both workarounds add unnecessary debt and complexity.

Apple sent this response on 18 November 2025: We believe this issue has been addressed. Please verify this matter is resolved after updating to iOS 26.2 beta 3. iOS 26.2 beta 3 (Build: 23C5044b) Posted Date: November 17, 2025 In my testing, the issue seems resolved indeed! Thank you! It is great and encouraging news for SpriteKit users. The issue FB20808104, where both SpriteKit and RealityKit drop frames under SwiftUI views, still holds. I will continue to look for updates on the Feedback Assistant.

Is this expected behavior or a bug? Is there a crucial piece missing from my setup to get multitouch working on ARView without the overlay view hack? Your input is much appreciated.

I'd like to bring attention to an issue that may or may not be related to the SpriteKit iOS 26 regression: SwiftUI makes both SKView and ARView (RealityKit scene) drop many frames. Full code and bug report here: https://developer.apple.com/forums/thread/804973

I filed report FB20808104 with the above information and code. Expected behavior: a native UI menu shouldn't impact the performance of underlying views, or use significant system resources.

I installed iOS 26.1 Beta 4, hoping the SpriteKit issues were fixed. But alas, they're still there. You can try this additional test: on any SpriteKit scene with a running animation, place a SwiftUI Menu on top. Each time the menu is opened, SpriteKit drops frames. This makes SwiftUI unusable alongside SpriteKit when the scene is animated or live-recorded. SpriteKit used to run predictably and efficiently. iOS 26 has broken too much in terms of performance and usability. The current state of things isn’t reassuring at all.

Hi, Try adding CADisableMinimumFrameDurationOnPhone to the project's property list, set its value to true, then use preferredFramesPerSecond.

Done, I have filed report FB20287404 as "SpriteKit performance regression on iOS 26". Long live SpriteKit.