Question for someone skilled in UIKit and event handling:
Important: This bug only happens on newer iPhones (13 for sure, also possibly 12), never on older ones. A 2018 iPad also does not show the bug, though newer ones might (no reports yet). iOS is up to date (15.2.1 or 15.3) in all cases.
When CoreFoundation dispatches touch events to my Qt 5.15.2/6.2.2-based iOS app, sometimes the traceback shows that UIKit's __processEventQueue is being invoked via updateCycleEntry and _UIUpdateSequenceRun rather than via __eventFetcherSourceCallback (the normal way of things). When that oddity happens, and my touch handler posts a dialog and spins an event loop to wait for user response, nothing is painted until that touch handler has returned (i.e., it hangs); in the normal case, that nested event loop gets update events, accomplishes the expected painting, and handles the user response as expected.
It seems wrong to me for UIKit to be dispatching a touch event while it's inside its update cycle! (Not too surprising, under that scenario, that my touch handler's local event loop wouldn't receive even more update events while it's running.) Searching the Web turned up some more recent crash reports where the traceback shows the same habit of dispatching GUI events while updating (here, for example). I wonder if this might be a general problem with newer models.
Details:
[problem case]
-[UIApplication sendEvent:] __dispatchPreprocessedEventFromEventQueue __processEventQueue updateCycleEntry _UIUpdateSequenceRun schedulerStepScheduledMainSection runloopSourceCallback __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__
[success case]
-[UIApplication sendEvent:] __dispatchPreprocessedEventFromEventQueue __processEventQueue __eventFetcherSourceCallback __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__