We ship a two-player real-time GameKit game. On iOS 27 the app crashes inside GameKitServices on the second real-time match of any app session — nine times out of nine yesterday. Filed as FB24789094 (and FB24788999 for a separate reinvitation problem). Posting the measurements here because the unified log makes the mechanism visible, and because everything I tried at the app level failed — maybe somebody has the missing piece. THE CRASH Main thread, no application frame anywhere on the stack: CFRetain + 52 GCKSessionReceiveDOOB + 1632 -[GKSessionInternal receiveDOOB:fromPeer:inSession:context:] + 320 -[GKSessionInternal(_private) tellDelegate_didReceiveBand_RetryICE:] + 212 __NSThreadPerformPerform + 264 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ EXC_BAD_ACCESS (SIGBUS), EXC_ARM_DA_ALIGN at 0x9 (0xa in one report). In every report the faulting address is exactly x0 + 8, and x0 is 1 or 2 — CFRetain is handed a small integer, not a pointer. A use-after-free would fault on a large plausible-looking address; 1 and 2 are not addresses at all. Address Sanitizer agrees: no heap error is reported before the fault, only __asan::ReportDeadlySignal directly above the same three GameKitServices frames. It reads like type confusion in the RetryICE band path. Not the SDK: a build made with Xcode 26.6 against iphoneos26.5 crashes identically — same stack, same registers. The peer's OS does not matter either (iPadOS 17.7.11, iOS 26.6.1 and iOS 27.0 all seen on the other side, and in one case an older build of our own app). Only the crashing device is always on iOS 27.0 (24A435), an iPhone 15 Pro. RECIPE Two devices, two Game Center accounts. Form a two-player real-time GKMatch — GKMatchmaker.findMatch(for:) or an invitation, both reproduce. Wait for the peer to connect, call finishMatchmaking(for:). Play for ten seconds or so, so data really flows. End it: match.disconnect(), release the GKMatch. In the SAME process, form a SECOND real-time match. Play. The crash lands roughly ten to thirty seconds after the second match starts exchanging data. A first match in a freshly launched process has never crashed for us. Out of eleven app sessions that reached a second match, two were force quit by hand during other tests and the remaining nine all crashed here. THE SESSION IS NEVER RECLAIMED GameKit runs one "com.apple.gamekitservices.gcksession.recvproc" / "sendproc" thread pair per live real-time session, in the app's own process. You can count them from inside the app, which turns out to be the only way to see what is going on: var threads: thread_act_array_t? var count: mach_msg_type_number_t = 0 task_threads(mach_task_self_, &threads, &count) // then pthread_from_mach_thread_np(threads[i]) + pthread_getname_np, and compare the name Measured across one app session: after Game Center authentication, before any match ......... 0 first match live ........................................... 1 right after match.disconnect() returns ..................... 1 <- not reclaimed before the second match is adopted ......................... 2 right after the second match's disconnect() ................ 2 Every crash report shows two of those pairs alive, although the app holds exactly one GKMatch at a time and releases the finished one the instant disconnect() returns. The same leak is visible on iOS 26.6.1 (an iPhone 11 Pro leaks identically) — it just does not crash there. WHAT THE LEFTOVER SESSION DOES Each match gets its own CDXClient. The first match's is never torn down, and keeps poking its hole on a 30-second keep-alive, on the same local port (:16402) the second match then binds: 15:28:05.117 <CDXClient: 0x155872e40> requesting-hole-punch <- match 1 15:28:35.289 <CDXClient: 0x155872e40> requesting-hole-punch <- match 1, +30s, match already over 15:28:50.197 <CDXClient: 0x12d4bda40> requesting-hole-punch <- match 2 15:29:05.287 <CDXClient: 0x155872e40> requesting-hole-punch <- match 1 again, 4s before the crash GCKSessionCreate:6425 globalscopelaunch appears once per process; the second match only does 6509 globalscoperequest and reuses the global scope. During the second match's ICE setup a packet arrives belonging to no live session: -[CDXClient handleFDEvent]:1066 packet-from-unknown-session -[CDXClient handleFDEvent]:1067 Incoming packet from unknown session. SID = ... immediately followed by [ERROR] ICEStopConnectivityCheck:2763 ICEStopConnectivityCheck() found no ICE check with call id (...) [ERROR] gckSessionCheckPendingConnections:1545 iICEChecksLeft=0, iUnconnectedNodeCount=0, iDDsExpected=1 Those lines appear exactly three times in a 28-minute window, all three in the two processes that went on to crash, never during a first match. About fourteen seconds later the RetryICE band is delivered and CFRetain is called on the garbage. WHAT DID NOT WORK Releasing the GKMatch immediately after disconnect(). The session threads stay. Waiting. Gaps of 17, 19, 22, 25, 30 and 45 seconds between the two matches all crashed. Tearing the match down cleanly. I suspected that calling disconnect() while match.players was still non-empty was the trigger — five out of five such teardowns were followed by a crash. So I made the quitting side announce its departure, wait for match(_:player:didChange:) to report the peer gone, and only then disconnect. It works (disconnect now runs with players == 0) and it changes nothing: the count still reads 1 afterwards, and the next match still crashes. Worth saying explicitly, because the correlation was strong enough to look causal. Skipping finishMatchmaking(for:). No effect. The only thing that reliably avoids it is allowing a single real-time match per app launch, which is a poor thing to ship. QUESTIONS Is there a supported way to make GameKit release a finished GKMatch's session inside the process? A GKMatch that never connected (peer wait timed out, disconnect() on an empty match) appears to leave the same residue, so it is not about how the match ended. And has anyone else seen GCKSessionReceiveDOOB / tellDelegate_didReceiveBand_RetryICE? I could not find a single mention of these symbols anywhere.

