@MainActor annotations and DispatchQueue.main... only work if something is draining the main dispatch queue. Normally, calling RunLoop.main.run() or dispatchMain() on the main thread would be enough to solve this. The problem is, those those functions return Never, meaning if you have something else on the main thread that isn't using Dispatch etc., your environment will hang. This is notably the case on Android when running native Swift code within Java/Kotlin apps, which have their own run loop.
CFRunLoop has some variations of the above functions that run only for a short amount of time before returning. Using them allows draining the main queue in a cooperative manner alongside another run loop implementation. The problem is that CFRunLoop is a part of CoreFoundation, which by default is only built as a static dependency of Foundation. Unfortunately, Foundation and its dependencies (notably ICU) are larger than our entire app, which is not trivial (in the order of 1M LOC). So I think it's safe to say that Foundation and co will be bigger than many people's apps/libraries out there, which seems like a poor tradeoff to me.
So, how can we drain the queue without pulling in all of Foundation and friends? This week I discovered _dispatch_main_queue_callback_4CF and calling it periodically appears to do what we need. That assumption appears to be vaguely supported by this post, but it's not clear to me whether we are silently missing something by "only" calling that function, rather than the thousands of lines of C code in e.g. CoreFoundation's CFRunLoopRunInMode and other functions that one calls out to.
I'm just looking for some kind of official word on whether this is a Bad Idea™ or probably ok for now. Can anyone help in assessing that?