Mac Stuck on the Loading Screen: How to Narrow It Down

A Mac sitting on the Apple logo with a progress bar that has not moved for twenty minutes is the hardest kind of problem to troubleshoot, because the machine cannot tell you anything while it is happening. There is no Terminal, no error text, and nothing on screen that separates “still working” from “will never finish”.

What follows is ordered by how much it can tell you, and it is explicit about which parts are documented procedure rather than something observed here: the recovery steps below are Apple’s documented ones, not a hang reproduced on this machine. The diagnostic commands are different — those were run on macOS 26.5.2, and they are what turns a mystery hang into something you can actually read afterwards.

Which screen you are looking at

Three different things get called “stuck on the loading screen”, and they are not the same problem:

• Apple logo with a progress bar. The system is loading. A bar that advances even slowly is doing work — first boots after a macOS update routinely take far longer than normal.
• Apple logo with no bar at all, for many minutes. Firmware handed off to the system and something early is not completing.
• A folder with a question mark, or a prohibitory sign. A different failure entirely — the Mac cannot find or cannot use a startup disk. That one has its own set of causes and fixes.

Give the first case real time before treating it as a hang. Thirty minutes is not excessive after an update; a progress bar that has genuinely not moved in an hour, with no drive activity and the fans idle, is the point where waiting has stopped being useful.

Disconnect everything, then try again

This is first for a reason: it costs nothing, it is reversible, and external devices are enumerated early in startup. A hub that has stopped responding, a drive with a damaged partition table, or a dock that misbehaves after a firmware update can all stall a boot before macOS has any way of telling you so.

Unplug everything except power — drives, hubs, docks, card readers, wired keyboards — hold the power button until the Mac shuts down, and start it again. If it boots clean, reconnect one device at a time. The one that reproduces the hang is your answer, and it is usually not the one you suspected.

Safe mode, and confirming you are in it

Safe mode loads a minimal system, skips third-party startup items, and runs a check of the startup disk on the way in. It is the fastest way to establish whether the problem is macOS itself or something layered on top of it.

Apple’s documented steps differ by architecture. On an Apple silicon Mac, press and hold the power button until “Loading startup options” appears, select your startup volume, then hold Shift and click “Continue in Safe Mode”. On an Intel Mac, restart and immediately hold Shift until the login window appears. Apple’s page notes you may be asked to log in twice, and that “Safe Boot” appears in the menu bar once you are in.

That menu bar indicator is easy to miss, and there is a definitive check that does not depend on spotting it:

$ sysctl kern.safeboot
kern.safeboot: 0

$ system_profiler SPSoftwareDataType | grep "Boot Mode"
      Boot Mode: Normal

Those are from a normal boot — 0 and Normal. In safe mode the values change accordingly, which settles the “did the Shift key actually register?” question that costs people a lot of repeat attempts. It is worth knowing before you need it, because a Mac that boots fine in safe mode and hangs normally has already narrowed the problem to login items, third-party kernel extensions, or a fonts and caches issue — none of which are the disk failure people usually fear at that stage.

Reading the log of the boot that failed

Here is the part almost nobody mentions. macOS keeps its unified log across restarts, so once the Mac does come up — in safe mode, or after removing whatever stalled it — you can read what the failed boot was doing before it stopped:

$ log show --last boot | head
Timestamp                       Thread     Type        Activity  PID
2026-07-03 07:27:20.018005+0800 0x0        Timesync    0x0       0    === system boot: 1F2E3D4C-...

The boot UUID is replaced with a placeholder above; everything else is as printed. That === system boot: marker is what the log uses to delimit one startup from the next, which is what makes --last boot possible at all.

The full output is enormous, so narrow it. log show --last boot --predicate 'process == "kernel"' --style compact gives the kernel’s own view, where a driver waiting on hardware that never answers tends to stand out as a gap in the timestamps followed by repeated retries. To look at the boot before the current one, --start and --end with times bracketing the failed attempt does the same job.

This will not fix anything by itself. What it does is replace guessing with a name — a kext, a service, a device — which is the difference between a targeted fix and reinstalling macOS because nothing else was left to try.

Leftover boot arguments

NVRAM can hold arguments passed to the kernel at startup. They are not set by default, and stale ones left behind by an old troubleshooting session or a since-removed tool can stall or break a boot:

$ nvram boot-args
nvram: Error getting variable - 'boot-args': (iokit/common) data was not found

That error is the healthy result: the variable does not exist because nothing ever set it. If instead you get a line of flags back, that is worth investigating before anything more drastic — sudo nvram -d boot-args removes it.

When it needs Recovery

If safe mode also hangs, the next documented step is Recovery: power button held on Apple silicon, Command-R at startup on Intel. From there, First Aid in Disk Utility on the startup volume checks the filesystem, and reinstalling macOS replaces the system without touching the data volume.

Reinstalling is not the same as erasing, and the order matters: run First Aid first, because a reinstall onto a volume with filesystem damage can fail partway and leave you worse off. If the Mac will not reach Recovery either, the remaining path is reviving or restoring the firmware from a second Mac, which is a separate procedure with its own requirements.

Back up before the reinstall if there is any way to do it — Target Disk Mode, or pulling files from Recovery’s Terminal — and treat “reinstall fixed it” as an answer that never told you what was wrong. If the same hang returns weeks later, the log from that first failed boot is the thing you will wish you had read.