Fixing Physics Jitter in Unity Mobile Games

Jitter is a mismatch between how often physics updates and how often the screen draws. Physics runs on a fixed clock, rendering runs on a variable one, and objects drawn at raw physics positions appear to stutter. Interpolation fixes most of it, and update order fixes most of the rest.

Why this matters

Jitter reads as low quality even when the frame rate is fine. Players describe it as the game feeling cheap without being able to say why.

It is also commonly misdiagnosed. Teams spend days on performance work when the frame rate was never the problem, because the symptom looks similar.

The causes are few and the fixes are settings rather than rewrites.

What jitter actually is

Unity runs physics at a fixed rate, independent of rendering. Rendering happens whenever a frame is ready.

Those two clocks do not line up. In some frames two physics steps have occurred, in others one, in others none. If an object is drawn at its exact physics position each frame, its apparent speed varies frame to frame even though its real motion is perfectly smooth.

That variation is jitter.

Jitter is almost never physics being wrong. It is rendering asking physics a question at an awkward moment.

Related but distinct is stutter, which is caused by frame time spikes and usually by memory allocation. If the hitch is periodic rather than constant, start with Object Pooling in Unity.

Fixed timestep and update order

Two settings and one habit.

Fixed timestep controls how often physics runs. The default is often more frequent than a mobile game needs, which costs performance without improving anything visible. Raising it to match your target frame rate is usually safe and frequently a win.

Maximum allowed timestep caps how much catch-up physics will attempt after a slow frame. Left high, a single hitch triggers a burst of physics steps, which causes a larger hitch, which triggers more. Lowering it prevents that spiral.

Update order is the habit. Physics values belong in the fixed update, and input and rendering concerns belong in the regular update. Moving a rigidbody from the regular update is one of the most common causes of jitter, because the move happens at an inconsistent point relative to the physics step.

The rule of thumb: if it is a force, a velocity, or a rigidbody position, it belongs in the fixed update.

Interpolation and extrapolation settings

This is the setting that fixes most jitter, and it is one dropdown.

Interpolate the player character and anything the camera follows. Do not interpolate everything, because it costs a little per object and most objects do not need it.

Extrapolation looks appealing and usually is not. Because it guesses, it produces visible corrections when an object stops suddenly, which is exactly when the player is looking.

Camera following a rigidbody

Even with interpolation set correctly, a camera can reintroduce jitter.

The problem is order. If the camera reads the target's position before interpolation has been applied for that frame, it follows the raw physics position and the target appears to shake relative to the world.

Two fixes.

1. Move the camera in the late update, after all other movement has been applied.
2. Smooth the camera independently, so it is never locked exactly to a physics value.

If you are using a camera package, check which update phase it runs in. Most expose the setting, and the correct answer for a physics-driven target is the late phase.

The general camera settings that matter are in Making a 2D Game Feel Good.

Collision and continuous detection cost

Continuous collision detection prevents fast objects passing through thin geometry. It is also considerably more expensive than the discrete mode.

Use it selectively: on fast-moving objects such as projectiles, and not on everything.

Two related costs worth checking on mobile.

• Mesh colliders on moving objects are expensive. Replace them with primitives wherever the shape allows, which is more often than people expect.
• The collision matrix tests every enabled layer pair. Turning off pairs that never interact is free performance and takes minutes.

Neither causes jitter directly. Both cause frame time spikes that look like jitter, which is why they belong in the debugging order below.

A jitter debugging order of operations

Work through these in sequence and stop when it is fixed.

1. Confirm it is jitter, not stutter. Constant unevenness is jitter. Periodic hitches are allocation.
2. Set interpolation to Interpolate on the object that looks wrong.
3. Check where the object is moved. Rigidbody movement must happen in the fixed update.
4. Move the camera to the late update, or smooth it independently.
5. Check the fixed timestep and raise it if it is unnecessarily frequent.
6. Lower the maximum allowed timestep so hitches cannot cascade.
7. Look for competing movement. Two scripts moving the same object, or an animator overriding a physics position.
8. Profile on a real device, because editor timing does not match device timing.

Steps two, three, and four resolve the large majority of cases.

What we would do

Set interpolation on the player and the camera target as a project default, and make the update-phase rule explicit for the team. Both are conventions rather than fixes, and conventions prevent the problem returning.

Raise the fixed timestep early, before tuning any physics values. Changing it later alters how forces feel, which means retuning gameplay you had already settled.

Then test on a mid-tier device with the frame rate capped where you intend to ship. Jitter is much more visible at a capped frame rate, and a game that looks smooth uncapped in the editor can look poor on the target hardware.

The short version

• Jitter is a timing mismatch between fixed physics and variable rendering.
• Interpolation on watched objects fixes the majority of cases.
• Move rigidbodies in the fixed update, never the regular update.
• Move the camera in the late update or smooth it independently.
• Raise the fixed timestep early and cap the maximum allowed timestep.
• Constant unevenness is jitter; periodic hitches are allocation.

Set interpolation on your player and camera target, then check where your movement code runs. If the game still looks wrong on device, send us a build.

Related reading: Unity Mobile Performance, Object Pooling in Unity, and Input Handling for Mobile.