Mobile Game Performance Optimization 2026
Build your Unity game to a real phone, play one scene with your eyes and hands, and write down what you notice before you open a single quality setting.
This is a different slice from our earlier Unity mobile optimization post: that one walks through measuring with the Profiler and then fixing rendering, CPU, and memory costs, while this one stops before any fix and covers only what you watch for and write down on the phone itself.
You will not change a quality level, a texture setting, or a render pipeline asset in this article. You will make one build, play one scene, and fill one page of notes. The notes decide what you change later.
Unity moves options between versions. If a menu or window named here is not where you expect, search the Unity manual for the version you have installed and follow that.
Why look before you change
It is tempting to open the quality settings the moment a phone build feels off. Lower shadows, lower texture size, turn off antialiasing. Sometimes that helps. Often you end up with a game that looks worse and still has the problem you felt, because the problem was never the thing you lowered.
A phone gives you information the editor does not. It gets warm in your hand. It has a small screen and a thumb in front of it. It may pause when something loads that loaded instantly on your desktop. You can only notice those things by holding the phone and playing.
Make one build and pick one scene
Make a build to a phone you own. Turn on the development build option in your build settings or build profile, since you will want it for the profiler later, and so you know you are running the same kind of build each time.
Pick one scene. Choose the one that feels heaviest to you: the busiest level, the room with the most effects, or the menu that leads into gameplay. Do not tour the whole game. One scene, watched carefully, tells you more than five scenes skimmed.
Plan a short route through it. Walk from the start to one landmark, trigger one event, open one menu, and come back. Write the route down so you can repeat it exactly.
Set up the session
Before you play:
- Charge the phone, then unplug it if you can. Some phones behave differently on a charger.
- Close other apps.
- Note the room you are in. A warm room and a cold room will feel different in your hand.
- Get a paper notebook or a notes file on another device. Do not take notes on the test phone.
Write the date, the phone model, and the build you installed at the top of the page.
What to watch for
Play your route several times in a row without stopping. Then go through this list and write a line for each item, even if the line is “nothing noticed.”
Heat
Hold the phone the way a player would. After a few runs, notice where it feels warm and whether it keeps getting warmer. Write down roughly when you first noticed it, in terms of your route: “warm by the third time through the courtyard.”
Heat matters because many phones slow themselves down as they warm up. A scene that feels fine in the first minute can feel worse in the fifth. If the game feels different on run five than on run one, write that down too.
Stalls tied to a specific moment
A stall is a pause or hitch you can point to. The key is the moment, not the stall itself. Write down exactly what was happening:
- “Freezes for a beat when the door opens and the next room appears.”
- “Hitches the first time an enemy spawns, not after.”
- “Pauses when the pause menu opens.”
A stall that happens only the first time often points to something loading. A stall that happens every time points to something that runs every time. You do not need to know which yet. You need the exact moment, because that is what you will search for in the profiler.
General smoothness
Separate from stalls, does motion feel even? Pan the camera slowly and watch the edges of objects. Walk past a busy area and see if the movement stays steady. Write what you see in plain words: “camera feels uneven near the fountain” is a useful note. Do not try to guess a frame rate by eye.
Touch and UI
Play with your thumbs, not a stylus or a fingertip held carefully. Note:
- Any button you missed on the first try.
- Any text you had to squint at or bring the phone closer to read.
- Anything your thumb covers while you are using it, like a health bar under a joystick.
- Any control near the screen edge or a notch that is hard to reach.
These are not performance problems, but they are things only a phone shows you, and they belong on the same page.
Load and return
Lock the phone mid-scene and unlock it. Switch to another app and back. Write down whether the game resumes cleanly, restarts, or shows something wrong for a moment.
Battery
Glance at the battery before and after your session. You are not measuring anything precise. You are noticing whether it dropped more than you expected for the time you played.
Read your notes
When you are done, read the page. Circle the items that would bother a player most. Usually that is one or two things: a stall at a specific moment, a phone that gets uncomfortably warm, or a button nobody can hit.
For each circled item, write one sentence that starts with “When.” For example: “When the second room loads, the game freezes briefly.” That sentence is now a question you can take to the profiler.
Then open the profiler
Only now, connect Unity’s Profiler window to the development build on the phone. The Unity manual has a page on collecting performance data from a target platform. Follow the steps for your Unity version, since the connection options have moved over time.
Play the same route. When you reach the moment from your “When” sentence, look at what the profiler shows at that point. You are not reading every graph. You are looking at the one moment you already know matters.
If you are not sure which profiler view to open for your question, start with the CPU view your version offers and look up the rest in the manual.
Then, and only then, change something
Pick the single circled item that matters most. Change one thing that you think addresses it. Build again, play the same route on the same phone, and fill out a fresh page.
Compare the two pages. If the note you were targeting changed, keep the change. If it did not, undo it and try something else. If some other note got worse, you have learned something about a trade-off.
Touch and UI notes often get fixed in the UI itself, not in a quality setting. Heat notes may lead to cutting an effect rather than lowering a slider. Your notes tell you which kind of fix you need.
Keep the pages
Put every page in one folder or notebook, newest on top. Each one is a short record of how the game felt on a real phone on a specific day. When someone asks whether the game runs better than last month, you have an answer in your own words, not a guess.
Next time you add a big feature, make a build, play the same route, and fill out a new page before you touch anything else.