This has a feel of it solved a race condition due to scheduling something on a few ticks later. So it might accomplish not only running something on the main queue but also sneakily after something else finished. For example if you call something like this at the end of view did load, other code that also runs on the main thread may run before it. It's async.
Having said that, it kind of feels hacky. I have certainly seen this in various codebases and I can't comment on react native but just with standard iOS programming it often points to a lack of understanding of lifecycle or similar order of when things are happening.
Isn't this the standard "Let the queue pump events" technique for dealing with the async UI elements in iOS that don't always behave like you expect them to - such as the system alerts? I mean, I'm not justifying this code, which looks quite weird, but one of the reasons for it may be that the framework has to allow events to pump through the iOS queues, such that events propagate all the way through to the system alerts ..
Having said that, it kind of feels hacky. I have certainly seen this in various codebases and I can't comment on react native but just with standard iOS programming it often points to a lack of understanding of lifecycle or similar order of when things are happening.