Hi, in RealityKit, AudioPlaybackController exposes duration, gain, speed, play/pause/stop, and a completion handler, but I can't find a way to read the current playhead position while a resource is playing. I need this to trigger animations and other timed events in sync with the audio. Is there a supported way to read the current playback position on AudioPlaybackController? If not, is this planned any time soon? Also, is there a sample-accurate way to start/keep audio playback in sync across multiple entities in RealityKit? Appreciate any guidance, thanks.

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.

Hey guys How do i create a level in realitykit ? and how do i then load it in code ? is it a file i need to drag and drop into the xcode the same as .reality file i use for assets? Thank you

Metal already provides a strong precise floating-point contract. With fast math disabled (mathMode = .safe and mathFloatingPointFunctions = .precise, or -fno-fast-math), the Metal Shading Language specification requires correctly rounded FP32 add, subtract, multiply, reciprocal, divide, sqrt, rsqrt, and fma. I am looking for clarification and, if necessary, API support for the two remaining pieces needed for portable bit-exact numerical shaders: Arithmetic rounding mode MSL §8.2 says either round-to-nearest-ties-to-even or round-toward-zero may be supported for floating-point operations. I cannot find a way to select or query the arithmetic rounding mode. The newer MTLCompileOptions.floatingPointConversionRoundingMode appears to apply only to narrowing float-to-float conversions, not arithmetic operations. Do all currently supported Apple GPU families use round-to-nearest-ties-to-even for precise FP32 add/subtract/multiply/divide/sqrt? If so, could that be made a documented guarantee? Otherwise, could Metal expose an arithmetic rounding-mode compile option and a corresponding MTLDevice capability query? Denormal behavior MSL §8.1 and §8.5 permit denormalized FP32 operands and results to be flushed to zero, including with fast math disabled. I cannot find a control or capability query for preserving denormal inputs and results. Do current Apple GPU families support denormal-preserving FP32 arithmetic? Could Metal expose a preserve/flush mode and a MTLDevice query? A convenient end state would be a queryable strict FP32 configuration combining: safe math; precise FP32 functions; contraction disabled when separate rounding points are required; round-to-nearest-ties-to-even arithmetic; preserved FP32 denormal inputs and results; defined signed-zero, infinity, and NaN behavior. My use case is deterministic GPU numerical simulation. A small compute-shader probe can identify effective rounding and denormal behavior on one GPU/OS/compiler combination, but it cannot provide the portable or future-proof contract needed by applications and higher-level APIs such as WebGPU. Related cross-API work: SPIR-V/Vulkan: https://github.com/KhronosGroup/SPIRV-Registry/issues/448 HLSL/DXIL/D3D12: https://github.com/microsoft/hlsl-specs/issues/926 WebGPU/WGSL umbrella issue: https://github.com/gpuweb/gpuweb/issues/2259 Relevant Metal documentation: Metal Shading Language Specification, §§1.6.3 and 8.1–8.5: https://developer.apple.com/metal/Metal-Shading-Language-Specification.pdf MTLCompileOptions.mathMode: https://developer.apple.com/documentation/metal/mtlcompileoptions/mathmode MTLCompileOptions.floatingPointConversionRoundingMode: https://developer.apple.com/documentation/metal/mtlcompileoptions/floatingpointconversionroundingmode

