> Cocoa is incredibly fragile about the main thread, so you need to be super careful what runs in what queue.

This basically just boils down to "don't touch the UI off the main thread". There are some exceptions with CoreAnimation, but other than that the main thread checker will yell at you if you do something wrong.

The main thread checker is a godsend. Enabling it + TSAN + Core Data concurrency assertions have reduced the threading bugs my team deals with to almost 0.

Anywhere we're doing something specific, we make liberal use of `dispatchPrecondition(condition: .onQueue(mySerialQueue))` or `assert(Thread.isMainThread)`.

Even in places where we are doing multithreaded UI rendering (mostly CATiledLayer), it's become a non-issue. It's a night-and-day difference compared to 5+ years ago.

> Cocoa is incredibly fragile about the main thread

That basically applies to all UI framework. At least I'm not aware about one which provides good support for accessing it from another thread.

There is obviously a reason for it, which is that UI frameworks are incredibly stateful, and trying to manipulate lots of state from multiple threads at once rarely works out well.

I think BeOS tried to and it did not went well with common threading issues poping up on BeOS apps.

Not sure if Haiku has any improvements regarding it.

Not sure what you mean when you say "common threading issues"; the entire point of the Be design was to force all threads to use message-based communication instead of shared memory for virtually all uses, and mandatory locking otherwise. It's extremely effective.

It was quite common to see BeOS apps crashing due to not handling the threads communication properly.

Having the whole OS being so multithreading heavy was a novelty for the large majority of developers and quite easy to make mistakes.