The spinning pinwheel is a type of throbber or variation of the mouse pointer used in Apple's macOS to indicate that an application is busy.^[1]

Officially, the macOS Human Interface Guidelines refers to it as the spinning wait cursor,^[2] but it is also known by other names. These include, but are not limited to the spinning beach ball,^[3] the spinning wheel of death,^[4] or the spinning beachball of death.^[5]

History

A wristwatch was the first wait cursor in early versions of the classic Mac OS. Apple's HyperCard first popularized animated cursors, including a black-and-white spinning quartered circle resembling a beach ball. The beach-ball cursor was also adopted to indicate running script code in the HyperTalk-like AppleScript. The cursors could be advanced by repeated HyperTalk invocations of "set cursor to busy".

Wait cursors are activated by applications performing lengthy operations. Some versions of the Apple Installer used an animated "counting hand" cursor. Other applications provided their own theme-appropriate custom cursors, such as a revolving Yin Yang symbol, Fetch's running dog, Retrospect's spinning tape, and Pro Tools' tapping fingers. Apple provided standard interfaces for animating cursors: originally the Cursor Utilities (SpinCursor, RotateCursor)^[6] and, in Mac OS 8 and later, the Appearance Manager (SetAnimatedThemeCursor).^[7]

From NeXT Step to MacOS X

NeXTStep 1.0 used a monochrome icon resembling a spinning magneto-optical disk.^[a] Some NeXT computers included an optical drive, which was often slower than a magnetic hard drive and so was a common reason for the wait cursor to appear.

When color support was added in NeXTStep 2.0, color versions of all icons were added. The wait cursor was updated to reflect the bright rainbow surface of these removable disks, and that icon remained, even when later machines began using hard disk drives as primary storage. Contemporary CD Rom drives were even slower (at 1x, 150 kbit/s).^[b]

With the arrival of Mac OS X, the wait cursor was often called the "spinning beach ball" in the press,^[8] presumably by authors not knowing its NeXT history or relating it to the HyperCard wait cursor.

The two-dimensional appearance was kept essentially unchanged^[c] from NeXT to Rhapsody/Mac OS X Server 1.0 which otherwise had a user interface design resembling Mac OS 8/Platinum theme, and through Mac OS X 10.0/Cheetah and Mac OS X 10.1/Puma, which introduced the Aqua user interface theme.

Mac OS X 10.2/Jaguar gave the cursor a glossy rounded "gumdrop" look in keeping with other OS X interface elements.^[9] In OS X 10.10, the entire pinwheel rotates (previously only the overlaying translucent layer moved). With OS X 10.11 El Capitan the spinning wait-cursor's design was updated. It now has less shadowing and has brighter, more solid colors to better match the design of the user interface and the colors also turn with the spinning, not just the texture.

System usage

In single-task operating systems like the original Macintosh operating system, the wait cursor might indicate that the computer was completely unresponsive to user input, or just indicate that response may temporarily be slower than usual due to disk access. This changed with multitasking operating systems such as System Software 5, where it is possible to switch to another application and continue to work there. Individual applications could also choose to display the wait cursor during long operations (and were often able to cancel this display with a keyboard command).

After the transition to Mac OS X (macOS), Apple narrowed the meaning of the wait cursor. The display of the wait cursor was only able to be controlled by the operating system, not by the application. This could indicate that the application was in an infinite loop, or just performing a lengthy operation and ignoring events. Each application has an event queue that receives events from the operating system (for example, key presses and mouse button clicks); and if an application takes longer than 2 seconds^[10] to process the events in its event queue (regardless of the cause), the operating system displays the wait cursor whenever the cursor hovers over that application's windows.

This is meant to indicate that the application is temporarily unresponsive, a state from which it should recover. It may also indicate that all or part of the application has entered an unrecoverable state or an infinite loop. During this time the user may be prevented from closing, resizing, or even minimizing the windows of the affected application (although moving the window is still possible in OS X, as well as previously hidden parts of the window which are usually redrawn, even when the application is otherwise unresponsive). While one application is unresponsive, typically other applications are usable. A file system and network delays are another common cause.

Guidelines, tools and methods for developers

By default, events (and any actions they initiate) are processed sequentially, intended to limit the trivial amount of processing from each event. The spinning wait cursor will appear until the operation is complete. If the operation takes too long, the application will appear unresponsive. Developers may prevent this by using separate threads for lengthy processing, allowing the application's main thread to continue responding to external events. However, this greatly increases the application's complexity. Another approach is to divide the work into smaller packets and use NSRunLoop or Grand Central Dispatch.

• Bugs in applications can cause them to stop responding to events; for instance, an infinite loop or a deadlock. Applications afflicted rarely recover.
• Problems with the virtual memory system—such as slow paging caused by a spun-down hard disk or disk read-errors—will cause the wait cursor to appear across multiple applications, until the hard disk and virtual memory system recover.

Instruments is an application that comes with the Mac OS X Developer Tools. Along with its other functions, it allows the user to monitor and sample applications that are either not responding or performing a lengthy operation. Each time an application does not respond and the spinning wait cursor is activated, Instruments can sample the process to determine which code is causing the application to stop responding. With this information, the developer can rewrite code to avoid the cursor being activated.

Apple's guidelines suggest that developers try to avoid invoking the spinning wait cursor, and instead suggest using other user interface indicators, such as an asynchronous progress indicator.