Hi all, This has been bothering me for quite a while. Basically my new iMac (bought for a few months only) started to crash randomly. I went to the genius bar and they couldn't do anything to identify the issue, I tried reinstalling the OS and even reinstalling an older version of Mac OS as well, but still seeing this issue. Today it happened twice and below are the details: Mac specs: Model Name: iMac  Model Identifier: iMac20,1  Processor Name: 10-Core Intel Core i9  Processor Speed: 3.6 GHz  Number of Processors: 1  Total Number of Cores: 10  L2 Cache (per Core): 256 KB  L3 Cache: 20 MB  Hyper-Threading Technology: Enabled  Memory: 16 GB  Boot ROM Version: 1554.100.64.0.0 (iBridge: 18.16.14556.0.0,0)  Serial Number (system): xxx  Hardware UUID: xxx  Activation Lock Status: Enabled The DiagnosticReports around the time it crashed has a lot of files with .gpuRestart, e.g.: Kernel_2021-04-27-213412_Zhuzengs-iMac.gpuRestart and file WindowServer_2021-04-27-213319_Zhuzengs-iMac.userspace_watchdog_timeout.spin in between. The details of the the first gpuRestart file Tue Apr 27 21:32:13 2021 Event: GPU Reset Date/Time: Tue Apr 27 21:32:13 2021 Application: Path: Tailspin: /Library/Logs/DiagnosticReports/gpuRestart2021-04-27-213213.tailspin GPUSubmission Trace ID: 0 OS Version: Mac OS X Version 10.15.7 (Build 19H1030) Graphics Hardware: AMD Radeon Pro 5300 Signature: 2 Report Data: GPU Log Version: 1 Restart Channel: 18 VMPT --THE STATE OF THE DRIVER AMDRadeonX6000_AMDNavi14GraphicsAccelerator state: ENABLED PCIe Device: [3:0:0], DID=0x7340, RID=0x47, SSID=0x219 TotalVideoRAMBytes: 0x00000000ff000000 (4278190080) Uptime 21:50:05.077572 [00] Channel: GFX, last reset at 0:00:00.000000 CompletedTS = 0x005be078, SubmittedTS = 0x005be079 SentTS = 0x005be078, sent at 21:49:00.896511, ScheduledTS = 0x005be079, submitted at 21:50:03.672539 Wait for Channel 18, TS 0xef924 PendingEvent: YES NumberOfPendingCB = 1, FirstPendingTS = 0x005be079, LastPendingTS = 0x005be079 FirstPendingCB: ProcessID = 225, ProcessName = WindowServer, SubmitContext = Unknown (0) GPUAddress = 0x0000000431cef000, Size = 0x000001d3, VMID = 2 ContentValidation = PASS Buffer range 0x0 .. 0x100:c0012800 80000000 80000000 c0026900 00000081 80000000 40004000 c0026900 By searching online this seems to be happening to others as well but I failed to find a common fix for this. Any help would be hugely appreciated!!!

