Great MacBooks, rough tools: the Android emulator story

I like my MacBook. Apple Silicon is genuinely impressive hardware — fast, quiet, absurdly efficient. So when something runs hot and slow, it's tempting to blame the laptop. Usually that's the wrong target. The machine is fine. The tools around it haven't caught up.

The machine isn't the problem

These chips sip power for most work. If your fans are screaming and your editor is stuttering, the first question shouldn't be "is my Mac underpowered?" — it almost never is. The right question is "what is this tool actually asking the machine to do?"

A concrete example: the Android emulator

Android Studio is the classic case. If you spin up an emulator without configuring it, you can end up with an image that wasn't chosen for your architecture. The defaults lean toward the x86 world, so the emulator ends up emulating a foreign architecture instead of running natively. Virtualizing like that burns a ridiculous amount of CPU — heat, throttling, a laptop that feels broken — for an emulator that should be light.

The fix is configuration, not hardware

The answer isn't a beefier machine. It's knowing your tools. Pick an ARM system image so the emulator runs natively. Tune the cores, RAM, and graphics backend it's allowed to use. Suddenly the same "slow" MacBook runs the same emulator cool and fast.

The lesson generalizes: when a great machine struggles, suspect the toolchain before the hardware. The defaults were written for someone else's setup, and defaults are just decisions nobody revisited. Revisit them.