Unity Update vs FixedUpdate (When to Use What)

TL;DR Cheat Sheet for unity update vs fixedupdate

• Update: runs every frame. Use for input, UI animation, camera logic (often in LateUpdate), timers, and non-physics transforms.
• FixedUpdate: runs on a fixed interval (Time.fixedDeltaTime; default 0.02 s). Use for physics—Rigidbody.AddForce, setting velocity, MovePosition/MoveRotation.
• LateUpdate: runs after Update every frame. Great for camera follow/aim that depends on objects already moved.
• Golden rule for unity update vs fixedupdate: Read input in Update → store intent → apply to rigidbodies in FixedUpdate.

What Are Update & FixedUpdate?

Unity’s main loop separates visual frames from physics simulation. Update is called once per rendered frame; its interval is variable and depends on framerate. FixedUpdate is called at consistent intervals determined by Time.fixedDeltaTime. If the game stutters, Unity may call FixedUpdate multiple times in a single frame to keep the physics world in sync.

Because physics requires determinism across timesteps, FixedUpdate is where you should interact with rigidbodies. Meanwhile, responsiveness to player input and UI should happen in Update so that it’s in step with the current frame. That’s the essence of unity update vs fixedupdate in practical terms.

When to Use Update (with code)

Use Update for things that should happen once per frame, tied to the camera and input:

• Reading the legacy Input Manager (Input.GetAxis, Input.GetButtonDown) or the newer Input System actions.
• UI interactions, cooldown timers, non-physics animations/tweens.
• CharacterController (non-rigidbody) movement.

// Read input each frame, move a CharacterController (not a Rigidbody)
public class PlayerController : MonoBehaviour
{
    public CharacterController controller;
    public float speed = 6f;

    void Update()
    {
        float h = Input.GetAxisRaw("Horizontal");
        float v = Input.GetAxisRaw("Vertical");
        Vector3 dir = new Vector3(h, 0, v).normalized;

        if (dir.sqrMagnitude > 0.001f)
        {
            controller.Move(dir * speed * Time.deltaTime);
        }
    }
}

Note how Time.deltaTime is used to keep movement frame-rate independent. For unity update vs fixedupdate, this is the Update side: reading input and moving non-physics objects.

When to Use FixedUpdate (with code)

FixedUpdate is the “physics lane”. Apply forces, set velocities, or use Rigidbody.MovePosition/MoveRotation here. Read Time.fixedDeltaTime if you need the timestep value.

// Read input in Update, apply to Rigidbody in FixedUpdate (best practice)
public class PhysicsMover : MonoBehaviour
{
    public Rigidbody rb;
    public float acceleration = 12f;
    public float maxSpeed = 8f;

    private Vector2 inputVector; // cached intent from Update

    void Update()
    {
        // Input is frame-based; capture here.
        inputVector.x = Input.GetAxisRaw("Horizontal");
        inputVector.y = Input.GetAxisRaw("Vertical");
    }

    void FixedUpdate()
    {
        // Convert intent to world-space force each physics tick.
        Vector3 force = new Vector3(inputVector.x, 0f, inputVector.y).normalized * acceleration;
        rb.AddForce(force, ForceMode.Acceleration);

        // Clamp velocity for tighter control.
        Vector3 v = rb.velocity;
        v = Vector3.ClampMagnitude(v, maxSpeed);
        rb.velocity = v;
    }
}

If you prefer kinematic movement with physics contacts, use Rigidbody.MovePosition in FixedUpdate:

void FixedUpdate()
{
    Vector3 desired = transform.position + moveDir * speed * Time.fixedDeltaTime;
    rb.MovePosition(desired);
}

These patterns keep physics stable and are the core of unity update vs fixedupdate in real projects.

Physics Timing: Fixed Timestep, Catch-up & Jitter

• Fixed Timestep: Project Settings → Time → Fixed Timestep. Default is 0.02 seconds (50 Hz). Physics ticks use this value.
• Catch-up: If frames take too long, Unity may run multiple FixedUpdates before the next Update to “catch up” the simulation.
• Maximum Allowed Timestep: caps how much catch-up happens in a single frame to avoid spirals.
• Interpolation: For smooth visuals of rigidbodies moved in FixedUpdate, enable Interpolate in the Rigidbody inspector so the renderer blends between physics states.

Symptoms of mixing lanes in unity update vs fixedupdate: jittery rigidbody motion (you moved it in Update), input lag (you read input in FixedUpdate), or tunneling (you teleported a dynamic rigidbody each frame). All of these stem from misunderstanding how unity update vs fixedupdate behave under stress.

Input Pattern: Update → FixedUpdate Bridge

Modern controllers poll once per frame. So capture the player’s intent in Update, store it, and consume that cached value inside FixedUpdate. This ensures responsive input while keeping physics deterministic. With the new Input System, subscribe to actions (frame events) and still apply physics changes in FixedUpdate—the standard bridge for unity update vs fixedupdate.

