Skip to content
macOSFix Published Updated 4 min readViews unavailable

Fixing an App That Won't Quit or Respond on macOS

Force Quit doesn't work, the icon keeps bouncing, or it's stuck 'Not Responding' indefinitely — the actual escalation path, gentlest to most forceful.

An unresponsive application on macOS has a clear escalation path from gentle to forceful — working through it in order avoids losing unsaved work unnecessarily by jumping straight to the most drastic option.

Step 1: wait briefly for genuinely busy (not actually frozen) operations

A spinning beachball during a large file save, import, or
export operation may resolve on its own within a reasonable
time — check Activity Monitor's CPU usage for the app
first (Step 2) before assuming it's truly stuck.

Step 2: check whether the app is actually doing something, via Activity Monitor

Applications → Utilities → Activity Monitor →
  find the app → check % CPU

An app actively using CPU is doing something, even if unresponsive to input — genuinely deadlocked/frozen apps typically show at or near 0% CPU while still failing to respond.

Step 3: try Force Quit from the Apple menu

 → Force Quit… → select the app → Force Quit

Step 4: if Force Quit itself doesn’t respond, use Activity Monitor to quit it

Activity Monitor → select the process → the (X) stop button
  → "Force Quit"

Activity Monitor operates more directly than the Force Quit dialog and can succeed in cases where the dialog itself hangs waiting for a response from the frozen app.

Step 5: use kill from Terminal for a process nothing else can stop

killall -9 "App Name"

Or, targeting a specific process ID:

ps aux | grep "App Name"
kill -9 <pid>

-9 (SIGKILL) terminates the process immediately without giving it a chance to clean up — appropriate as a last resort, since any unsaved work in that specific app is lost at this point regardless of which method actually stops it.

Step 6: check Console.app for what the app was doing before it hung

Applications → Utilities → Console → search for the app name

Console may show a crash report or repeated error messages explaining why it hung, useful for preventing a recurrence rather than just resolving this one instance.

Step 7: check for a known issue if this happens repeatedly with the same app

A specific application hanging repeatedly, rather than a one-off, points at an app-specific bug (often tied to a specific file, a specific macOS version, or a specific plugin/extension) worth checking the developer’s own support resources for, rather than continuing to force-quit it as a recurring routine.

Step 8: restart if the system itself seems affected beyond just the one app

If Force Quit and kill -9 both fail to actually terminate the process, or overall system responsiveness is degraded beyond just the one app, a restart is the appropriate next step rather than continuing to escalate within the running session.

Why checking Activity Monitor’s CPU usage first saves real time

Distinguishing “genuinely frozen, doing nothing” from “extremely busy, will finish eventually” before reaching for Force Quit prevents killing an app mid-way through a long operation (a large export, an application update) that would have finished on its own — losing that in-progress work unnecessarily is a common, avoidable mistake from force-quitting too early.

Capturing a sample before you kill it, if this keeps happening

sample "App Name" 10 -file ~/Desktop/appname-sample.txt

If the same app hangs repeatedly and you actually want to understand why (rather than just clearing this one instance), sample captures ten seconds of that process’s call stack across multiple threads before you force-quit it — genuinely useful diagnostic information a bug report to the developer can actually act on, versus “it hangs sometimes,” and something that’s impossible to capture retroactively once the process is already gone. Running this immediately before Step 3-5’s actual termination, rather than skipping straight to killing the process, costs only a few seconds and preserves evidence that’s otherwise lost the moment the hung process is terminated.

Why SIGKILL sometimes still doesn’t work

kill -9 (SIGKILL) is meant to be unblockable by the target process — but a process stuck in an uninterruptible kernel wait (blocked on a slow or hung filesystem operation, a stalled network mount, a driver-level I/O call that never returns) can persist even after SIGKILL is sent, because the kernel itself hasn’t yet returned control to userspace where the signal would actually take effect. This specific pattern — kill -9 accepted without error but the process still visibly running — is a reasonably strong signal that whatever the app was blocked on (a hung network share, a failing external drive) is the real underlying problem, and addressing that resource directly, or a restart, is more likely to resolve it than continuing to retry the kill.

Related:

Sources:

Comments