// the find
Cysharp/UniTask
Provides an efficient allocation free async/await integration for Unity.
UniTask replaces Unity's coroutine system and the standard Task<T> with a struct-based, zero-allocation async/await implementation that runs entirely on Unity's PlayerLoop. It's for Unity developers who are hitting GC pressure from Task or want coroutine-style frame timing control without the IEnumerator ceremony. Not relevant outside of Unity.
The struct-based UniTask<T> with a custom AsyncMethodBuilder genuinely eliminates the per-await allocation that makes Task<T> painful in hot game loops. PlayerLoopTiming integration is thorough — you can yield at any point in Unity's frame pipeline (PreUpdate, FixedUpdate, PostLateUpdate, etc.) rather than being stuck with the three or four timings coroutines expose. The async LINQ over IUniTaskAsyncEnumerable is a real implementation, not a stub — WhenEach, CombineLatest, Queue, Publish are all there and work with pull-based backpressure. UniTaskTracker in the editor window is genuinely useful for catching leaked tasks that would be invisible with standard Task.
UniTask instances cannot be awaited twice — this is by design from IValueTaskSource but it bites people migrating from Task who cache results. The workaround (UniTask.Lazy or .Preserve()) is documented but easy to miss, and the failure mode is undefined behavior, not a clear exception. WebGL and wasm support requires running everything on the main thread, which means UniTask.SwitchToThreadPool() silently doesn't work the way you'd expect on those platforms — the README mentions it but the constraint isn't surfaced at the call site. The DOTween integration requires a manual #define symbol (UNITASK_DOTWEEN_SUPPORT) which is a friction point that trips up new users. The .Timeout() method is explicitly discouraged in favor of CancellationToken — having an API that the docs say not to use is a design smell they haven't cleaned up.