Hi, Can Apple provide some reassurance on the continued support for SpriteKit in the coming years? At WWDC 2025, Apple deprecated SceneKit, which was alarming for a SpriteKit fan and user. I'm aware Apple doesn't comment on future plans. However, committing to a specific framework for larger projects is a significant investment in time (and money). Developers need to know whether to continue investing in proprietary technology that could be deprecated at any time. Some reassurance regarding SpriteKit's future would go a long way. I have moved my project from SpriteKit to RealityKit. RealityKit is certainly interesting, but I'd gladly switch back to SpriteKit. SpriteKit has things going for it that no other Apple framework provides: Live drawing of shapes, paths, text, video, and images at 120 FPS across all Apple devices. RealityKit offers no procedural drawing API equivalent to shape nodes. Particles and physics fields are very easy and fun to play with. The rigid body engine has a good feel. By comparison, RealityKit sleeps too aggressively, and doesn't have spring joints. SpriteKit is lightweight and runs well on older devices. In an ideal world, I'd also love to see SpriteKit improved: A deterministic physics engine Metal shader support Soft shadows for lights One can dream. Thank you!

Hi, I have a game which is available on iOS and tvOS and the gameplay is basically the same on both platforms. I'd like to enable my players to seamlessly continue their play sessions on all available platforms. Unfortunately, the new GameSave framework is not available on tvOS and neither is the old GKSavedGame API. I'm asking you to enable the new GameSave framework in a future version of tvOS. Thank you. I've also reported via Feedback Assistant with Feedback Number: FB22791051

Hi, I'm implementing the new iOS 26 GameSave API in my game and I'm seeing an unexpected behavior when I try to handle custom conflict resolution. Here's what happens: directoryState.conflictedVersions is nil when directoryState.state is GSSyncStateConflicted. According to the API docs, this should never happen because there is no way to resolve the conflict. Here's the setup: I have 2 devices. Device 1 - iPad 10G iOS 26.5, and Device 2 - iPhone SE 3G iOS 26.5 and I run the same code on both devices. I disable the WiFi on device 2 to create a conflict I open the directory using [GSSyncedDirectory openDirectoryForContainerIdentifier: nil] Run [dir finishSyncingWithCompletionHandler:] After the callback returns I check dir.directoryState.state If the state is GSSyncStateReady, GSSyncStateOffline, or GSSyncStateLocal I write some data in a file and close the dir. I re-enable the WiFi on Device 2 and run the same code Now, on Device 2 dir.directoryState.state is GSSyncStateConflicted, as expected, but dir.directoryState.conflictedVersions is NIL and there is no way to continue and resolve the conflict. I'm expecting dir.directoryState.conflictedVersions to contain an array of GSSyncedDirectoryVersion objects as described in the API docs. One interesting bit is that if I replace [dir finishSyncingWithCompletionHandler:] with [dir finishSyncing: window completionHandler:] the UI conflict resolution works as expected. I'm using Objective C to call the API, if that matters. I've also reported via Feedback Assistant with Feedback Number: FB22790831

I recompiled my turn-based app to the (now mandatory) SDK 26 (Xcode 26.4 to be exact), and Game Center is no longer sending notifications of turn changes or game invites to either my iPad Air running 15.8.8 or my iPhone SE3 running 26.4.2.

