How to Optimize a Unity Game for Mobile (Android & iOS): What to Fix First

Mobile optimization in Unity has a strange way of turning into a shopping list.

Reduce draw calls. Lower the textures. Bake the lights. Use object pooling. Remove post-processing. Use Addressables. Lower the shadows. Optimize the scripts.

None of those ideas are automatically wrong.

The problem is that a developer who only asked, “How do I stop my mobile game from crashing and make the FPS smooth?” can end up with twenty pieces of advice and no reliable way to decide which one matters first.

That is exactly what caught my attention in a recent r/Unity3D discussion.

The Reddit Question#

The developer had mostly built simple prototypes and was now preparing an actual Android/iOS game. The concerns were practical: memory usage, crashes, smooth FPS, and what a Low/High graphics button should actually change.

The embed above is served by Reddit. If a privacy extension blocks Reddit embeds, open the original discussion directly.

The replies mostly move in three directions:

• profile on a cheap or older real device and watch shaders, graphics configuration, and scripts;
• learn Unity's Profiler, create quality tiers, and pay attention to draw calls and overdraw;
• use Addressables to control how content is loaded and unloaded.

Those are useful directions. The problem appears when useful directions get mistaken for a universal checklist.

What the Thread Gets Right#

The strongest advice in the thread is simple: test on real target hardware and profile the result.

A modern desktop can hide a frightening amount of bad mobile behaviour. Even a strong flagship phone can hide problems that become obvious on the lower-end Android device your actual player owns.

The comments are also right to point toward shaders, high-resolution shadows and textures, post-processing, draw calls, overdraw, scripts, and memory management. Every one of those can matter.

What they cannot tell you from a Reddit thread is which one is currently stealing your frame time.

Where Good Advice Turns Into Bad Optimization#

The difference between possible bottleneck and your bottleneck is the entire game.

If the CPU is already limiting the frame, destroying your visual quality by simplifying every shader might barely change FPS. If the GPU is buried under overdraw and expensive lighting, spending two days rewriting an AI loop might also do very little.

That is why optimization should be diagnosis before treatment.

Do not optimize the thing you suspect. Measure the thing that is actually expensive.

Unity's profiling tools exist specifically to answer that question. The Profiler can connect to development builds on Android and iOS, and Unity's current profiling reference recommends profiling as the way to understand CPU, GPU, memory, and script performance.

Step 1: Define the Target#

Before touching the Profiler, decide what “good performance” means for this game.

Mobile is not one hardware class. A recent flagship and a budget Android phone can differ enormously in CPU performance, GPU throughput, memory, thermal behaviour, and screen resolution.

Pick the lowest class of device you genuinely intend to support, then define a frame target.

At 60 FPS, a frame has roughly 16.67 ms. At 30 FPS, you have roughly 33.33 ms.

Now “the game feels slow” can become “this gameplay scene is taking 24 ms when the target is 16.67 ms.” That is something you can investigate.

Step 2: Profile on the Real Device#

Make a Development Build, install it on the target phone, connect the Unity Profiler, and reproduce the part of the game that performs badly.

Do not optimize from one screenshot of the Editor Stats panel. Capture behaviour while the actual game is running on the hardware you care about.

Start with the normal Profiler and inspect the relevant modules. Look at CPU Usage, Rendering, Memory, Physics, Animation, and GPU timing where available.

If the spike is in scripts, investigate scripts. If the spike is rendering, investigate rendering. If the game is being killed because memory keeps climbing, switch the investigation to memory.

Deep Profile Is a Scalpel, Not the Opening Hammer#

One commenter recommends Deep Profile because it can expose detailed script calls and garbage-collection problems.

That capability is real, but I would not make Deep Profile the default first step.

Unity's documentation warns that Deep Profiling instruments C# method calls and can significantly slow the Player. That overhead can distort the thing you are trying to measure, especially in a larger project.

Start with normal profiling. Narrow the problem down. Use allocation call stacks or targeted profiler markers where appropriate. Then reach for Deep Profile when you actually need the extra call-level detail.

The Profiler is the flashlight. Deep Profile is the floodlight you switch on when you already know which room you are searching.

Step 3: Find Out Whether the CPU, GPU, or Memory Is Losing#

This decision changes almost everything you do next.

If the CPU is the problem#

Investigate gameplay scripts, physics, animation, AI, excessive per-frame searches, garbage collection, object creation and destruction, third-party systems, and CPU-side rendering submission.

If the GPU is the problem#

Investigate shader cost, transparency, overdraw, render scale, shadows, lighting, particles, post-processing, and how many pixels the device has to shade.

If memory is the problem#

Use the Memory Profiler and look for large textures, duplicated content, audio, oversized meshes, retained assets, loaded scenes or bundles that should have been released, and allocations that grow over time.

