I'm still trying to figure out the best route here. I should say the standard presentDrawable approach is usually described as "present as soon as possible" which also sounds like what I want, but in reality it seems to mean "present as soon as possible after all the other frames in the queue have been presented". From my investigations so far it seems likely that CAMetalLayer has some logic to handle pacing, but I haven't seen that described anywhere either in docs or WWDC talks and I'm struggling to figure out the logic it's using. For example if you look at https://developer.apple.com/videos/play/wwdc2019/606/ at 6:30 - the focus is on the command encoder for a future frame blocking on waitNextDrawable for a full frame, and how offscreen draws could be dispatched ahead. But for me there's an unanswered frame pacing question here too - the orange surface stays on the display for 2 frame periods, even though the following frame (shown in green in the Instruments trace) is fully complete well in advance of the swap interval where we'd expect it to display. It's as if some component (likely CAMetalLayer) has decided that a future frame has missed some submission deadline and so responds by delaying the presentation of the next one in the queue, even though it's ready to go. I think with CAMetalLayer I might just end up triggering rendering the following frame on the presentedHandler callback of the previous one rather than using CADisplayLink / MTLView at all. That way I can hopefully keep maximumDrawableCount at 3 so waitForNextDrawable should always be non-blocking, and guarantee presenting on the following VSYNC, but I don't want to be fighting against internal opaque CAMetalLayer logic that decides I'm not submitting frames fast enough to keep a full drawable queue. I'd love to understand more about all this - any references greatly appreciated!

Here's an instruments screenshots showing the correlation with activity in those bluetoothd threads: And a wider view that shows the 10 second pattern in this activity: I've also posted this via feedback assistant as with the ID FB11469459

I'm still seeing this behaviour on iPhone 12 Pro on 16.0.2 and the 16.1 beta. I have noticed it's a bit device-specific though, and doesn't appear on earlier devices (iPod 7th Gen for example). One other finding of interest - I wrote a quick iOS app for the peripheral side of things and it still reproduced there (with the peripheral running on iPod 7th Gen and central on iPhone 12 Pro). However I also implemented the L2CAP channel and noticed these updates did not seem to be disrupted in the same way. I've made both the peripheral and central test apps (very rough and ready) public on GitHub: https://github.com/tangobravo/ios-bluetooth-central https://github.com/tangobravo/ios-bluetooth-peripheral Here's an Instruments screenshot showing when the updates are received, when they are sent both via the channel and via an attribute update: Note the gap in the characteristic updates still seems to correlate with bluetoothd activity looking at the CPU states data shown on the CPU tracks (for some reason the bluetoothd thread views are missing the data now unfortunately). So that at least gives hope for a workaround - I'm investigating implementing the L2CAP approach on my actual peripheral now.

It looks like ShinyQuagsire has discovered the answer here: https://developer.apple.com/forums/thread/758804 There are some private Metal Texture formats accessible from AppleGPUFamily4 that also do RGB conversion. So I guess the fact the these do exist means technically that format is "metal compatible" but it would be great to have them declared in public headers and documented so they can be used by third party apps.

Thanks for the reply, great info. So actually it's probably the case that in iOS 18 the system has added another input source to the runloop, whereas in earlier versions when I invalidated the displayLink the thread basically busy-looped on the run method so the performBlock happened essentially immediately. I've switched the code for exiting the render loop to this, which shouldn't rely on any of the undefined behaviour and has been working in my testing. // Schedule a block on the run loop to allow the thread to exit CFRunLoopRef rl = [_renderThreadRunLoop getCFRunLoop]; CFRunLoopPerformBlock(rl, kCFRunLoopDefaultMode, ^{ self->_continueRunLoop = NO; // Exit current runMode:beforeDate: method CFRunLoopStop(rl); }); // Wake up the run loop to execute the scheduled block immediately CFRunLoopWakeUp(rl); Can you clarify the circumstances in which mach ports are leaked? The while loop in the original post is in a function launched as a new thread with pthread_create, my code only adds a CADisplayLink as an input source before the while loop, and when ending the thread I call [displayLink invalidate] and then set the loop variable so the pthread function can exit cleanly. Is there still a mach port leak in that case? To give a bit more context, this is a dedicated render thread for a custom metal view. The starting point for my code came from this Apple sample: https://developer.apple.com/documentation/metal/onscreen_presentation/creating_a_custom_metal_view?language=objc It spins up a render thread when didMoveToWindow is called, as that's the first time there's a UIScreen available to get a CADisplayLink, and that's the only app-side input source the run loop will ever need. When the view moves off a window it then [displayLink invalidate] is called which removes the source from the run loop. I saw a couple of issues with the code in that example - firstly the render thread isn't stopped when the display link is invalidated. If the system hasn't added any other input sources, the render thread will be effectively busy-looping at this point (runMode would return immediately as there are no sources). Secondly, the next time the view is added back to a window, a new render thread is started. There's some code that sets _continueRunLoop to NO before starting the new render thread to allow any previous render threads to exit, but no actual guarantee the render thread has checked that flag and exited before setting the same ivar back to YES to get the new thread to run. My code fixes these issues (and also switched to pthreads) but it still seemed reasonable to me to have the lifetime of the render thread (and related display link, and run loop) all driven by whether the view is attached to a window. If it's not possible to implement that without leaking mach ports then I can have a rethink...

Thanks for the all the info, I think I'll stick with my current setup in that case. There's usually only one of these views on screen at once - and typically only one ever created in the app, but I wanted it to clean up after itself if apps did choose to dealloc it. It felt like a reasonable architecture to encapsulate the render thread behaviour in the view class as it is tied to when the view is added to a window. I do want a dedicated render thread and also wanted to follow the guidelines for them from this WWDC talk: https://developer.apple.com/videos/play/wwdc2018/612/?time=1146 I switched to pthreads for the thread creation so I could set those scheduler attributes at thread creation time as shown in that video. I'm happy enough with using pthreads directly for now.

I'm also trying to figure out if the Game Controller iOS support extends to generic HID BLE gamepad peripherals and the limited documentation of what is supported is proving challenging. I don't know if Game Controller always filters to known controllers only or if generic ones are supported but I just haven't found the right setup yet. I've tried various HID report descriptors from basic 2-axis, 2-button ones to ones copied from supported controllers. They successfully pair but never show up in the Game Controller framework as controllers in either macOS or iOS. They do work in Windows, Android, and Chrome on macOS through the gamepad API (presumably using some other HID device implementation rather than Game Controller framework) These controllers already exist and are BLE only, so I'm hoping a firmware update will enable them to work with the Game Controller framework on iOS / macOS too. I'll stop trying if it's just not something that's possible without some sort of hardware license from Apple.

Thanks Kevin, great to have the confirmation, that saves me a lot of time of trial and error. Our controllers were designed as part of our "Zapbox" iPhone-powered VR / MR product. They come as a left/right pair and have the same inputs as Meta Quest ones, so a bit non-standard and not a perfect match to the Extended Gamepad profile, but could get close as a pair (a bit like the iOS Joy-Con support). Given the low volume and non-standard setup I won't waste your time with a request to add it specifically. On a separate note, now iOS does support Joy-Cons we're also considering supporting those as controllers with our apps. Unfortunately motion data isn't reported from Joy-Cons with the GameController API even when only one is connected. When two are connected iOS combines them into a single GameController so it would need new API to expose two different sets of motion data in that case too. I will file a bug on that.