I have noticed that the performance drop on SpriteKit-based projects running on iOS 26 is still ongoing With iOS 26 back in Sep 2025 a framerate problem was introduced. My app was always running smoothly with 60fps even on very old devices suddenly started to stutter with 40fps - and lower on a rather normal iPhone 13. This problem continued with BETA 26.1 The problem was fixed in 26.2. But 26.3 brought the problem back and its still ongoing with 26.4 of yesterday This is easily reproducible with a very simple example // // BareboneSpriteKitApp.swift // BareboneSpriteKit // // Created by Bernd Beyreuther on 24.02.26. // import SwiftUI import SpriteKit @main struct BareboneSpriteKitApp: App { var body: some Scene { WindowGroup { BareboneSceneView() } } } final class BareboneScene: SKScene { override func didMove(to view: SKView) { size = view.bounds.size scaleMode = .resizeFill anchorPoint = CGPoint(x: 0.5, y: 0.5) backgroundColor = .darkGray let s = SKSpriteNode(color: .cyan, size: CGSize(width: 64, height: 64)) addChild(s) let action = SKAction.rotate(byAngle: .pi, duration: 2) s.run(.repeatForever(action)) let t = SKLabelNode(text: deviceInfoString()) t.fontSize = 15 t.position.y = -100 addChild(t) } } struct BareboneSceneView: View { var body: some View { SpriteView( scene: BareboneScene(), debugOptions: [.showsFPS] ) .ignoresSafeArea() } } func deviceInfoString() -> String { let os = ProcessInfo.processInfo.operatingSystemVersion let osString = "iOS \(os.majorVersion).\(os.minorVersion).\(os.patchVersion)" let model = UIDevice.current.model // "iPhone", "iPad" let machine = { var sysinfo = utsname() uname(&sysinfo) return withUnsafePointer(to: &sysinfo.machine) { ptr -> String in ptr.withMemoryRebound(to: CChar.self, capacity: 1) { cptr in String(cString: cptr) } } }() // z.B. "iPhone15,2" return "Model Identifier: \(model) (\(machine)), \(osString)" } I file a bugreport via Feedback Assistant FB22038921 The problem is no around for such a long time ! This is deeply concerning, because it questions if it is really feasable to continue to develop using Spritekit ?

In my turn-based app, existing matches created with a newer version (5.1.2) are not showing up in the MatchMaker ViewController (or even when I call GKTurnBasedMatch loadMatchesWithCompletionHandler) on a device running version 5.1. (Newer version is run from Xcode download to device). Note that in AppStoreConnect, I have the earliest compatible version set at 4.5. This was not a problem before using the (now mandatory) SDK 26 (Xcode 26.4 to be exact).

This started out as a plea for help, but in preparing this post I discovered the root cause. I'm posting it as a lesson learned in hopes it will help someone. I've spent a good chunk of March trying to get AR-mode working again in my unreleased game. I had it working with SceneKit and ARView 5 years ago, but since 2024 I've been converting the game to use RealityKit and RealityView on iOS, macOS, visionOS, and tvOS. I've been having no joy getting AR mode to work on iOS. I get the pass-through device video but the game content isn't anchored to the floor but rather anchored to the screen. I made a simple project with just a simple shape in the middle of a RealityView and an overlay with a SwiftUI toggle to go in and out of AR-mode. At first, my simple project worked, and I couldn't figure out what was different in the logic. Both projects used the same logic: func transitionToXR(_ content: inout RealityViewCameraContent) { content.remove(gameBoard.rootEntity) content.add(xrAnchor) content.camera = .spatialTracking Self.anchorStateChangedSubscription = content.subscribe(to: SceneEvents.AnchoredStateChanged.self) { event in if event.anchor == xrAnchor, event.isAnchored { xrAnchor.addChild(gameBoard.rootEntity) } } } Then I made an alternate version of my view, and reproduced the same "anchored to the screen not the floor" issue. I compared the code side-by-side and finally saw the difference! The one that didn't work, like my game, had a property 'cameraEntity' which is initialized with PerspectiveCamera(), position and look-at configured, then added as a child of the root entity. So, the simple fix was to remove 'cameraEntity' from the root entity before adding it to the detected AnchorEntity when going into AR-mode. Then when leaving AR-mode, I add back 'cameraEntity' as a child of the root entity and configure it again. So the lesson learned is: make sure there isn't a PerspectiveCamera in the tree of Entities added to an AnchorEntity with a .spatialTracking content camera. Apple: let me know if you think this is a bug or if I was being dumb. If a bug, I can use Feedback Assistant to report this. If I was being dumb, it wouldn't be the first time. :-)