What to Do About Shaders, Draw Calls, and Overdraw#

The thread's shader warning is useful. A single expensive material covering a large amount of the screen can hurt a mobile GPU badly. Transparent layers can also force the device to shade the same pixels repeatedly.

But the correct response is not “replace every shader.”

Use the Profiler and Frame Debugger to understand what is being drawn. Check material and shader passes, transparent layers, batch breaks, lighting, and the actual cost of the scene.

Draw calls are similar. Lower can be better when CPU submission is a problem, but there is no magic number that makes a project optimized. A game meeting its frame budget with 300 draw calls is healthier than one with 100 draw calls and an expensive full-screen effect eating the GPU.

For URP projects, Unity's current performance guidance specifically points to settings such as render scale, shadow distance, soft shadows, additional-light shadows, post-processing settings, and renderer features as knobs to review after analysis shows they matter.

Memory Is Not the Same Problem as FPS#

A mobile game can hold 60 FPS beautifully and still crash because it runs out of memory.

That is why memory deserves its own pass.

Unity's Memory Profiler is designed to inspect memory allocations on projects ranging from mobile to large desktop titles. Use snapshots to understand what is resident and compare states before and after loading or unloading content.

Also remember that download size is not runtime memory. A small store download can still expand into a large runtime memory footprint, while a larger package can sometimes manage resident memory sensibly.

Addressables Are Useful, but Not a Magic Memory Button#

One Reddit reply recommends learning Addressables early, including remote content.

Addressables can absolutely help when a project needs controlled loading, unloading, dependency management, downloadable content, or a cleaner content-delivery pipeline.

But moving everything into remote Addressables before you know why memory is high can simply add another system to debug.

Use Addressables when the architecture benefits from Addressables. Do not use them as a ritual performed whenever somebody says “mobile memory.”

How Low, Medium, and High Settings Should Actually Work#

A Low/Medium/High menu is a good idea, but the presets should change things that are expensive in your game.

This is an example, not a prescription. If texture memory is the actual problem, texture/mipmap limits may belong in the preset. If textures are fine, lowering them just makes the game uglier for no useful reason.

A preset is successful when it changes measured behaviour. “Low disables shadows” is not the goal. “Low moves this target device from unstable 38–47 FPS to a stable target” is.

Do Not Forget Thermals#

Mobile performance also changes over time.

A phone may run beautifully for the first minute and then reduce performance as heat builds. That means a sixty-second test can lie to you.

Run longer sessions. Watch sustained performance, battery behaviour, and thermal throttling. Unity's Adaptive Performance package can expose thermal and power-state information when a project needs runtime adaptation.

A Free Mobile Optimization Workflow#

You can do a serious mobile optimization pass without buying anything.

1. Choose representative target devices.
2. Define FPS, memory, loading, and stability targets.
3. Create a Development Build.
4. Profile the actual device.
5. Decide whether CPU, GPU, or memory is the primary problem.
6. Use the Frame Debugger when rendering is suspicious.
7. Use Memory Profiler snapshots when memory is suspicious.
8. Change one meaningful thing.
9. Measure again.
10. Keep the change only if the data and the game both improved.

The last part matters. If you change ten systems at once and performance improves, you have no idea what actually helped. Worse, one change may have introduced a regression that the other nine changes temporarily hide.

Measure before. Change. Measure after.

Two Tools That Can Structure the Work#

Unity's built-in Profiler, Memory Profiler, Frame Debugger, and quality settings should remain the foundation. Third-party tools become useful when you want to make parts of the investigation faster, more visual, or more structured.

Two current Asset Store options take noticeably different approaches.

1. Nebula PRO: Scene Heatmaps and LOD-Focused Analysis#

Nebula PRO: One-Click LOD Optimizer & Scene Performance Heatmap is primarily a scene-analysis tool.

Its published feature set focuses on scene geometry and renderer complexity, a color-coded heatmap, platform-aware scene analysis, LOD transition optimization, draw-call and estimated-memory indicators, and platform presets for targets including mobile and VR.

The developer also clearly states what it does not do: it is not a runtime performance profiler, does not continuously analyze the game while it runs, and does not automatically modify the scene beyond LOD distance adjustments.

How I would use Nebula PRO#

1. Open the scene you want to investigate.
2. Run a scene scan.
3. Use the heatmap to find renderer/geometry hotspots.
4. Select the relevant mobile/platform preset.
5. Inspect expensive renderers and LOD configuration.
6. Adjust LOD transitions where appropriate.
7. Then validate the result on a real device using Unity's runtime profiling tools.

That makes it a sensible option when the pain is primarily scene complexity, renderer cost, LOD review, and visual identification of hotspots.

At the time of writing, the Asset Store listing shows $9.99 and Unity 6 compatibility across Built-in, URP, and HDRP. Always check the current store listing before buying because prices and compatibility can change.