Hello Apple engineers, I’m trying to determine whether what I’m seeing is expected behavior or a software issue with the new M5 Pro platform. System MacBook Pro (M5 Pro) Latest macOS Beta External 5K 165Hz monitor connected via DisplayPort Refresh rate correctly detected as 165Hz What I observe The display itself is clearly running at 165Hz. For example: Mouse cursor movement is extremely smooth. Dragging the desktop by holding an empty area is also perfectly smooth. However: Moving application windows feels much closer to 60Hz. Scrolling in Safari, Chrome and other applications also appears to run at a much lower frame rate than the display refresh rate. Mission Control animations sometimes show similar micro-stutters. This makes the cursor and desktop movement noticeably smoother than normal window animations. ⸻ Troubleshooting already performed Different DisplayPort cables Different timing configurations Different resolutions / HiDPI modes DSC enabled and disabled Refresh rate confirmed at 165Hz Same behavior across multiple applications The issue appears unrelated to the monitor itself because the cursor is clearly rendered at the full refresh rate. ⸻ Additional observation Interestingly, I previously used another external 4K 144Hz HDR monitor and did not notice this behavior. I also found another M5 Pro user reporting nearly the same issue: external 165Hz display smooth cursor window dragging jitter / micro-stuttering At the same time, I haven’t found similar reports from M4 Pro or the base M5 running the same monitor. ⸻ My question Could this be related to the new M5 Pro display pipeline (WindowServer, Display Engine, or DCP)? Is there any known issue regarding high-refresh-rate external displays on the M5 Pro platform? Or is there additional diagnostic logging (WindowServer, DCP, Metal, etc.) that would help identify whether frames are actually being presented at the display refresh rate? I’d be happy to provide: sysdiagnose WindowServer logs Screen recordings Display timing information IORegistry dumps if they would be helpful. Thank you!

When we use MTLBlitCommandEncoder.copy to copy from buffer to textures with specific size, we find that the texture content is corruppt. The specific rules we found are: On Apple GPUs (reproduced on Apple M5, macOS 26.3 and iPhone 13 / A15), for ASTC textures uploaded to private storage via the blit encoder, the sampler / texel-fetch mis-addresses the tail of a mip level when ALL of the following hold: that level's texel width is an exact multiple of the 16 KB page width (32 blocks) — 128 texels for ASTC 4x4, 192 for 6x6, 256 for 8x8; the texture width is not divisible by 2^level (a partial block column exists in the chain); that level is taller than one page (>32 block rows). The level's first 128 texel rows (first page row, 4x4) are always read correctly; everything beyond is mis-addressed. Reads landing on unmapped/invalid memory decode as opaque magenta (1,0,1); reads aliasing valid memory show wrong image content. This produced visible purple artifacts in a shipping game (impostor tree atlas, 514x1024 ASTC 4x4, mip2 bottom half). The minimum reproduce code is: ASTCMipTailBugRepro.swift The output is: 514x1024 blit(private) mip2: CORRUPTED (bottom of mip2 mis-addressed) 512x1024 blit(private) mip2: INTACT 514x1024 replaceRegion mip2: INTACT

I have a metal kit view and drain the draw method of its delegate like shown below. Let's say I have one or more MTLBuffers with vertex resources bound via the argument table. When is it ok to drop these buffers? As far as I know one cannot schedule a completion handler In Metal 4 and I haven't been able to find any documentation about the lifetime requirements here. Any pointers/ideas appreciated. class RenderCoordinator: NSObject, MTKViewDelegate { public func draw(in view: MTKView) { let commandAllocator: any MTL4CommandAllocator = ... let commandBuffer: any MTL4CommandBuffer = ... let commandQueue: any MTL4CommandQueue = ... guard let drawable = view.currentDrawable else { return } commandBuffer.beginCommandBuffer(allocator: commandAllocator) let state: any MTLRenderPipelineState = ... let encoder: any MTL4RenderCommandEncoder = ... let argTable: any MTL4ArgumentTable = ... encoder.setRenderPipelineState(state) encoder.setArgumentTable(argTable, stages: .vertex) commandBuffer.endCommandBuffer() commandQueue.waitForDrawable(drawable) commandQueue.commit([commandBuffer]) commandQueue.signalDrawable(drawable) drawable.present() } }

