Understanding Threads and Queues in Swift TurboModules

The presenter describes the main thread for UIKit updates, the JavaScript thread for React Native JavaScript, and the native modules thread for native module work. Synchronous TurboModule methods such as `getItem` run on the JavaScript thread, so blocking one can make the app unresponsive. Xcode breakpoints and thread names can help identify where a method is running.

Grand Central Dispatch lets developers submit closures to queues while the system manages its thread pool. `DispatchQueue.global().async` moves work to a background thread, and `DispatchQueue.main.async` can schedule follow-up work on the UI thread. The presenter recommends using async work in most cases because sync dispatch blocks the calling thread.

A custom dispatch queue created with only a label is serial by default, so tasks run one at a time in order. Adding the concurrent attribute lets tasks overlap: in the example, a second task runs before the first task finishes sleeping for two seconds. The presenter suggests queues for work such as file access or parallel network requests, and briefly mentions Swift actors as another option.

The presenter adds promise-based `getItemAsync` and `setItemAsync` methods, which resolve or reject instead of returning a value directly. The example moves storage work onto a custom concurrent queue and resolves the promise there; the JavaScript caller awaits the result. This avoids keeping long-running work on the shared TurboModule queue.

The presenter summarizes that native module calls begin on the TurboModule queue, while global or custom queues can handle background work. Heavy operations should not block either the main UI thread or the JavaScript thread. Send results back to those threads when their work requires them.