// Minimal "bridge" pattern
Vector2 _moveIntent;

void Update() {
    _moveIntent = _inputActions.Player.Move.ReadValue<Vector2>();
}

void FixedUpdate() {
    ApplyMovement(_moveIntent); // physics side
}

Movement Recipes (CharacterController, Rigidbody 3D/2D)

CharacterController (no physics)

Use Update with CharacterController.Move. Gravity can be applied manually. This keeps you entirely in the frame loop—no rigidbody needed. In unity update vs fixedupdate terms: CharacterController lives in Update.

Rigidbody (3D)

• Arcade movement: set rb.velocity or MovePosition in FixedUpdate.
• Authentic physics: use AddForce/AddTorque in FixedUpdate.
• Smooth camera: follow in LateUpdate (after both Update and any transforms moved).

Rigidbody2D (2D)

Exactly the same idea as 3D: do physics work in FixedUpdate and enable interpolation for smoother rendering—another staple of unity update vs fixedupdate best practice.

Kinematic Rigidbody

If a rigidbody is kinematic, use MovePosition/MoveRotation in FixedUpdate to interact correctly with dynamic bodies (triggers, contacts, etc.). This keeps you aligned with unity update vs fixedupdate responsibilities.

LateUpdate, OnGUI & Other Callbacks

• LateUpdate: runs after Update. Use for camera and look-at logic to avoid one-frame lag behind player objects moved in Update—great synergy with the unity update vs fixedupdate split.
• OnGUI: part of the IMGUI system; called multiple times per frame. Avoid heavy work here for runtime games.
• Coroutines: WaitForFixedUpdate aligns a coroutine to the next physics tick if you need sequencing without writing FixedUpdate code.

Decision Tree & Comparison Table for unity update vs fixedupdate

Quick Decision Tree

1. Does it touch a Rigidbody? → Yes → FixedUpdate. No → Step 2.
2. Is it player input/UI/timers? → Yes → Update. No → Step 3.
3. Is it camera follow/aim? → Yes → LateUpdate. No → usually Update.

Unity Update vs FixedUpdate — Comparison

Common Mistakes to Avoid

• Driving dynamic rigidbodies from Update. It may appear fine at 144 Hz, then break on 30 Hz devices.
• Reading input in FixedUpdate. Physics may tick multiple times per frame, so you’ll reuse old input.
• Teleporting a rigidbody each frame. Use MovePosition or velocities to respect contacts.
• Forgetting interpolation. Even correct FixedUpdate motion can render choppy without interpolation.
• Changing Fixed Timestep casually. Larger steps are cheaper but less stable; tiny steps are costly.

When you hit any of these problems, revisit your lane choice—correcting the split in unity update vs fixedupdate usually fixes the symptom immediately.

Performance Tips (GC, allocations, jobs)

• Avoid per-tick allocations. Cache component references; reuse lists/buffers.
• Cap physics iterations (Project Settings → Physics) if you don’t need super precise contacts.
• Consider Rigidbody interpolation instead of extreme timesteps to smooth rendering.
• Use Jobs/Burst for heavy math in Update, then feed results to FixedUpdate safely—another healthy pattern for unity update vs fixedupdate.

FAQ

Should I ever move a non-rigidbody in FixedUpdate?

You can, but you gain nothing and risk visual jitter. If there’s no rigidbody involved, Update is simpler and perfectly fine—one more way to keep unity update vs fixedupdate responsibilities clean.

How many times can FixedUpdate run per frame?

As many as needed to catch up with time, bounded by Maximum Allowed Timestep. That’s why rigidbody work belongs here and not in Update, a core principle in unity update vs fixedupdate.

Where should I rotate the camera?

Usually in LateUpdate, after player and world objects move. This prevents one-frame lag or wobble and complements the unity update vs fixedupdate split.

Is CharacterController physics?

No. It’s a kinematic collider that you drive yourself, typically from Update using Move. This keeps you on the Update side of unity update vs fixedupdate.

Does the new Input System change the rule?

No. You still read actions on the frame (Update) and apply physics in FixedUpdate. The bridge pattern is the recommended approach for unity update vs fixedupdate with both input systems.

Official Docs & Further Reading

• Unity Manual — MonoBehaviour.Update
• Unity Manual — MonoBehaviour.FixedUpdate
• Unity Scripting — Time.fixedDeltaTime
• Learn Unity — Update & FixedUpdate tutorial
• Stack Overflow — community discussion on differences

Conclusion

Think of Unity’s loops as two lanes: the frame lane for input and visuals (Update) and the physics lane for deterministic motion (FixedUpdate). When you follow this split, movement is smooth on fast PCs and slow phones alike. If you’re ever unsure about unity update vs fixedupdate, ask: “Does this touch a rigidbody?” If yes, choose FixedUpdate; if not, Update or LateUpdate is your friend—and your game will feel better immediately.