Hi, I’m trying to use the new TouchController framework together with a custom Metal rendering pipeline using SpriteKit’s SKRenderer. Right now there seems to be almost no real documentation or end-to-end example showing how the framework is intended to work. Or is it just my own inexperience that I cant get it to work? My setup is: MTKView custom Renderer SKRenderer SKScene rendering SpriteKit manually through: skRenderer.render(withViewport:commandBuffer:renderPassDescriptor:) I managed to get: Metal rendering working SpriteKit rendering through SKRenderer TCTouchController connecting successfully But I still struggle to get the actual controls to render reliably on screen. Is there any minimal working example showing: MTKView SKRenderer TCTouchController rendering controls with render(using:) all together in one pipeline? Even a very small sample project would help a lot. Thanks!

I'm updating our app to support metal 4, but the metal 4 types don't seem to get recognized when targeting simulator. Is it known if metal 4 will be supported in the near future, or am I setting up the app wrong?

Hey all, I'm building a tile-based puzzle game for iOS and have been experimenting with using SwiftUI for the HUD (score, timer, pause menu, settings sheet) layered on top of a SpriteView that hosts the actual gameplay scene. So far the integration has been smoother than I expected — SpriteView drops cleanly into a ZStack, and I can drive SwiftUI state from the SpriteKit scene via an ObservableObject shared between them. That said, I've run into a few rough edges that I'd love some input on. The biggest one is touch handling: when a SwiftUI overlay (like a semi-transparent pause button) sits over the SpriteView, taps near the edges of the button occasionally get swallowed by the underlying scene, even when the button's hit area looks correct in the view debugger. I've tried .contentShape(Rectangle()) and bumping the frame, which helps but doesn't fully eliminate it. Curious if anyone has landed on a reliable pattern here, especially for transient overlays like toast notifications that need to ignore touches everywhere except on the toast itself. The other thing I'm weighing is animation ownership. Right now, gameplay animations (tile slides, match effects) live in SpriteKit, and HUD animations (score pop, combo counter) live in SwiftUI with withAnimation. It works, but the two animation systems don't share a clock, so when I want a "tile matched → score increment" effect to feel synchronized, I end up dispatching from the SKScene back to the ObservableObject and hoping the frame timing lines up. Has anyone found a cleaner way to coordinate timing across the two, or is this just the cost of mixing the frameworks? Would also love to hear from anyone who has shipped a game with this hybrid setup — any gotchas around Scene Phase transitions, backgrounding, or memory pressure that bit you in production? Thanks!

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 RealityKit components in tests — there is no swift test workaround Feedback ID: FB22099519 Environment: macOS 15.5, Xcode 16.4, Swift 6.1

I've been testing Apple Silicon devices in their desktop configurations on the Mac Studio and now retired Mac Pro and it seems like they're greatly bottlenecked by their clock speeds. For reference here's my testing results. Testing Results: Mac Studio M2 Max • 32GBs RAM • 30 core GPU • 1TB Storage CPU Utilization • 60% • 20W CPU Temperature • 47ºC GPU Utilization • 100% • 20W GPU Temperature • 55ºC Fan Speed • 50% Workload Duration • 2hrs Another point is that the clock speed on the M2 Max's CPU is 3.5 GHz and on the GPU it is 1.44 GHz at max performance. Which the Mac Studio has no trouble pushing. My question is how do I push those clock speeds higher? Cause 1.44 GHz at 55ºC is evidence for extensive headroom. I'm sure there are tools internally for testing the upper limits of the silicon, but it makes no sense why it would be set so low the Mac Studio is at no worries of melting. Is there any way to push the performance of my Mac Studio? FB22713867 - Possibilities of Overclocking Apple Silicon

When using index primitives is there a method to provide the indices using a temp buffer like setVertexBytes? Right now I have to create a temp metal buffer even for a small number of vertices and toss it after rendering using drawIndexedPrimitives.

