I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.

The firestore API was designed before swift actors existed. We do intend to improve the situation, but this needs to be carefully examined as the SDK is written in C++. I will add this to our todo list, but we also won't have capacity to address in the near future.

Thanks for the report though!

@wu-hui I understand that fully supporting Swift concurrency might be a significant task. However, I have a question about thread safety: is it safe to access QuerySnapshot or DocumentSnapshot across different threads?

For instance, we listen to Firestore on a utility queue by setting firestoreSettings.dispatchQueue = DispatchQueue(label: "firestore", qos: .utility) because we often handle large collections. However, the converted data sometimes needs to be consumed by the UI on the main thread. Therefore, I'd like to know if it's safe to pass the snapshot objects between threads.

One suggestion is to do the parsing while still on the background thread, then just passing a parsed (Sendable, plain value type) model back to the main thread.
Would that work for you?

Yes, that works, but it does create some difficulties. One of the main challenges is the need to frequently check metadata in DocumentSnapshot, such as isFromCache and hasPendingWrites. While it's certainly feasible to create a wrapper type and perform the parsing on a background thread, I find it challenging to locate clear documentation on the thread safety guarantees provided by the Firestore library. So it would be great if there is an official documentation/guidance on the thread safety of these classes :)