I was using Times New Roman and trying to use superscript numbers, but found out that Times New Roman only has superscript numbers 0, 1, 2, 3, ¹ (like so) and since I'm writing out transcriptions of pinyin, I also need superscript 4, 5, 6, 7. When I do that, the font changes to Lucida Grande automatically. I would like to change the default unicode font/alt font from Lucida Grande to EB Garamond (downloaded from Google) since it more closely resembles Times New Roman and unfortunately, I need to keep the font as close to Times New Roman as possible. Is there a way to change the default the computer chooses to when Times New Roman/alt font fails unicode? Alternatively, is there a font that looks exactly like Times New Roman that has the superscript numbers 0-9? 2022 laptop, M2, Tahoe 26.6.1 Move post at will if need be.

Tengo un iphone 13, estoy con ios 27 ultima beta reciente y juego efootball mobile pero anda horrible. Anda muy pesado.

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.

Hey everyone 👋 I'm trying to initialize a part of a CALayer hierarchy on a background thread and then attach the root of that hierarchy to a CALayer that backs a UIView. The motivation is to keep the main thread responsive when constructing a complex layer hierarchy. This isn't a case where I'm creating two or three layers and then switching back to the main thread. The hierarchy can potentially contain a large number of layers, with animations being created/configured for those layers as well. My first approach was to create and configure the layers entirely on a background thread. While the output might be the expected one (not always), CoreAnimation emits an assertion along the lines of: "Modifications to the layer tree from a background thread may not be committed" (or something like this). This makes sense to me if implicit CATransaction is thread-local. In that case, the implicit transaction opened by the layer modification on the background thread would not be part of the transaction that is already open on the main thread. Therefore, committing the main-thread transaction would not commit the changes made on the background thread. My second approach was to explicitly create and commit a CATransaction on the background thread. This appears to be accepted by Core Animation's threading model, but I'm seeing unreliable results. Sometimes parts of the hierarchy are missing, and in other cases the hierarchy is present but the animations don't appear to run at all. I do understand that this is private behavior of the framework, but I wanted to know if what I am trying to achieve is possible and, if so, what the solution would be (obviously if you can share this information). Besides this, I would also like to know what behavior CATransactions have when they are created on different threads. What I mean by this is that the transactions work as a stack, and the changes are committed when the stack is empty. Does this behavior still apply when having transactions on different threads? Any weird behaviours that might appear between transactions operated on main vs background threads? Thank you! Vlad.