Greetings! I'm preparing to publish an app in Apple Store. It's a 2D Audio app made in Godot, already published in Google Store.. As we know, OpenGL is considered deprecated since iOS 12 / 2018 .. However given the current state of Metal, or Vulkan integration in Godot, and with the idea of bringing the Best possible experience on iOS.. I'm not completely sure what will be the best API to use as primary option.. -As good as Metal, or even Vulkan work in Godot; the fact of the matter is, each API has its strong and weak points.. -Metal: Native on iOS, fully compliant and supported. However it has two weak points: Initial Compilation Freeze - +5 sec. Performance Hit, (although negligible for final user) app uses 25% more CPU (on my iPhone 12). Battery drain? -Vulkan: In godot, Vulkan > MoltenVk > Metal More complex translation layer, but interestingly gives slightly better Performance than Metal.. Initial Compilation doesn't cause Freeze, because is lazy/delayed and performed while the app is starting. Uses 25% less CPU than Metal and gives slightly more stable Framerate. (iPhone 12) However, given the extra complexity it could be more prone to error, or Compatibility Problems, which are known and have been reported with older iOS devices (iPads come to mind..) Right? -OpenGL: No Initial Compilation Needed Max Performance, No CPU munch Universally supported, (in theory?) works Perfectly on my iPhone 12 with iOS 26.3 and 26.4.2 And all in all, gives the best Performance and user experience. -And that's pretty much the situation! Since the graphics API of choice, will have an effect and directly translate to User experience... what's then the best one? -This will be the first app I Publish on Apple Store, so as you can imagine I want to Comply with Apple as much as possible; and bring iOS users the best possible experience. However each one of the APIs seem to have a negative aspect.. Metal: 5sec Compilation Freeze Vulkan: Compatibility Problems? OpenGL: "Deprecated" In practical terms, right now, OpenGL gives the best Performance, and the best User Experience.. So what to do? -The Android version is published in Google Store in OpenGL Compat mode. Works perfectly. Even tho OpenGL has been Deprecated on iOS for 7+ years, it has survived all along, with no announced removal date from Apple. And it seems to work perfectly and be fully operational up to the latest iOS 26 version.. right? Maybe Apple is maintaining it for stability and compatibility reasons, even if they're no longer actively developing it? Butthee "deprecated" label sounds alarming, as if support could drop any day.. So what will be the best choice in this situation? -Will an app built primarily for OpenGL, (with Metal fallback) be Rejected right away in Apple Store? -Otoh Vulkan (via MoltenVK) could be a middle term solution, second best Performance, no Compilation Freeze.. But yeah, the Compatibility aspect is important; and while considerable improvements have been made in Godot's implementation, the current status or possible outcome is harder to assess.. Both Metal and OpenGL seem safer options in that sense..

Hello, I have a problem where my macOS (Sequoia) Spritekit game spikes delta during the first press of an arrow key. I've test this with a small program, code below: // // GameScene.swift import SpriteKit import GameplayKit class GameScene: SKScene { var lastTime: TimeInterval = 0 override func keyDown(with event: NSEvent) { print("---------------> delta keyDown: \(event.characters!) keyCode: \(event.keyCode)") } override func update(_ currentTime: TimeInterval) { // Called before each frame is rendered print("update begins") let dt: CGFloat if lastTime > 0 { dt = (CGFloat(currentTime - lastTime)) } else { dt = 1.0 / 60.0 } if dt > (1/30) { print("************************************ delta spike ", dt) } lastTime = currentTime print("dt: ", dt) print("update ends") } } Example output: update begins ************************************ delta spike 0.03381687504588626 dt: 0.03381687504588626 update ends update begins dt: 0.016670208307914436 update ends As you can see, when I press left arrow key in this case I get a big delta spike. There's no spike with further presses of the arrow key. Other keys, such as the common W A S D controls for games, do not cause this delta spike.

