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.

I also use SF Symbols with SpriteKit for quick UI and icon prototyping. I have an SKTexture extension to create SpriteKit textures from SF Symbol on iOS: extension SKTexture { convenience init?(systemName: String, pointSize: CGFloat, weight: UIImage.SymbolWeight = .regular) { let config = UIImage.SymbolConfiguration(pointSize: pointSize, weight: weight) guard let symbol = UIImage(systemName: systemName)?.applyingSymbolConfiguration(config) else { return nil } let rect = CGRect(origin: .zero, size: symbol.size) UIGraphicsBeginImageContextWithOptions(rect.size, false, 0) guard let context = UIGraphicsGetCurrentContext() else { return nil } /// Flip the coordinate system context.translateBy(x: 0, y: rect.size.height) context.scaleBy(x: 1, y: -1) /// Generate a white image UIColor.white.setFill() context.fill(rect) context.setBlendMode(.destinationIn) if let cgImage = symbol.cgImage { context.draw(cgImage, in: rect) } else { return nil } guard let result = UIGraphicsGetImageFromCurrentImageContext() else { return nil } self.init(image: result) } } Usage example: let iconTexture = SKTexture(systemName: "play.fill", pointSize: 17, weight: .bold) let sprite = SKSpriteNode(texture: iconTexture) sprite.colorBlendFactor = 1 sprite.color = .systemBlue addChild(sprite)

I have a similar issue with Xcode 16.3. Readjusting the preview pane every time is not okay. I switched back to Xcode 16.2, which we can download separately from Apple or Xcodes app.

Interested in a solution to this issue as well. override func didMove(to view: SKView) { scaleMode = .resizeFill view.contentMode = .center // This is the closest working solution indeed. But not quite there yet. } The documentation of setNeedsDisplay() method says: If your view is backed by a CAEAGLLayer object, this method has no effect. A CAEAGLLayer is "a layer that supports drawing OpenGL content." SpriteKit probably used that, then moved to Metal, and the same limitation still applies. But this is only speculation. Source: setNeedsDisplay() CAEAGLLayer