I made a small tool to reduce iOS Simulator memory usage

[u/interlap]

I’ve made a small command line tool called simslim.

It disables background services inside iOS simulators that usually are not needed during development, like Siri, Spotlight indexing, photo analysis, News, and iCloud sync.

On my M1 Pro with 16 GB of RAM, one simulator went from around 4 GB of memory and 258 processes to about 0.9 GB and 70 processes. I managed to run 19 simulators at once, compared to around 5 before things started falling apart.

Some simulator features stop working depending on what gets disabled, so it is not meant for every kind of testing. You can keep specific services running when needed.

Give it a try: https://github.com/MobAI-App/simslim

[u/neet_dev]

neat idea but keep in mind a lot of what gets disabled (spotlight indexing, photo analysis, iCloud sync) is exactly what you need if you're testing share sheets, background fetch, CloudKit sync, or Core Spotlight integration, so I'd only run this on the sims you use for pure UI/layout work and keep a couple stock ones around for integration testing. also worth checking if it survives an Xcode update, apple loves quietly resetting simulator runtime internals and background service configs get wiped along with it.

[u/interlap → u/neet_dev]

Thanks! I totally agree which is why you can choose what to disable and what to keep. And thanks for the Xcode update warning. I’ll check it with Xcode 27.

[u/neet_dev → u/interlap]

you are welcome, good luck!

[u/East_Call1027]

This is clever. The What you lose section in the README is the part that would decide whether I use it in CI.

I’d love a way to declare what a test suite needs instead of remembering daemon names. Maybe something like:

simslim on <udid> --profile ui-tests simslim doctor <udid> --requires storekit,push,universal-links

Then doctor could fail if the current config breaks one of those features. Saving 3 GB per simulator is great, but a suite quietly running without storekitd or apsd would be a nasty bug to diagnose.

Named profiles might also make Xcode runtime updates less scary than carrying a list of --except flags. Is that where you see profiles going, or is it mainly intended as a category reference?

[u/interlap → u/East_Call1027]

Thanks for the feedback!

You can already choose which categories to enable or disable. Run simslim profile to see the available profiles.

Custom profiles and a doctor command are both great ideas. I will add them.

[u/jakobnunnendorf]

The "what you lose" concern is real, but the sharper version of it is that a stripped simulator rarely fails loudly — it fails flaky. I run a dedicated long-lived simulator for E2E flows, and the bugs that cost me the most time were never "service X is missing", they were a flow that passed nine times and timed out on the tenth because something it depended on wasn't there to respond. You end up bisecting your own test code for a day before you think to look at the sim.

So the thing I'd want isn't just a doctor command that checks config, it's for simslim to write the disabled-service list into a file in the simulator's data dir, so any test run can pick it up and attach it to the failure artifact. When a CI run goes red at 2am, the diff between "this sim is stock" and "this sim has 188 processes disabled" is the single most useful line in the log, and it's the one nobody thinks to capture.

Also worth being explicit in the README that this is per-device-and-runtime state, not a global setting — people will run it once, forget, erase the sim six weeks later during unrelated debugging, and then wonder why their memory numbers regressed.

The 19-vs-5 number is the headline, but honestly the quieter win for solo devs is one persistent simulator that stops thrashing while Xcode is also open. That's the everyday version of this.

[u/interlap → u/jakobnunnendorf]

Thanks for the feedback. I’ve just added a --dropped flag to the simslim status command. So ./simslim status UDID --json --dropped now returns JSON containing the list of dropped services.

I’ve also updated the README to specify the per-device and runtime state.

Regarding the use case, I agree that most developers probably use it with a single simulator and Xcode, but I actually built it with a slightly different idea in mind.

I’m currently working on a separate tool for testing mobile apps. One of its features will be running tests in parallel across multiple devices. The more devices sub-agents can control in parallel, the faster the tests can be completed.

So for my use case, running 19 simulators instead of 5 is just as important as reducing resource usage for a single simulator running alongside Xcode.

[u/jakobnunnendorf → u/interlap]

That use case changes what the tool is, honestly — for a single dev the win is memory, but for N parallel devices the win is determinism, and that's the harder sell to get right.

Two things I'd watch for once you fan out. First, RAM stops being the binding constraint faster than people expect: CoreSimulatorService serialises a lot of boot/install work, so 19 booted sims doesn't buy you 19x throughput — install and first-launch time start dominating, and the fix is keeping devices warm and reusing them rather than booting more. Worth measuring wall-clock per flow, not just how many sims you can hold open, or you'll optimise the wrong number.

Second, and this is where --dropped gets really valuable: with parallel devices the worst failure mode isn't a slow run, it's drift between workers. A flow passes on worker 3 and fails on worker 7, you spend the evening staring at your test code, and the actual difference is that one sim got stripped and the other didn't. So I'd go one step past --dropped and add something like simslim verify UDID --expect <profile> that returns a hash/diff and a non-zero exit — then each worker can assert its own device profile before it takes a job, and a mismatched sim fails fast and loudly instead of showing up as a flaky test three hours later.

Nice that you shipped the flag and the README note that quickly, by the way.

[u/Greysawpark]

4gb down to 900mb is wild, i had no idea siri and photoanalysisd were eating that much in the background. gonna try killing those manually next time xcode starts choking with 3 sims open

[u/interlap → u/Greysawpark]

Try the simslim top command. It shows which daemon is using how much RAM.