It looks as though this is actually a bug in UITableView. In my case it is triggered when the parent view lays out subviews but the table view is not yet visible - its height constraint is 0. At the point the exception is thrown the table view is actually in the view hierarchy - it is just invisible. IMHO it is not the responsibility of a user of UITableView to check its view state inside the internal implementation of its layoutSubviews method.

I thought Apple's bug tracking could not get any worse ... I was wrong. Feedback Assistant is a sad joke. Even the name betrays Apple's unrivalled arrogance - they don't have bugs; just feedback. Why oh why is there zero bug transparency provided - even to developers who enable the entire app ecosystem? I just want to see if my issue is already reported, and if so how widespread is it. I'd like to know "Am I going mad or are others experiencing my issue?". If the bug is not being addressed has anyone found a workaround? Where in the bug pipeline is my bug - has it even been acknowledged? Will it be fixed in the next release? Is there any plan at all to fix my bug? I can't believe that Apple think it acceptable that StackOverflow has become the place to track issues in their developer tools - complete with its masses of fud and incorrect advice. PLEASE FIX THIS.

This situation is insane. The Account Holder for our company is the CEO - he doesn't even know what a certificate is let alone the information needed to generate one or a CSR. Surely the Account Holder should be able to delegate this authority to a trusted executive such as the CTO or development team lead. It also doesn't help that he is in another timezone - 8 hours from my own.

@MobileTen That doesn't address the issue. The code in question is supposed to run on the MainActor's executor. If it's not this is a bug in the runtime.

This seems to only occur when @GlobalActor isolated methods/functions are called from closures. Something to do with the runtime dispatch mechanism and this annotation-based style of isolation.

As you investigate this, keep in mind that the main thread and the main queue are related but not exactly the same thing. This post has code that highlights that difference. I understand this but thousands of libraries use main thread checks as seatbelts which we can't just disable and the impression provided by what documentation exists for the MainActor is that it is a special-cased global actor with a single-threaded executor such that all calls isolated to the MainActor will be executed by the same thread. If this is not the case it breaks almost every Swift library in existence that makes display calls. I would expect Thread.isMainThread to always return true in a block isolated to the MainActor. I actually would have used some other test of isolation but prior to 5.9 there is none and I am forced to write code that supports iOS 14. That isn't the point of this issue though. I just used that thread test above because it is the only tool I have at my disposal to test this behaviour and MainActor is documented to behave in a manner that that test should always pass.