Three unrelated failures share one phrase. Sorting them takes about thirty seconds and saves you from following the wrong fix, so do this in order.
First: does your Mac meet the requirements?
LM Studio's own system requirements state "Apple Silicon (M1/M2/M3/M4)", "Intel-based Macs are currently not supported", and "macOS 14.0 or newer is required". It recommends 16GB of RAM or more, and says 8GB works if you "stick to smaller models and modest context sizes". If your Mac fails either the chip or the OS line, the app is behaving correctly and no fix exists.
This is the answer for a meaningful share of the people searching, and it deserves to be said plainly rather than buried under registry-style cleanup advice. Two notes on it:
If you are on an Intel Mac, we are not your alternative either. ToolPiper is Apple Silicon only, with a higher OS floor than LM Studio's. Pointing you at us would waste your time. Look at llama.cpp built from source, or at Ollama, which still ships an Intel-compatible macOS build. That is the honest answer and it does not involve us.
If you are on Apple Silicon but an older macOS, LM Studio's floor of 14.0 is lower than ours, so LM Studio is the one that runs. Update macOS if you can; if you cannot, keep using it and stop reading here.
Second: the app will not open at all
An app that bounces once in the Dock and quits, or that never appears, is usually a quarantine or bundle-integrity problem rather than a problem with the app itself. macOS attaches a quarantine attribute to anything downloaded from a browser, and a download interrupted partway leaves a bundle that looks complete in Finder and is not.
The order that resolves nearly all of it:
Move it to Applications. Running an app from the mounted disk image, or from Downloads, produces a class of launch failures that go away the moment the bundle is in /Applications. Eject the disk image afterwards.
Redownload rather than retry. A truncated app bundle behaves exactly like a corrupt one, and relaunching does not repair it. Delete and download again, and let it finish before you touch it.
Give it the full first launch. First run does more work than later ones, and interrupting it can leave partial state that makes the second launch worse than the first.
If the app opens but the lms command does not work, that is expected and not a bug: LM Studio's docs state lms ships with the app and requires LM Studio to have been run at least once before it can be used.
Third: the beachball that is not a hang
A spinning cursor during a model load is usually the app waiting on the largest single allocation it will ever make, not a crash. Loading a multi-gigabyte model reads the whole file and commits it to memory, and on a machine under pressure that takes long enough to look like a freeze. Give it more time than feels reasonable before force-quitting.
Two things make this worse in ways that are worth knowing.
Memory pressure turns a slow load into a stall. Apple Silicon shares one memory pool between the CPU and the GPU, and macOS reports a working-set ceiling to Metal that is a fraction of installed RAM. On our M2 Max with 32GB it reads 26,800,603,136 bytes, roughly 25GiB. Loading a model that sits near that line while a browser and an editor are competing for the same space produces exactly this symptom.
Going over the line is not a normal error. A wired-memory overflow on Apple Silicon is a kernel-level fault, not an allocation failure the app can catch and report to you. That is why an over-budget load can take the machine down rather than showing a dialog, and why the only real defense is refusing the load before it starts. Check Activity Monitor's memory pressure graph before you attempt a load that you know is close.
It stopped working after an update
Two different things hide here. If models that used to load now fail, the bundled engine changed and the file is the issue rather than the app, which is a separate diagnosis. If the app itself will not start after updating, treat it as the bundle-integrity case above: an update that downloaded incompletely produces the same symptom as a bad first download.
What to check, in order
Stop at the first one that matches. Most people are done by step two.
The alternative, and when it is not one
If your Mac runs macOS 26 or newer on Apple Silicon, ToolPiper is a native Mac app with the same engine lineage: upstream llama-server embedded directly, build b10068, unmodified. On inference speed expect parity, not an advantage. Our same-bytes benchmark on an M2 Max landed within single digits in both directions with the winner flipping by model.
The relevant difference for this page is the third failure above. The app reads your installed memory and the live Metal working-set ceiling and sizes model suggestions against them, so the list tells you what your Mac can hold before you commit. On the MLX path that reading is a hard gate rather than a hint: a load projected to exceed the budget is refused before any allocation, because a wired-memory fault is not something an app gets to apologize for afterwards.
The rest of the free tier is the whole runner: unlimited GGUF downloads, multi-model switching, the local OpenAI-compatible API, embeddings, developer tokens, all speech, browser automation, and an MCP server with over 420 tools. Local RAG over your files is the $10 Pro tier. No account, no caps, no terminal.
And to repeat the part that matters more than the pitch: if you are on an Intel Mac, or on macOS 25 or earlier, this is not your answer. LM Studio's requirements are lower than ours, and on those machines it is the one that runs.
If you are on a Mac we do support, the cost of trying is nothing. LM Studio's local app is free, with cloud inference billed separately per token. Our runner is free outright, with no account and no caps. Here is what each one charges for.