I have some clarifying questions on how fences work in Metal 4. If two encoders A, B update the same fence and encoder C waits on that fence, is the work encoded by C guaranteed to execute after both A and B have completed, or after either A or B have completed? The following quotes in the waitForFence() documentation seem contradictory. "Encodes a command that instructs the GPU to pause before starting one or more stages of the pass until a pass updates a fence." "When encoding a pass that reuses a fence, wait for other passes to update the fence before repurposing that fence..." Are fences unsignaled when they are waited on? Specifically, can two (or more) encoders wait on a fence that is only updated in a single prior encoder? If an encoder updates a fence, no subsequent encoders in the command queue wait on the fence, and the command queue is committed, is that fence still signaled when used in a subsequent command buffer?

I am investigating whether a macOS display utility can adjust the luminance of normal SDR desktop content system-wide, including other apps, on the built-in Liquid Retina XDR display of a 2021 M1 Max MacBook Pro. Is there a documented public API, or combination of public APIs, for this scope? The research target is SDR white around 1000 cd/m² while retaining HDR highlight capability, where supported by the hardware and OS. This is a feasibility question, not a claim that this output has been achieved or is supported. The approach must preserve OS color management and respect thermal, power and brightness limits, including protective dimming. I am not seeking gamma-table changes, screen capture and HDR re-display, private APIs, or bypasses of system protections. I understand that enabling EDR for an app's own layer is different from controlling ordinary SDR content in other apps. I am specifically asking about the latter. If this is supported, could you point to the API names, primary documentation, applicable macOS versions and hardware limitations? If it is not supported through public APIs, an explicit clarification would also be helpful.

Apple's InputTargetComponent documentation shows this code for an entity that should receive input without participating in physics: // Create a collision component with an empty group and mask. var collision = CollisionComponent(shapes: [.generateSphere(radius: 0.1)]) collision.filter = CollisionFilter(group: [], mask: []) myEntity.components.set(collision) In my RealityKit scene, myEntity also has an enabled InputTargetComponent and a GestureComponent with a TapGesture callback. I use .trigger collision mode. With the empty group and mask, the callback runs on visionOS but does not run on macOS or iOS. Changing the filter to CollisionFilter.default makes the callback run on macOS and iOS. The entity and gesture setup are otherwise the same. Should the documented empty filter still allow input hit testing on macOS and iOS? Is this a RealityKit bug, or does input targeting on those platforms require a different collision filter or additional setup?

FB24536235 On Mac Catalyst under macOS 27, a plain CADisplayLink asking for CAFrameRateRange(minimum: 60, maximum: 60, preferred: 60) gets serviced at 30 Hz for as long as a RealityView is on screen in the same window. The link does nothing per tick but count, so there's nothing of mine to blame it on. RealityKit's own statistics overlay reads 60.41 fps in the same frame. Click a segmented control that removes the RealityView and the same link goes straight back to 60. Nothing else changes. That's the whole reproducer, and I've attached it to the radar. It only happens while the display panel is in ProMotion mode. Set the built-in to a fixed 60 Hz and it's correct again. With an external 60 Hz display attached the roles swap: the built-in is fine and the external drops to somewhere between 18 and 30, and setting the built-in to 60 Hz fixes that one too without touching the external's own settings. A raw MTKView presenting continuously at 60, at 120, and on a 120 Hz link presenting every second callback are all fine, so it isn't continuous presentation and it isn't the requested rate. It's RealityKit specifically. Worth knowing if you're testing: RealityView on Catalyst is an ARView underneath, so both paths give you the same answer. This is VERY rough for anything that puts RealityKit next to a UI. In an editor that's the sidebar, the inspector, gizmos, drag handles, every display-link-driven or UIKit animation in the window running at half rate around a viewport that stays smooth. Likely Related to FB24091347, which is the same defect seen as SwiftUI scroll judder. If you can reproduce either, please file a duplicate. Attached two screenshots; first with promotion enabled, second with promotion off. PLEASE fix this, it drives me crazy and there seems to be no workaround. On release day of macOS 27 our app will likely be blamed for it by users and my hands are tied. Thank you!

