Previously, I never really understood the phrase “runs on potatoes” back in 2016, until I had the scope to work with a Unity game development team and play a game that is developed with the Unity engine and works on a 1GB RAM Android phone. If you have mostly developed and tested on your dev machine or a flagship device, trust me, you are missing out on a very real part of the market that lives and breathes budget phones.
Over the last couple of years working at Red Apple Technologies, I’ve been part of game projects that needed to run decently on everything—from mid-range Samsungs to ultra-budget devices in Southeast Asia and Africa. The goal wasn’t "buttery smooth 60 FPS," but something more humble: "Doesn’t lag like hell."
Here’s what we learned the hard way.
🔄 Stop Instantiating Everything
If your game has bullets, enemies, or anything that comes and goes frequently—and you’re still using Instantiate() and Destroy() every time—you’re going to run into performance hiccups.
On low-end devices, every call to Instantiate() is like asking your game, “Wanna stutter now?” And it almost always says yes.
What we did:
Built a really basic object pooler.
Preloaded everything we needed at the start.
Used SetActive(true/false) instead of instantiating at runtime.
One of our games cut CPU usage by nearly 40% just from this.
## 🎨 Sprites + UI: Less Is Definitely More
I once saw a junior dev make a mobile game with 4096x4096 textures. It looked stunning. It also ran at 9 FPS on our test phones.
Texture size matters more than you think. And Unity’s UI system? That’s a beast if you’re not careful. Canvas rebuilds can choke weak devices.
What worked for us:
Keeping sprite atlases small and compressed (512x512 or 1024x1024 max).
Disabling Raycast Target on all non-interactive UI.
Splitting dynamic and static canvases to reduce redraws.
Also, no more than 2-3 font types. That stuff adds up.
## 💡 The Lighting Trap
Baked lighting is your friend. Real-time lights? Not so much—especially with shadows.
In one game, just switching to a fully baked lighting setup gave us an instant FPS boost. Bonus: our battery usage dropped too.
Pro tip: If your scene is static, there's literally zero reason to use dynamic lighting. Your players won't notice it, but their devices will thank you.
⚠️ Garbage Collection: Silent Performance Killer
The profiler became our go-to tool once we realized GC spikes were causing microstutters. The biggest culprits?
String concatenation in Update()
foreach loops over List
Unintentional boxing
We replaced all of those with pooled lists, StringBuilder, and cached references. The game felt instantly smoother—like, noticeably so.
## 🧪 You Need to Test on Actual Crap Phones
Seriously, when your only test device is an emulator or a Pixel 8, you are not serious about tackling issues that your game may encounter post-launch.
So, we usually bought a few cheap Android phones comprising 2GB RAM, old chipsets, and bloated storage. Then we started testing every build on them. That was when we noticed how your game’s performance may be severely impacted under memory pressure.
The lesson: your game doesn’t live in Unity Editor. It lives in your users' hands.
## 📌 Final Thought
As a game developer, you should remember one thing that when developing a game, you need to make it run well for everyone, especially those not using a flagship phone, which is the real challenge.
It is not about hacking your way to 60FPS. It is about understanding your audience and optimizing your game quality accordingly.
When you are building games for low-end devices and want more tips and guidance to succeed in this industry, I would genuinely love to hear from you.
Top comments (0)