2. Advanced Optimization Kit Pro: A Broader Optimization Pipeline#

Advanced Optimization Kit Pro takes a broader approach. Rather than concentrating mainly on one scene-analysis problem, it is organized as a multi-phase optimization workflow spanning project scanning, runtime systems, quality management, profiling, benchmarking, performance sessions, and regression investigation.

The current workflow is intentionally review-first rather than “press Optimize and hope.” The idea is to identify risks, inspect the actual object or asset involved, make controlled changes, then prove whether those changes improved the project.

How I would use Advanced Optimization Kit Pro#

1. Create a project snapshot before risky changes.
2. Run the project/scene scanners and health-dashboard checks.
3. Sort the findings by impact instead of fixing every warning equally.
4. Inspect the affected assets, objects, settings, shaders, scripts, physics, lighting, UI, audio, and other flagged areas.
5. Apply only changes you understand and that fit the project.
6. Re-scan and compare.
7. Use runtime quality, culling/streaming, profiler overlays, or adaptive-quality systems where they fit the game.
8. Benchmark and record performance sessions to verify that the change survives real gameplay.

That makes it more appropriate when the problem is not just “this scene has heavy renderers,” but “this whole project needs a repeatable optimization process and I want to know what changed, why it changed, and whether it actually helped.”

The Asset Store currently lists Advanced Optimization Kit Pro at $99, version 2.1, with Unity 2022.3 and Unity 6 compatibility shown across Built-in, URP, and HDRP.

Which One Fits Which Workflow?#

There is no reason to pretend those are the same product with different logos.

If you mainly want a cheap, focused way to visualize scene complexity and tune LODs, Nebula PRO is much easier to justify.

If you want something that follows optimization from project audit through runtime behaviour, quality systems, benchmarking, session recording, and regression proof, Advanced Optimization Kit Pro is targeting a much larger workflow.

And neither removes the need to understand Unity's own Profiler. A good optimization tool should make investigation easier, not replace evidence with a green button.

If the Price Is the Problem#

$99 is not small money for every indie developer. Depending on where you live, it can be the difference between “useful development expense” and “absolutely not this month.”

If Advanced Optimization Kit Pro looks like the right fit for a real project but the price is what stops you, reach out to CirclesLab and explain what you are building and your situation. Discounts can sometimes be discussed for developers working with genuinely tight budgets.

There is no need to buy a tool simply because an article mentioned it. The free workflow above remains the foundation. Buy workflow tools when the time they save is worth more to you than the price.

What I Would Tell the Original Poster#

If I had to compress all of this into an answer for the Reddit developer, it would be:

1. Pick the weakest phone you genuinely intend to support.
2. Set a real FPS and memory target.
3. Make a Development Build and profile that phone.
4. Find out whether CPU, GPU, or memory is the primary problem.
5. Fix the largest measured problem first.
6. Build Low/Medium/High presets around the systems that actually cost you performance.
7. Treat Addressables as an architecture choice, not a mandatory mobile checkbox.
8. Test long enough to catch thermal throttling.
9. Measure again after every meaningful change.

The important result is not “Low disables shadows.”

The useful result is “Low makes this target device hold the performance target without ruining the game.”

The Real Rule#

There is no final state called a “fully optimized Unity project.”

There is a project that meets its performance, memory, battery, loading, and visual targets on the hardware it intends to support.

You can always remove another effect. Compress another texture. Rewrite another method. Merge another material.

Eventually the question has to stop being:

Can I optimize this more?

and become:

Does the game now meet its targets on the devices I actually support?

If yes, ship the game.

If no, measure again, find the biggest problem, fix that one, and repeat.

That is optimization.

Not a bag of tricks.

A feedback loop.

About the author

Emeka Igbokwe-Azogu

Emeka Igbokwe-Azogu is the developer behind CirclesLab, where he builds Unity tools, games, and software systems.

Writing came long before much of the technology. He started by drawing comic books when he was young, then moved from illustrated stories into writing stories in books. Life eventually pulled him through game development, software, work, and enough other responsibilities that writing moved into the background.

It never completely left. Storytelling and the instinct to pull an idea apart still sit underneath a lot of the work. For now he plans to write occasionally about games, tools, worlds, mistakes, systems, and whatever else seems worth examining. As life settles with age, writing may become a larger part of the journey again.

Sources and Further Reading#

• Original r/Unity3D discussion
• Unity profiling tools reference
• Unity Deep Profiling documentation
• Unity Memory Profiler
• Unity URP performance settings
• Unity Adaptive Performance
• Nebula PRO Asset Store listing
• Advanced Optimization Kit Pro Asset Store listing

Product prices and compatibility above reflect the public Asset Store listings checked on 28 September 2026 and can change later.