Working with Update & FixedUpdate

Unity runs on two clocks: Update runs once per rendered frame (a variable rate), and FixedUpdate runs at a fixed rate for physics. Most jitter, missed inputs and "physics feels different on my friend's PC" bugs come from mixing them up. This guide explains how they relate and what belongs where.

How the two loops line up

With the default fixed timestep of 0.02 s (50 steps per second):

So FixedUpdate may run several times in one frame, or not at all.

What goes where

Pattern: read in Update, apply in FixedUpdate

using UnityEngine;

public class RollingBall : MonoBehaviour
{
    [SerializeField] private float moveForce = 20f;
    [SerializeField] private float jumpImpulse = 6f;

    private Rigidbody rb;
    private Vector3 moveInput;   // continuous input: just overwrite each frame
    private bool jumpQueued;     // one-off input: set in Update, consume in FixedUpdate

    void Awake() { rb = GetComponent<Rigidbody>(); }

    void Update()
    {
        moveInput = new Vector3(Input.GetAxisRaw("Horizontal"), 0f, Input.GetAxisRaw("Vertical")).normalized;
        if (Input.GetButtonDown("Jump")) jumpQueued = true; // never set back to false here
    }

    void FixedUpdate()
    {
        rb.AddForce(moveInput * moveForce, ForceMode.Force); // continuous: every step

        if (jumpQueued)
        {
            rb.AddForce(Vector3.up * jumpImpulse, ForceMode.Impulse); // once
            jumpQueued = false; // consumed
        }
    }
}

Why a flag instead of calling AddForce directly in Update? At 144 FPS, most frames have no physics step, so the force would sit waiting anyway. At 20 FPS, several physics steps happen per frame, and a force added in Update only affects the first of them. Buffering makes behavior identical at any frame rate.

deltaTime in each method

So a function using Time.deltaTime works correctly in either. Remember that forces and velocities are already "per second": don't multiply AddForce or linearVelocity by deltaTime.

Fixing jitter: interpolation

At 144 FPS with 50 physics steps, a Rigidbody only moves on ~1 in 3 frames. The camera moves every frame. The result: the object looks like it stutters.

• Set the Rigidbody's Interpolate to Interpolate. Unity then smooths the Transform between the last two physics positions every frame. (Costs a little; use it on the player and anything the camera follows.)
• Move the camera in LateUpdate, following the Transform (which is interpolated), not rb.position (which isn't).
• Never move the same object from both loops (e.g. Rigidbody in FixedUpdate and transform.position in Update).

Changing the fixed timestep

Project Settings > Time > Fixed Timestep (or Time.fixedDeltaTime in code).

For slow motion, scale both: Time.timeScale = 0.25f; Time.fixedDeltaTime = 0.02f * Time.timeScale;. Reset both afterwards.

Advanced: many objects, one Update

Every MonoBehaviour Update is a call from Unity's engine (C++) into your C# code. With thousands of objects, that overhead adds up. A common industry pattern is a single update manager that loops over plain C# objects:

using System.Collections.Generic;
using UnityEngine;

public interface ITickable { void Tick(float dt); }

public class TickManager : MonoBehaviour
{
    private static readonly List<ITickable> tickables = new List<ITickable>();

    public static void Register(ITickable t)   => tickables.Add(t);
    public static void Unregister(ITickable t) => tickables.Remove(t);

    void Update()
    {
        float dt = Time.deltaTime;
        for (int i = tickables.Count - 1; i >= 0; i--) // backwards: safe if one unregisters
            tickables[i].Tick(dt);
    }
}

public class Drone : MonoBehaviour, ITickable
{
    void OnEnable()  { TickManager.Register(this); }
    void OnDisable() { TickManager.Unregister(this); }

    public void Tick(float dt) { transform.Rotate(0f, 90f * dt, 0f); }
}

Only worth it for large numbers (hundreds to thousands) of per-frame objects. Measure with the Profiler before and after.

Staggering expensive work

// Each enemy thinks every 5th frame, spread out so they don't all think on the same frame.
private int slot;
void Awake() { slot = Random.Range(0, 5); }

void Update()
{
    Move();                                   // cheap: every frame
    if (Time.frameCount % 5 == slot) Think(); // expensive: 1 in 5 frames
}

Common Mistakes

• Input in FixedUpdate → missed presses at high frame rates.
• Continuous forces in Update → movement speed changes with frame rate.
• Moving a Rigidbody with Transform → teleporting, tunneling, jitter.
• Camera in Update or FixedUpdate following a physics object → jitter. Use LateUpdate + Interpolate.
• Counting on FixedUpdate every frame for timers → wrong at high FPS. Use Update for timers.
• Setting fixedDeltaTime very small "for accuracy" → physics eats the CPU, especially on mobile.

See also

• Script Lifecycle
• Time
• Rigidbody
• Interpolation & Easing

This page is a simplified, AI-assisted interpretation. For the complete and authoritative reference, see the official Unity documentation.