Guide for UniTask and Awaitable in Unity 6

[neuecc]

Unity 6 introduces the awaitable type, Awaitable. To put it simply, Awaitable can be considered a subset of UniTask, and in fact, Awaitable's design was influenced by UniTask. It should be able to handle PlayerLoop-based awaits, pooled Tasks, and support for cancellation with CancellationToken in a similar way. With its inclusion in the standard library, you may wonder whether to continue using UniTask or migrate to Awaitable. Here's a brief guide.

First, the functionality provided by Awaitable is equivalent to what coroutines offer. Instead of yield return, you use await; await NextFrameAsync() replaces yield return null; and there are equivalents for WaitForSeconds and EndOfFrame. However, that's the extent of it. Being coroutine-based in terms of functionality, it lacks Task-based features. In practical application development using async/await, operations like WhenAll are essential. Additionally, UniTask enables many frame-based operations (such as DelayFrame) and more flexible PlayerLoopTiming control, which are not available in Awaitable. Of course, there's no Tracker Window either.

Therefore, I recommend using UniTask for application development. UniTask is a superset of Awaitable and includes many essential features. For library development, where you want to avoid external dependencies, using Awaitable as a return type for methods would be appropriate. Awaitable can be converted to UniTask using AsUniTask, so there's no issue in handling Awaitable-based functionality within the UniTask library. Of course, if you don't need to worry about dependencies, using UniTask would be the best choice even for library development.

[MertBalkanRedAxe]

what is gonna be happen when unity introduces core clr in unity 7?
Is Unitask gonna be compatible with the core clr?

[tigran-sargsyan-w]

UniTask should continue to work on Unity’s CoreCLR (Unity 7+). UniTask doesn’t rely on Mono-specific internals; it provides its own AsyncMethodBuilder and integrates with Unity’s PlayerLoop, so it’s largely runtime-agnostic. In practice, that means the switch from Mono to CoreCLR doesn’t break UniTask’s core model. Unity’s built-in Awaitable is handy (especially for libraries that want zero external deps), but UniTask remains the more complete, production-oriented toolkit: frame-aware delays, WhenAll/WhenAny, fine-grained PlayerLoopTiming, CancellationToken first-class support, etc. A sensible approach is: if you’re writing a reusable library and want to avoid extra packages, expose Awaitable (you can still adapt to UniTask in app code); for apps/games, UniTask stays a great default. Practical tips as Unity rolls out CoreCLR: keep UniTask on the latest release, avoid mixing Task and UniTask without a reason (or convert explicitly), be mindful of SynchronizationContext differences, and test on the latest Unity previews/tech streams early. If this helps, please mark as Accepted—and feel free to ping for a minimal repro or migration checklist