How to Optimize Unity Games for Mobile 2026

A mobile game has to draw, simulate, and respond on a phone that is also doing a dozen other jobs. Optimization is the work of finding what your game actually spends, then removing the expensive parts you do not need. This is a solo-friendly process for a Unity project you already have running. It will not turn a heavy scene into a flagship title in an afternoon, and it will not quote frame rates you should expect. Phones differ too much for that.

Unity moves settings between versions. If a checkbox name here does not match your editor, search the current Unity manual. Do not copy a license price or a “recommended” quality table from an old post.

Measure before you change anything

Guessing is how projects lose a week on the wrong problem. Make a development build, install it on a phone you own, and play the heaviest scene you have. The editor is not the phone. A smooth Game view can still hitch on device.

Use Unity’s Profiler, attached to the player, and look at a captured stretch of real play, not an idle menu. Separate CPU time, rendering, and garbage collection spikes. Then open the Frame Debugger on a representative frame and see how many draw calls and what shaders are in flight. Memory Profiler, when it is available in your version, shows which textures and meshes dominate.

Write down three observations in plain language: what spikes, when it spikes, and what is on screen at that moment. Fix the largest real cost first. Do not start by lowering every quality slider, or you will not know which change mattered.

Pick a render pipeline and stay there

For most solo mobile games, the Universal Render Pipeline is the practical starting point. It is aimed at scaling across devices, including phones. The High Definition Render Pipeline is built for higher-end visuals and is usually the wrong default for a broad mobile audience. If you are already on the Built-in pipeline, do not convert in the middle of a content crunch unless you have time to retest every material.

Read the current URP manual for the mobile notes that match your Unity version. In particular, learn how the SRP Batcher works in that version, and which shaders are compatible with it. A shader that opts out of batching can undo a lot of careful scene work. Use as few shader variants as you can get away with. Every extra light mode, fog mode, and keyword is work for the build and sometimes for the GPU.

Keep real-time lights rare. One directional light plus baked or cheap lighting for the rest is easier to run than a street full of dynamic point lights and shadows. Shadows are often a larger cost than the mesh they fall on. If a shadow does not help the player read the scene, turn it off for that light.

Make the scene cheaper to draw

Rendering problems are usually too much unique work, not one magic setting.

Use texture compression formats that mobile GPUs actually like. ASTC is the common choice on modern devices, with an ETC2 fallback when you still care about older ones. Confirm the override list in your version’s texture importer docs. Shrink textures that are never seen up close. A background prop does not need the same resolution as a character’s face. Turn on mipmaps for textures that appear at varying distances so the GPU does not sample a huge image for a tiny object.

Reuse materials. Ten objects with one shared material are cheaper to reason about, and often cheaper to draw, than ten copies with tiny color changes that broke the batch. Static batching can help non-moving geometry. Check the current manual before you enable it on a huge scene, because batching trades memory for fewer draw submissions.

Mark objects that never move as static when that matches the truth. Use occlusion so the phone does not draw rooms behind closed doors. A simple corridor with closed doors is an easy win. A dense forest of unique meshes is not, and you may need fewer unique trees rather than a cleverer culling setup.

Add levels of detail only for objects that change size on screen a lot. Test any LOD swap on device so it does not pop.

Keep UI on separate canvases so one changing number does not rebuild a screen full of static art. Avoid large transparent overlays stacked on top of the world. Overdraw, drawing the same pixel many times, is a classic mobile cost and it is easy to create with particles and full-screen effects.

Make the CPU and memory boring

A smooth renderer can still hitch if your scripts allocate every frame. In Update and similar per-frame methods, avoid creating new lists, strings, or temporary objects just to throw them away. Cache references. Use object pools for bullets, floating numbers, and other things you spawn constantly. Instantiating and destroying in a firefight is a common spike you can see in the Profiler as garbage collection.

Physics is a budget. Put gameplay objects on layers and make the collision matrix ignore pairs that never need to touch. Do not use continuous collision detection on everything. It is for the fast objects that tunnel at discrete steps, not for crates. A lower physics rate can be fine for a slow puzzle game and wrong for a precise platformer. Change it on purpose and playtest, rather than copying a number from a forum.

Animations, AI, and navigation do not all need to think every frame. Update distant characters less often. A timer that runs ten times a second is enough for a lot of decision making. Pathfinding for a crowd is more expensive than pathfinding for one enemy. If you do not need a crowd, do not simulate one.

Match audio import settings to the clip’s role, using the current audio importer docs, and listen on the phone speaker.

Strip engine code you do not use when you build. Managed stripping and IL2CPP are documented under Player settings, and the safe level depends on your project. A stripping level that breaks reflection or a plugin is worse than a slightly larger build. Test the stripped build on device. Development builds are not a fair size or performance comparison.

Build a test loop you will actually repeat

Keep a short scene that represents your worst case: the busiest fight, the largest room, or the most particles. After each optimization pass, run the same route on the same phone and look at the Profiler again. Change one thing at a time when you are not sure. A pile of simultaneous tweaks feels productive and teaches nothing.

Set quality levels for a small range of devices if you must, but support only what you can test. Two tiers you have played are better than five tiers you imagined. Disable post-processing effects that you cannot see on a small screen. Bloom, heavy ambient occlusion, and full-screen blur are often the first things to question.

Watch thermal behavior by simply playing for a while. A phone that gets hot will slow down even if the first minute looked fine. You do not need a lab for that. You need a few minutes of honest play and a willingness to cut an effect.

Know when to stop

Optimization is finished for now when the game feels steady on the phones you care about, load times are acceptable to you, and you can explain the remaining costs. Chasing the last stutter in an unfinished game is a way to avoid making the rest of the game.

Do not ship a tutorial’s advice untested. Profile, change, and profile again. If a setting’s name or default has moved in your Unity version, the manual wins. A smaller, stable scene that you completed beats a technically ambitious one that only runs on your development machine.