If you are developing a network game, it is best to use server time as the basis for game time. If you are developing a standalone game, it is best to use the rendering frame count as the basis for game time.

I'm converting my game from SceneKit to RealityKit. It has a SpriteKit overlay that according to Explore advanced rendering with RealityKit 2 I can add with the code below. The code runs fine if the SKScene only contains a SKSpriteNode (see the commented out line), but when I add a SKShapeNode with a fillColor instead, the app crashes with this error: -[MTLDebugRenderCommandEncoder validateCommonDrawErrors:]:5970: failed assertion `Draw Errors Validation MTLDepthStencilDescriptor uses frontFaceStencil but MTLRenderPassDescriptor has a nil stencilAttachment texture MTLDepthStencilDescriptor uses backFaceStencil but MTLRenderPassDescriptor has a nil stencilAttachment texture ' I don't know enough about low-level graphics and stencils yet to figure out a quick solution, so I would appreciate if anyone could share an easy fix or explanation of what's wrong. Thanks! class ViewController: NSViewController { var device: MTLDevice! var renderer: SKRenderer! override func loadView() { let arView = ARView(frame: NSScreen.main!.frame) view = arView arView.renderCallbacks.prepareWithDevice = { [weak self] device in guard let self = self else { return } self.device = device renderer = SKRenderer(device: MTLCreateSystemDefaultDevice()!) let scene = SKScene() let shape = SKShapeNode(rectOf: CGSize(width: 10, height: 10)) shape.fillColor = .red scene.addChild(shape) // scene.addChild(SKSpriteNode(color: .red, size: CGSize(width: 10, height: 10))) renderer.scene = scene } arView.renderCallbacks.postProcess = { [weak self] context in guard let self = self else { return } let encoder = context.commandBuffer.makeBlitCommandEncoder() encoder?.copy(from: context.sourceColorTexture, to: context.targetColorTexture) encoder?.endEncoding() renderer.update(atTime: context.time) let descriptor = MTLRenderPassDescriptor() descriptor.colorAttachments[0].loadAction = .load descriptor.colorAttachments[0].storeAction = .store descriptor.colorAttachments[0].texture = context.targetColorTexture renderer.render(withViewport: CGRect(x: 0, y: 0, width: context.targetColorTexture.width, height: context.targetColorTexture.height), commandBuffer: context.commandBuffer, renderPassDescriptor: descriptor) } } }

I'm building an iOS word game (Gramfall) and no production App Store users can see their own scores on any leaderboard, despite Game Center authentication succeeding and no errors being thrown. The same code works correctly in development and all 6 leaderboard submissions fire "Score submitted" notifications on my dev device. 6 leaderboards in App Store Connect (3 Classic all-time, 3 Recurring monthly) and all are Live Production App Store users: authenticated, scores submitted, no errors — scores never appear Development build: all 6 submissions confirmed via Settings → Developer → Notify About Score Submissions Affected users cannot see their own score on the leaderboard from their own device. This rules out privacy/visibility restrictions as a player should always see their own score. This suggests submissions are either silently failing or being accepted but not recorded in the production Game Center environment. What we have ruled out Leaderboard ID mismatch (Everything in App Store Connect matches) Authentication failure (GKLocalPlayer.local.isAuthenticated is true, app shows "Connected") All 6 leaderboards load with releaseState(rawValue: 1), isHidden: false Account-level restrictions effectively ruled out as it affects all users, not one account endGame() fires correctly, confirmed in dev Questions Is there a known difference in how GKLeaderboard.submitScore behaves between the sandbox and production Game Center environments that could cause silent failures? Is there any way for a submission to return no error yet still not be recorded in production? Code func submitGameResult(timeSeconds: Int, score: Int, longestWordLength: Int) { guard GKLocalPlayer.local.isAuthenticated else { return } Task { do { try await GKLeaderboard.submitScore(timeSeconds, context: 0, player: GKLocalPlayer.local, leaderboardIDs: ["gramfall.lb.time", "gramfall.lb.time.monthly"]) try await GKLeaderboard.submitScore(score, context: 0, player: GKLocalPlayer.local, leaderboardIDs: ["gramfall.lb.score", "gramfall.lb.score.monthly"]) try await GKLeaderboard.submitScore(longestWordLength, context: 0, player: GKLocalPlayer.local, leaderboardIDs: ["gramfall.lb.longestword", "gramfall.lb.longestword.monthly"]) } catch { print("[GameCenter] submitGameResult failed: \(error)") } } }

I’m trying to use MTL4FXTemporalDenoisedScaler, and I’m seeing a crash during initialization even with a very simple sample app. I created a minimal sample here: https://github.com/tatsuya-ogawa/MetalFXInitExample The exception is: NSException: "-[AGXG16XFamilyHeap baseObject]: unrecognized selector sent to instance ..." What I found is: • This works: descriptor.makeTemporalDenoisedScaler(device: device) • This crashes: descriptor.makeTemporalDenoisedScaler(device: device, compiler: metal4Compiler) So the issue seems to happen only with the Metal4FX version. For testing, I’m using an iPhone 15 Pro. According to the Metal Feature Set Tables, MetalFX denoised upscaling should be supported on Apple9 and later, so I believe the device itself should meet the requirements. Reference: https://developer.apple.com/metal/Metal-Feature-Set-Tables.pdf Has anyone seen this before, or knows what might be causing it? I’d appreciate any advice. Thanks.

Problem Summary After upgrading to iOS 26.1 and 26.2, I'm experiencing a particle positioning bug in RealityKit where ParticleEmitterComponent particles render at an incorrect offset relative to their parent entity. This behavior does not occur on iOS 18.6.2 or earlier versions, suggesting a regression introduced in the newer OS builds. Environment Details Operating System: iOS 26.1 & iOS 26.2 Framework: RealityKit Xcode Version: 16.2 (16C5032a) Expected vs. Actual Behavior Expected: Particles should render at the position of the entity to which the ParticleEmitterComponent is attached, matching the behavior on iOS 18.6.2 and earlier. Actual: Particles appear away from their parent entity, creating a visual misalignment that breaks the intended AR experience. Steps to Reproduce Create or open an AR application with RealityKit that uses particle components Attach a ParticleEmitterComponent to an entity via a custom system Run the application on iOS 26.1 or iOS 26.2 Observe that particles render at an offset position away from the entity Minimal Code Example Here's the setup from my test case: Custom Component & System: struct SparkleComponent4: Component {} class SparkleSystem4: System { static let query = EntityQuery(where: .has(SparkleComponent4.self)) required init(scene: Scene) {} func update(context: SceneUpdateContext) { for entity in context.scene.performQuery(Self.query) { // Only add once if entity.components.has(ParticleEmitterComponent.self) { continue } var newEmitter = ParticleEmitterComponent() newEmitter.mainEmitter.color = .constant(.single(.red)) entity.components.set(newEmitter) } } } AR Setup: let material = SimpleMaterial(color: .gray, roughness: 0.15, isMetallic: true) let model = Entity() model.components.set(ModelComponent(mesh: boxMesh, materials: [material])) model.components.set(SparkleComponent4()) model.position = [0, 0.05, 0] model.name = "MyCube" let anchor = AnchorEntity(.plane(.horizontal, classification: .any, minimumBounds: [0.2, 0.2])) anchor.addChild(model) arView.scene.addAnchor(anchor) Questions for the Community Has anyone else encountered this particle positioning issue after updating to iOS 26.1/26.2? Are there known workarounds or configuration changes to ParticleEmitterComponent that restore correct positioning? Is this a confirmed bug, or could there be a change in coordinate system handling or transform inheritance that I'm missing? Additional Information I've already submitted this issue via Feedback Assistant(FB21346746)