Restrictions on Input, UI, Async
This page lists everything that is currently not supported in T#
This section rounds up all input-related limitations, asynchronous code restrictions, and other notable Unity patterns that are not supported in T#. It also covers UI events, reflection methods, and a few important workarounds.
INPUT & UI
π±οΈ IPointer Events
In Unityβs UI system, interfaces like IPointerClickHandler
are used to detect and respond to user input events like button clicks or hovers. This is not supported in T#.
π What you instead need to do in T# to detect user input:
Use manual input checks inside Update()
or OnMouseDown()
if available.
ποΈ DOTween for UI Animations
DOTween is widely used in Unity for smooth tween-based animations but DOTween is only partially supported in T#.
π What works in T#:
Basic one-liners like this are supported:
Advanced features like custom Tweeners
, complex Sequences
, and chaining may not work:
ASYNC & REFLECTION
β async
/ await
async
/ await
In Unity, asynchronous methods using async Task
are often used for non-blocking workflows. This is not supported in T# .
.
π What you instead need to do in T#: Use coroutines for delays or async-like behavior.
β Task.Run()
Task.Run()
Unity developers sometimes use Task.Run
to offload work to background threads. This is not supported in T#.
π What you instead need to do in T#:
T# is single-threaded. Keep logic lightweight and frame-safe. You can Break tasks into smaller operations in Update()
or use coroutines for pacing.
β GetType()
or typeof()
In Unity, these are used for reflection, dynamic behavior, or type comparisons. These are not supported in T#.
π What you instead need to do in T#:
Instead of GetType()
or typeof(),
you need to use direct type references and avoid dynamic type inspection.
Last updated