In a WWDC 2019 "Advances in macOS Security" at 18:40 there is the following code func getDesktopWindowIds() -> [CGWindowID] { let windows = CGWindowListCopyWindowInfo([.optionOnScreenOnly], kCGNullWindowID)! as! [[String: AnyObject]] let DesktopWindowLevel = CGWindowLevelForKey(.desktopWindow)-1 let DesktopWindows = windows.filter { let windowLevel = $0[kCGWindowLayer as String] as! CGWindowLevel return windowLevel == desktopWindowLevel } return desktopWindows.map { $0[kCGWindowNumber as String] as! CGWindowID } } to find the CGWindowID of the Desktop background. This works, but when you then try to get the CGImage for that CGWindowID with let cgImage = CGWindowListCreateImage(CGRectNull, [.optionIncludingWindow], cgWin, [.bestResolution]) cgImage does get a reference, however it's just a gray image. Not the Desktop picture. It's clear from the documentation that ScreenCaptureKit should be used. However, if used I get multiple warnings to the user, the most concerning one states: "App" would like to record this computer's screen and audio. This is not true! I do nothing with audio and to say a capture is a recording is also misleading. Is there way to achieve what use to work before macOS 27? Or a way to change/avoid this misleading warning? Is there a reason why this warning is needed for capturing the Desktop background where before it was explicitly allowed?

iPhone 18 Pro Max using Xcode 27 (27A266a) The framework logs: ObjectCaptureSession.isCurrentDeviceSupported: Object Capture is not supported on this device bug filed as FB24864578

Hello, I recently submitted an enhancement request through Feedback Assistant requesting official native macOS support for Genshin Impact. Feedback ID: FB25106712 I am an Apple Developer Beta tester, a Mac user, and a passionate gamer. I regularly test macOS developer beta releases and provide feedback on performance, stability, compatibility, and the overall system experience. I also genuinely enjoy testing games on Mac and seeing what Apple Silicon is capable of. I have personally tested games such as Wuthering Waves, Cyberpunk 2077, and Minecraft on Mac, and my experience with them has been extremely positive. Wuthering Waves in particular runs very smoothly and seamlessly on my Mac. These experiences have made me feel that the capability for excellent gaming on Apple Silicon is already there. The larger limitation, in my experience, is the availability of native support. As a major HoYoverse fan, Genshin Impact is one of the games I would most like to experience and test natively on macOS. At present, Mac users have to rely on third-party workarounds such as PlayCover, compatibility solutions, or cloud gaming rather than having an officially supported native client. I would really like to see Apple work with HoYoverse to bring Genshin Impact natively to macOS, properly optimized for Apple Silicon and Metal. I would also be very happy to test such a release across macOS versions and provide detailed feedback on performance, graphics, stability, thermals, controller support, and the overall gaming experience. Could this enhancement request be brought to the attention of the appropriate Apple team, or is there an appropriate channel through which I can provide further feedback regarding this request? Thank you for your time.

My sandbox app on MAS (Hide Icons) simply toggles the visibility of the Desktop icons and Widgets on or off. It does this by display customized NSWindow on window level given by NSWindow.Level(rawValue: Int(CGWindowLevelForKey(.desktopIconWindow))+1) This custom NSWindow can either have a copy of the Desktop background/wallpaper CGImage or a solid color depending on user preference. Until macOS 27, this worked fine. To find all the Desktop background/wallpaper images (there can be multiple screens and each screen can have multiple Spaces), Apple provided code that avoided any TCC dialog boxes. Namely func getDesktopWindowIds() -> [CGWindowID] { let windows = CGWindowListCopyWindowInfo([.optionAll], kCGNullWindowID)! as! [[String: AnyObject]] let DesktopWindowLevel = CGWindowLevelForKey(.desktopWindow)-1 let DesktopWindows = windows.filter { let windowLevel = $0[kCGWindowLayer as String] as! CGWindowLevel return windowLevel == desktopWindowLevel } return desktopWindows.map { $0[kCGWindowNumber as String] as! CGWindowID } } which returns [CGWindowID] of all the Desktop background/wallpaper windows. Then for any one, say cgID, a simple let cgImage = CGWindowListCreateImage(CGRectNull, [.optionIncludingWindow], cgID, [.bestResolution]) gave an CGImage which then can be applied to my custom NSWindow. No where is TCC triggered. All is great. I followed Apple's ideas about Security and Privacy since I'm only using the data I need (i.e. [CGWindowID]) and the data is only used during execution. Never saved or shared. macOS 27 beta 4 and beyond broke CGWindowListCreateImage(...). It compiles and when called it returns some gray image. Documentation tells me to use ScreenCaptureKit. The newest versions of ScreenCaptureKit introduce SCScreenshotManager.captureImage(contentFilter:, configuration) which can return a CGImage of the CGWindowID. Here is when the problem occurs. To capture that CGWindowID CGImage, one would use SCContentFilter(desktopIndependentWindow: desktopWindow) but to get desktopWindow you first need to find the SCWindow that corresponds to CGWindowID. You can grab a set of SCWindow with SCShareableContent.excludingDesktopWindows(false, onScreenWindowsOnly: false) But when any method of SCShareableContent is called, TCC throws up this warning I do not want this. Too many permissions are being granted. I only want the [CGWindowID] of the Desktop background/wallpaper. This, if the user grants, gives me much more which is bad for Security and Privacy. One way to avoid the TCC in ScreenCaptureKit is to use the new SCContentSharingPicker.shared. This allows the user to pick what they want to share. I first tried var pickerConfiguration = SCContentSharingPickerConfiguration() pickerConfiguration.allowedPickerModes = [.multipleWindows, .singleWindow] but the picker does not allow the user to select the Desktop background/wallpaper. Using var pickerConfiguration = SCContentSharingPickerConfiguration() pickerConfiguration.allowedPickerModes = [.singleDisplay] also doesn't give me Desktop background/wallpaper access. Trying to use [.singleApplication] and limiting the choices to WindowServer (what SCWindow claims is the owner) also doesn't allow picking of the Desktop background/wallpaper. So, is it true to get access to the Desktop background/wallpaper CGWindowID's CGImage, I must have the user give me full access via TCC? Please tell me of a work around. The obvious fix is on Apple's side. The corresponding list of [SCWindow] corresponding to [CGWindowID] should always be included in SCContentFilter.includedWindows. Or simply leave them out of the TCC domain as before.