When constructing a MTLIndirectAccelerationStructureInstanceDescriptor, one specifies an accelerationStructureID. In the equivalents in both Vulkan and DirectX12, one can set it to zero to be an "inactive" instance. However, on Metal, this field does not appear to have any documentation, and thus it is difficult to figure out if there is similar behavior (and no other Metal documentation seems to mention this). Does setting this field to 0 (i.e. null) disable the instance? If not, is there any other way to have an equivalent effect?

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 been using a small macOS research project to exercise Metal with a workload that differs from rendering and dense machine-learning kernels. Autolykos v2 is useful for this because it combines a large, height-dependent working set with pseudo-random reads, integer-heavy hashing, sustained execution, and periodic replacement of the dataset. The project happens to be a miner, but my question here is strictly about Metal compute behaviour. On the Apple M4 system used for these measurements, the full dataset contained 216,430,305 elements of 32 bytes each: 6.93 GB, or about 6.45 GiB, held in a .storageModePrivate buffer. For every nonce, the search kernel: computes an index seed, performs 32 pseudo-random 32-byte dataset reads, accumulates the eight 32-bit limbs into a 256-bit sum, and applies a final BLAKE2b compression and target comparison. The normal dispatch uses 128 threads per threadgroup. The wider pipeline also builds the next height's dataset in chunks on a separate command queue while search continues, and keeps two search command buffers in flight. I record command-buffer wall time, gpuStartTime/gpuEndTime, unions of overlapping intervals, and thermal state. To estimate the ceiling imposed by the random gathers, I added a non-consensus microbenchmark. It retains the normal seed calculation, index distribution, all 32 dataset reads, and the complete accumulation, but omits the final BLAKE2b compression. The accumulated result remains observable through a comparison, so the gather loop cannot simply disappear. I expected this stripped kernel to be at least slightly faster. Instead, an order-balanced campaign on an M4 produced: complete search kernel: 3.108 million nonces/s median active throughput gather-only kernel: 2.952 million nonces/s ratio: 105.3% All four same-round ratios were between 103.18% and 105.74%. Each measured run used the full dataset, a 30-second search interval, an excluded warm-up, and a start-temperature gate below 50 °C. Both compute pipeline states reported maxTotalThreadsPerThreadgroup == 1024. My conservative conclusion was not to pursue speculative register-pressure or manual memory-level-parallelism rewrites. The access pattern appears sufficiently dominant, while the supposedly simpler microbenchmark may have changed the compiled pipeline in a way that makes it a poor upper-bound model. My questions are: Can removing the trailing arithmetic legitimately make a memory-latency-heavy Metal kernel slower by changing register allocation, instruction scheduling, or the amount of useful latency hiding? Or would you first suspect a flaw in this kind of gather-only benchmark construction? Also, which Metal GPU counters are the most reliable way to distinguish memory-latency saturation from register-limited occupancy in a long-running compute kernel? I am looking at compute occupancy, buffer and ALU limiters, bandwidth, and cache behaviour, but maxTotalThreadsPerThreadgroup alone is clearly too coarse to explain the result. This is one hardware-specific observation rather than a general claim about Apple GPUs. If useful, I can reduce the workload to a smaller standalone reproducer. The source code, benchmark driver, and complete campaign report are available here: https://github.com/giffeler/ergometal The detailed measurements and validation procedure for this comparison are documented here: https://github.com/giffeler/ergometal/blob/main/Benchmarks/2026-08-15-search-gather-ceiling-ab.md

I know this might be a peeve of mine, but looking into programming a simple Metal4 Compute Shader example, essentially updating the Performing Calculations on a GPU example code to work with CPP and Metal4. I found that MTL::Allocation and MTL::Buffer pointers can't be used interchangeably when you are trying to add allocations to a MTL::ResidencySet, this is forcing you to: Know by heart that they inherit from each other and that you can just cast them (this is a bit suspicious though, it did work for me). Forcefully either C-cast or reinterpret_cast the MTL::Buffer pointer to a MTL::Allocation pointer as the MTL::ResidencySet will only accept that type. I might as well just be plain wrong about how this is used, any tips on correct usage in that case? Is there any expectation to either provide a typecast operator or add inheritance to support the expected behaviour seen in Swift and ObjC, which is just passing the thing? Opened a report with # FB24534953 with some extra information. Bear in mind that the example code uses Premake5, but it can generate an Xcode solution easily.

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!

I've just downloaded the Xcode 27.0 beta 5 on a macOS 26.6.1 machine and tried to build my app (which includes Metal CoreImage kernels). I'm met with a new (to me) error; /Users/…/Developer/…/air-lld:1:1 symbol(s) not found for target 'air64_v28-apple-macosx26.0.0' and from the build log; air-lld: warning: ignoring file '/Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage.metallib', file AIR version (2.9) is bigger than the one of the target being linked (2.8) air-lld: error: symbol(s) not found for target 'air64_v28-apple-macosx26.0.0' metal: error: air-lld command failed with exit code 1 (use -v to see invocation) I have no MTL_LANGUAGE_REVISION in my build settings. If I add one, with value Metal41 the app builds fine, but crashes at runtime as Metal 4.1 isn't supported on macOS 26. I imagine this is a beta Xcode and or macOS SDK bug, is there a workaround?

like: let mat = try await ShaderGraphMaterial(named: "matname", from: "reality") currently I use an USD file with materials like so and it works: try await ShaderGraphMaterial(named: "/Root/matname", from: "file.usda", in: appBundle) when i try it with .reality i get "NameNotFound". so is it possible or do i have to have a bunch of dummy entities with my materials assigned so i can find the entity>components>material? or what's the best way to author materials in RCP3 for quick access in realitykit?