Choosing Between Update, FixedUpdate, and LateUpdate in Unity

The Frame Timing Problem

Placing logic in the wrong Unity update loop causes unpredictable behavior: physics objects that tunnel through walls, cameras that jitter during movement, and input that feels unresponsive. The core issue is that Unity manages three distinct timing cycles—variable frame rates, deterministic physics steps, and post-update cleanup—and using them interchangeably leads to unstable game state.

Comparing the Update Loops

The following table outlines the primary constraints and intended use cases for each loop.

Method	Execution Timing	Timing Consistency	Primary Use Case
Update()	Once per rendered frame	Variable (Frame-rate dependent)	Input, timers, non-physics movement
FixedUpdate()	Fixed interval (Default 0.02s)	Deterministic (Constant)	Rigidbody forces, physics calculations
LateUpdate()	After all Update() calls	Variable (Frame-rate dependent)	Camera following, UI tracking

Trade-offs and Engineering Risks

The Physics Instability Risk

Unity's physics engine (PhysX) operates on a fixed timestep. If you apply a force in Update(), the force is applied every frame. On a high-end PC running at 144 FPS, the force is applied more often than on a console running at 30 FPS, leading to inconsistent gameplay across hardware. Conversely, placing physics logic in FixedUpdate() ensures the simulation remains stable regardless of the visual frame rate.

The Camera Jitter Effect

When a camera follows a player in Update(), a race condition occurs. If the camera updates its position before the player's movement script runs in that same frame, the camera will be one frame behind. This results in a visual "stutter" or jitter. Moving the camera logic to LateUpdate() guarantees the player has already finished moving for that frame before the camera calculates its new position.

Input Responsiveness

While physics belongs in FixedUpdate(), input detection (e.g., Input.GetKeyDown) should stay in Update(). Because FixedUpdate() can run multiple times per frame or not at all (depending on the frame rate), placing input checks there can lead to "dropped" inputs where a key press is missed entirely.

Implementation Example: Character Controller

This example demonstrates the correct distribution of logic for a standard physics-based character. This assumes Unity 2021.x or newer.

using UnityEngine;

public class PlayerController : MonoBehaviour
{
    public Rigidbody rb;
    public float speed = 10f;
    private float movementInput;

    // 1. Capture input every frame for maximum responsiveness
    void Update()
    {
        movementInput = Input.GetAxis("Horizontal");
    }

    // 2. Apply physics forces on a deterministic clock
    void FixedUpdate()
    {
        Vector3 force = new Vector3(movementInput * speed, 0, 0);
        rb.AddForce(force, ForceMode.Acceleration);
        
        // Note: Use Time.fixedDeltaTime if manual calculations are needed here
    }
}

public class CameraFollow : MonoBehaviour
{
    public Transform target;
    public Vector3 offset;

    // 3. Ensure the target has moved before updating camera position
    void LateUpdate()
    {
        transform.position = target.position + offset;
    }
}

Validation and Diagnostics

To verify your logic is in the correct loop, use the following diagnostic checks:

• Physics Stability Check: Apply a constant force in Update() and artificially lower your frame rate (using Application.targetFrameRate). If the object's acceleration changes, the logic must be moved to FixedUpdate().
• Jitter Test: Move a target object in Update() and follow it with a camera in Update(). If the movement looks shaky, move the camera logic to LateUpdate().
• Execution Order Log: Create a script that logs "Update", "FixedUpdate", and "LateUpdate" to the console. You will observe that FixedUpdate may trigger multiple times (or zero times) between Update and LateUpdate calls.

Limitations

FixedUpdate() is not a magic bullet for all timing issues. If your game requires extremely high-precision networking (like fighting games), you may need a custom deterministic lockstep system rather than relying on Unity's built-in physics loop. Additionally, heavy computations in Update() will directly lower the FPS, which can indirectly affect the perceived smoothness of FixedUpdate() physics interpolation.