Difference Between Update, FixedUpdate, and LateUpdate in Unity

When developing games in Unity, controlling how and when your game logic executes is critical for performance and correctness. Unity provides three commonly used MonoBehaviour event functions—Update(), FixedUpdate(), and LateUpdate()—each with a specific purpose and timing in the game loop.

Let’s break down what each of these methods does, how they differ, and when to use them.

🔁 1. Update(): The Standard Frame-by-Frame Logic

• Called: Once per frame
• Use case: For general game logic like user input, movement, animations, timers, and UI updates.

Key Points

• Update() runs once every rendered frame. If your game runs at 60 FPS, it is called 60 times per second.
• It is frame rate-dependent, meaning if the frame rate drops, Update() will be called less frequently.
• Suitable for things that depend on user input (like Input.GetKeyDown()), which are also frame-dependent.

Example

void Update()
{
    if (Input.GetKeyDown(KeyCode.Space))
    {
        Debug.Log("Jump!");
    }
}

⚙️ 2. FixedUpdate(): Physics-Based Logic

• Called: On a fixed time interval (default: 0.02s, i.e., 50 times/sec)
• Use case: For physics calculations and Rigidbody movement.

Key Points

• Runs independently of the frame rate.
• Consistent timing makes it ideal for physics-based logic.
• Use this for applying forces, torque, or Rigidbody velocity changes (Rigidbody.MovePosition() or AddForce()).

Example

void FixedUpdate()
{
    rb.AddForce(Vector3.forward * thrust);
}

🧠 Tip: Avoid using Input.GetKeyDown() in FixedUpdate() because input is frame-based and may get missed.

⏮️ 3. LateUpdate(): Executes After All Updates

• Called: Once per frame, after all Update() methods
• Use case: For the following cameras, character animation clean-up, and final adjustments.

Key Points

• Useful when one object depends on another object's Update() logic.
• Common in camera systems where the camera should follow a character after it has moved.
• Ensures the logic here sees all the final states of the frame before rendering.

Example

void LateUpdate()
{
    camera.transform.position = player.transform.position + offset;
}

🧩 Comparison Table

Feature	Update()	FixedUpdate()	LateUpdate()
Called Every...	Frame	Fixed Time Interval	Frame (after Update())
Frame Rate Dependent	✅ Yes	❌ No	✅ Yes
Best for...	Input, animations	Physics (Rigidbody, forces)	Camera follow, clean-ups
Input Handling	✅ Yes	❌ No	✅ Yes

🧪 Example Scenario

Let’s say you have a car game:

• You read player input (like acceleration or brake) in Update().
• You apply physics-based movement (like acceleration force) in FixedUpdate().
• You adjust the camera position to follow the car smoothly in LateUpdate().

This keeps your game modular, readable, and performant.

🧠 Final Tips

• Don’t mix physics and input in the same method—split logic appropriately.
• Be cautious of Time.deltaTime in FixedUpdate(). Use Time.fixedDeltaTime instead.
• Test with different frame rates to see how logic behaves across Update() vs FixedUpdate().

🎮 Conclusion

Understanding the difference between Update(), FixedUpdate(), and LateUpdate() is key to writing clean, efficient, and bug-free game logic in Unity. Each plays a specific role in Unity’s execution cycle and should be used accordingly to ensure the best gameplay experience.

Use

• Update() for frame-dependent logic,
• FixedUpdate() for physics,
• LateUpdate() for logic that must happen last.

With these principles in mind, you’ll have tighter control over game behavior and fewer unexpected bugs in your gameplay mechanics.