According to the official Metal Feature Set Tables, the Apple9 family introduces full 64-bit atomics such as atomic_compare_exchange_weak_explicit() and others. However when trying to use it the compiler throws an error "no matching function call...". Example: kernel void test_64bit_cas(device atomic_ulong* atomic_var [[buffer(0)]]) { ulong expected = 0; ulong desired = 1; // This fails to compile despite Apple9 hardware supporting 64-bit buffer atomics atomic_compare_exchange_weak_explicit(atomic_var, &expected, desired, memory_order_relaxed, memory_order_relaxed); } Am i doing something wrong ?

The CGSetDisplayTransferByTable() is not working on the latest round of Mac hardware, namely the MacBook Neo (external display), MacBook M5 Pro (both built-in and external display) and possibly the M5 Max. All tested apps (BetterDisplay, MonitorControl, f.lux, Lunar) exhibit the very issue both in macOS Tahoe 26.3 and macOS Tahoe 26.4 RC. Tested on multiple Macs and installations on the MacBook Neo and MacBook M5 Pro. This issue breaks several display related macOS apps. Way to reproduce the issue using an affected app: Install the app BetterDisplay (https://betterdisplay.pro) Launch the app, open the app menu, choose Image Adjustments and try to adjust colors. Adjustments take no effect Way to reproduce the issue programmatically: Attempt to use the affected macOS API feature: https://developer.apple.com/documentation/coregraphics/cgsetdisplaytransferbytable(::::_:) Here are the FB numbers: FB22273730 (Filed this one as a developer on an unaffected MBP M3 Max) FB22273782 (Filed from an affected MBP M5 Pro running 26.4 RC, with debug info attached)

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 ?

Through log analysis, I found that the SQLite files generated after signing in to Game Center are located in: ~/Library/Group Containers/group.com.apple.gamecenter/Library/Caches com.apple.deleted automatically cleans up cache files. This causes the following problem: after I have been signed in for some time, when I check Game Center again, I find that the profile name has changed to Unknown. When I launch Apple Arcade games, I am always asked to sign in to Game Center, and “Show Profile” also shows the same symptoms as described in this post: https://discussions.apple.com/thread/256053912 I believe they are caused by the same issue. I have to log out and then log back in to Game Center to temporarily resolve the problem, but once the cache is cleaned again, I have to repeat the same process. I also think that having less remaining free storage space may make system cache cleanup more likely to be triggered, although this is only my guess. https://www.reddit.com/r/macgaming/comments/1l0f8i4/the_avatar_and_name_in_game_center_are_displayed My system is macOS 15.7.9. I have already submitted a complete Feedback Report. FB ID: FB24975495

I maintain mps-pointops, an open-source library implementing farthest-point sampling (FPS), k-nearest-neighbor search, and radius / Ball Query operations with custom Metal kernels for PyTorch MPS tensors. The intended use is 3D point-cloud pipelines whose existing extensions depend on CUDA. I would like to prepare a contribution proposal at the appropriate layer. Apple’s PyTorch/MPS page links to the PyTorch MPS backend contribution guide and directs backend issues to PyTorch’s GitHub tracker with the module: mps label. The current implementation has numerical-contract tests for selection order, ties, radius boundaries, and padding, plus benchmark records from physical M1 and M5 Pro Macs. The repository contains the kernels, Python interfaces, tests, and measurement conditions: https://github.com/gamzerA/mps-pointops My questions are: For specialized operators such as FPS and radius search, is the recommended contribution structure to keep the operator/API in a domain library (for example, a point-cloud or graph library), while proposing only reusable backend primitives to PyTorch MPS? Is there a public Apple-maintained contribution or technical-review channel relevant to this work, beyond the PyTorch route linked from Apple’s page? For an external library that dispatches custom Metal work alongside PyTorch MPS operations, which documented extension/interoperability path should be the long-term target for command-stream ordering and buffer lifetime? I would like to minimize reliance on backend internals when preparing an upstream proposal. Pointers to the appropriate public interface, maintainers, or contribution requirements would help me scope a small, reviewable proposal. I understand that inclusion in an upstream project is subject to its maintainers’ review. Apple documentation referenced: https://developer.apple.com/metal/pytorch/

As part of the WWDC25 Keynote, a technology was announced that can present 2D images as 3D spatial scenes. This announcement is supported by a Press Release. ...developers can use the Spatial Scene API to make their app experience even more immersive. Zillow is taking advantage of the API for their Zillow Immersive app, allowing users to see images of homes and apartments with the rich depth and dimension that spatial scenes offer. The feature also appears in the Photos App on iOS 26 Developer Beta 1. Tapping "Spatial Scene" on any photo opens a view of that photo with a parallax effect. I've searched the WWDC sessions and new documentation and have come up short. Reaching out here for help. Is there any documentation for Spatial Scene API? Or any guidance on how to implement the spatial scene in iOS?

Hi, I understand Scenekit is deprecated in ios27, but expectation is that it should continue working in ios27 and not anymore maintained. With ios27 , when we attempt to set self.delegate in an ARSCNViewDelegate we receive a crash. Is there any workaround to have that fixed until we have time to move away from Scenekit? Can this be part of a fix in ios27 considering we should have sometime to migrate out production apps or that won't go through? Thank you.

I filed Feedback Assistant report FB24967734 for this issue. When two USD scenes contain explicit polygon meshes at the same prim path and are compiled together with xcrun realitytool, one scene's mesh loads with zero bounds. Renaming the mesh prims so their paths are unique makes both meshes load correctly. Reproduce Download and expand the source ZIP from https://github.com/mesqueeb/RealitykitUsdMeshDisappearanceOnMatchingPaths/archive/refs/heads/main.zip, then run these commands from the extracted directory: xcrun realitytool compile --output-reality Fixtures/Compiled/inline-same-path.bundle/Contents/Resources/RealityKitContent.reality --platform macosx --deployment-target 27.0 Fixtures/Source/inline-same-path.rkassets xcrun realitytool compile --output-reality Fixtures/Compiled/inline-unique-path.bundle/Contents/Resources/RealityKitContent.reality --platform macosx --deployment-target 27.0 Fixtures/Source/inline-unique-path.rkassets swift run The same-path case has a mesh at /Root/MeshCube in both scenes. The control changes only the mesh paths to /Root/MeshCube_A and /Root/MeshCube_B. Current output inline-same-path: SceneA.usda / MeshCube: bounds=SIMD3<Float>(0.19999999, 0.2, 0.2) SceneB.usda / MeshCube: bounds=SIMD3<Float>(0.0, 0.0, 0.0) inline-unique-path: SceneA.usda / MeshCube_A: bounds=SIMD3<Float>(0.19999999, 0.2, 0.2) SceneB.usda / MeshCube_B: bounds=SIMD3<Float>(0.19999999, 0.2, 0.2) Expected output Both meshes in the matching-path case should have nonzero bounds: inline-same-path: SceneA.usda / MeshCube: bounds=SIMD3<Float>(0.19999999, 0.2, 0.2) SceneB.usda / MeshCube: bounds=SIMD3<Float>(0.19999999, 0.2, 0.2) inline-unique-path: SceneA.usda / MeshCube_A: bounds=SIMD3<Float>(0.19999999, 0.2, 0.2) SceneB.usda / MeshCube_B: bounds=SIMD3<Float>(0.19999999, 0.2, 0.2) Reproduced on macOS 27.0 (26A428), Xcode 27.0 (27A266a). The repo includes the USDA inputs, compiled RealityKitContent assets, and the Swift code that prints these bounds. Source and downloadable ZIP: https://github.com/mesqueeb/RealitykitUsdMeshDisappearanceOnMatchingPaths

I’m investigating GameKit Saved Games synchronization between an iPhone and an iOS app running on an Apple-silicon Mac through TestFlight—not a native macOS or Mac Catalyst app. Environment: • iPhone 11, iOS 26.6.2 • Apple-silicon Mac, macOS 27.0 (26A428) • Built with Xcode 27 (27A266a), minimum iOS 16 • Same iCloud and Game Center accounts, confirmed manually • iCloud Drive enabled, including the app’s per-app syncing setting on Mac Expected: The Mac can discover and load the existing iPhone save. Observed: The iPhone’s fetchSavedGames returns two entries, one matching our expected save name, and loadData successfully reads that matching save. On the Mac, fetchSavedGames completes without an error but returns an empty array. This is the raw result before our filename filtering. Game Center authentication succeeds. Our app-level identity checks also resolve to the same game/environment/profile scope on both devices. We understand this does not independently prove the iCloud accounts match. The installed Mac app’s signed entitlements include: • Game Center • iCloud environment Production • CloudDocuments • The expected matching iCloud and ubiquity container identifiers The unusual system observation is that brctl status for this container reports: client:blocked-app-uninstalled SYNC DISABLED (app not installed) This persists while the app is installed and running. The container reports foreground when the app is open. Completed checks: Verified installed build and signed entitlements. Confirmed LaunchServices registration of the app wrapper and inner iOS bundle. Targeted re-registration, normal Mac restart, and reopening did not clear the state. In a separately triggered diagnostic inside the signed app, called FileManager.url(forUbiquityContainerIdentifier:) off the main thread with the exact entitled container identifier. That call returned a nonnil URL, but the immediate GameKit fetch and a subsequent delayed check still returned zero saves. The system block remained unchanged. The diagnostic did not write a save, restore progress, or directly read/write container files. We have not deleted app data, reset iCloud, or rewritten the source save to force synchronization. I found the authentication-timing discussion at: https://developer.apple.com/forums/thread/718541 However, our result persists across subsequent fetches and restarting the Mac, rather than only the first fetch near authentication. Questions: • Is there an additional supported configuration or initialization requirement for GameKit Saved Games in an iOS TestFlight app running on Apple silicon? • What targeted diagnostics would help explain why the container remains marked app-uninstalled despite the app being installed and running? • How should an app distinguish a genuinely empty Saved Games result from synchronization that is not yet available? We have not established that this is an Apple defect. We currently have an instrumented application, but not a separate minimal project reproducing the issue.

I’m using PHASE for an outdoor soundscape with only .directPathTransmission enabled. A point source and listener are 2 metres apart. Between them is a PHASEOccluder built from a 2 × 2 × 0.02 metre MDLMesh box, with a .cardboard material assigned to every shape element. Without the occluder, the sound is loud. With it, the sound is completely inaudible. Switching to .glass and setting the sampler’s cullOption to .doNotCull makes no audible difference. This happens on both iOS Simulator and a physical iPhone. Adding .lateReverb produces faint audible sound, but room reverb is inappropriate for this outdoor scene and doesn’t establish whether direct transmission works. Is this expected attenuation, or is additional configuration required to hear muffled sound through an occluder? Is there a working sample demonstrating material-dependent transmission with reverb disabled?

FB24091347 On macOS 27.0 beta (26A5388g), MacBook Pro M4 Pro, the built-in ProMotion display never settles on a stable refresh cadence. Scrolling in SwiftUI judders constantly. The same app binary was smooth on macOS 26, and is smooth on a 120 Hz ProMotion iPad. I captured two 60-second Instruments traces — same app, same scene, same scrolling, no external display — changing only the display's refresh-rate setting. On ProMotion the vsync interval standard deviation is 4.093 ms across six different cadences, mostly flip-flopping between 120 Hz and 60 Hz. Forced to a fixed 60 Hz it drops to 0.391 ms with a single cadence. The app presented an identical 59 fps median in both runs — frame production is perfectly steady, the display just holds each frame for an unpredictable length of time. That's what makes this nasty: it's invisible to every frame-rate metric, so it looks like the app got slow when nothing about the app changed. I spent most of a day profiling my own code before realising the app was never the problem. Workaround: force the built-in display to 60 Hz. Worth noting, because it complicates the picture: attaching a 60 Hz Studio Display makes the built-in smooth, but the Studio itself then judders — despite its own vsync cadence measuring perfectly stable. So refresh rate alone isn't the whole story, and there may be a second mechanism. The clean, reproducible, single-variable result is the ProMotion vs forced-60 Hz comparison on the built-in panel. If you can reproduce this on an M-series MacBook Pro on 27 beta, please file a duplicate referencing FB24091347.

In duo because of this design, most games like Call of Duty or Minecraft didn’t support this