How does focus update deferral work?

I incorrectly said in my previous post that during focus deferral I received symbolicated stack traces in the console - I actually meant the opposite. However, when testing on the simulator it seems that the traces are actually symbolicated:

2022-08-03 13:38:45.220746+0300 App[94677:24673225] [UIFocus] Starting to defer focus updates.
(
	0   UIKitCore                           0x000000011002ecfc -[UIFocusSystem _resetFocusDeferral] + 420
	1   UIKitCore                           0x0000000110031610 -[UIFocusSystem updateFocusIfNeeded] + 1164
	2   UIKitCore                           0x000000011003083c __44-[UIFocusSystem _focusEnvironmentDidAppear:]_block_invoke + 28
	3   UIKitCore                           0x000000011096c690 -[_UIAfterCACommitBlock run] + 64
	4   UIKitCore                           0x000000011096cac4 -[_UIAfterCACommitQueue flush] + 172
	5   libdispatch.dylib                   0x00000001038d85f4 _dispatch_call_block_and_release + 24
	6   libdispatch.dylib                   0x00000001038d9dbc _dispatch_client_callout + 16
	7   libdispatch.dylib                   0x00000001038ea814 _dispatch_main_queue_drain + 1316
	8   libdispatch.dylib                   0x00000001038ea2e0 _dispatch_main_queue_callback_4CF + 40
	9   CoreFoundation                      0x00000001803714d0 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12
	10  CoreFoundation                      0x000000018036bc60 __CFRunLoopRun + 1956
	11  CoreFoundation                      0x000000018036b0a4 CFRunLoopRunSpecific + 584
	12  GraphicsServices                    0x00000001892dcc8c GSEventRunModal + 160
	13  UIKitCore                           0x000000011052fe80 -[UIApplication _run] + 868
	14  UIKitCore                           0x0000000110533e28 UIApplicationMain + 124
	15  FontBrowseriOSTestApp               0x0000000102bb3ad8 main + 64
	16  dyld                                0x0000000102d6dfa0 start_sim + 20
	17  ???                                 0x0000000102e5d08c 0x0 + 4343582860
	18  ???                                 0x1805000000000000 0x0 + 1730789631793823744
)

Can anyone share some details about this focus deferral? Thanks.

Thank you for the detailed reply. I am indeed using -UIFocusLoggingEnabled YES for debugging this feature while working on it.

Are you dynamically loading content?

That is correct. I should have specified this from the start as, based on what I'm seeing online, it isn't a frequent use case.

Through trial and error I found a workaround to give the focus engine a valid view at all times: by using a root view with override var canBecomeFocused { true } for my VC, and requesting a focus update once I am reasonably certain there is at least one visible cell in the collection view (e.g. viewDidLayoutSubviews). Is there perhaps a better way to have the focus engine wait for a cell to appear and then move focus to it?

Even better, would there be a way to simply specify an IndexPath that should be prioritized for focusing whenever it becomes visible? It would help with another part of the overall keyboard focus feature that I'm working on.

UICollectionView and UITableView have delegate methods for the preferred focused index path that will be used. However if the focus system starts deferring, it waits for user interaction to act on that. I'd suggest to not do anything here. If you do not present content initially, the expected user experience is that focus shuts off again and only becomes active again when the user interacts with it.

I'd suggest to not do anything here. If you do not present content initially, the expected user experience is that focus shuts off again and only becomes active again when the user interacts with it.

Agreed, my intent was simply to customize the behavior of the focus engine very slightly in order to create a consistent experience; as the collection view is in fact populated in less than a second from showing its VC (this includes the animation from UICollectionViewDiffableDataSource.apply(_:animatingDifferences:completion:)), it is a bit jarring to sometimes have the focus moved to the correct item and sometimes not.

UICollectionView and UITableView have delegate methods for the preferred focused index path that will be used

Here I would like to suggest a clarification for the docs - collectionView(_:shouldUpdateFocusIn:) and indexPathForPreferredFocusedView(in:) only seem to be called for focus movements that occur after the UICollectionView first receives focus. This was not clear initially and was a pain to work around, as we need the custom behavior from those two methods even upon the first focus request since starting the app (e.g. to be able to focus the first item that is completely visible and does not intersect a sticky header after scrolling). This might have something to do with being in focus deferral mode, of course.

Thank you for your help on this topic and please feel free to challenge any incorrect statements I've made - at the moment I only have empirical knowledge on focus quirks.

Agreed, my intent was simply to customize the behavior of the focus engine very slightly in order to create a consistent experience

I get the point. Unfortunately there is currently no way to programmatically disable focus deferral. It would be great if you could file feedback to request this so we can track this properly internally.

indexPathForPreferredFocusedView(in:) only seem to be called for focus movements that occur after the UICollectionView first receives focus.

That sounds incorrect and if you can reproduce this in a sample, sending this over via feedback would be great. In fact it should be pretty much the other way around.

The delegate method should be called, even with focus deferral enabled. Although with focus deferral enabled the method will be called when focus runs the hidden update and not when the user starts interacting with it.

This method should only be skipped if selectionFollowsFocus is enabled and there is a selected cell, in which case that takes precedence since with selectionFollowsFocus enabled, the selected and focused cell should always be the same.

Sorry for the late reply. I will look at constructing a sample for sending via feedback.

This method should only be skipped if selectionFollowsFocus is enabled and there is a selected cell

Agreed, I made sure that this is not enabled anywhere in my code.