Native macOS Performance: Principles, Measurement, and Budgets

Protect the main thread

On macOS the main thread is responsible for handling input and updating the interface. Anything that blocks it, file parsing, network waits, heavy computation, directly translates into a frozen window and a spinning cursor. The single most important performance principle for a native app is that the main thread should do as little work as possible beyond rendering and responding to events.

This means moving expensive work to background queues and returning to the main thread only to update the interface with the result. Disk and network access in particular should never run synchronously on the main thread, because their latency is unpredictable and their stalls are immediately visible to the user.

Measure, do not guess

Performance intuition is unreliable. The component a developer suspects is rarely the one consuming the time, and optimizing the wrong thing wastes effort while the real cost remains. Apple’s Instruments toolset exists precisely to replace guessing with evidence.

• Use the Time Profiler to find where CPU time is actually spent.
• Use the Allocations and Leaks instruments to track memory growth and detect leaks.
• Watch for main-thread stalls and hangs, which are the most user-visible failures.
• Profile a release build, since debug builds have different performance characteristics.

Set explicit budgets

A budget turns performance from a vague aspiration into a measurable requirement. Without one, an app degrades gradually as each feature adds a little overhead that no single person notices. With one, a regression becomes a failed check rather than a slow erosion.

The practice that keeps budgets honest is to measure them continuously and treat an overrun the same way you treat a correctness bug. A feature that ships but blows the launch budget is not finished.

Common sources of slowness

A handful of patterns account for a large share of performance problems on macOS. Doing layout or text measurement repeatedly when it could be cached. Loading more data than the visible interface needs. Allocating and deallocating objects in tight loops. Synchronous work that should have been asynchronous.

TextPack, which renders documents to PDF, is a useful example: rendering is inherently CPU-intensive, so it runs off the main thread and reports progress back, keeping the interface responsive even while a large document is being laid out. The general lesson is that heavy work is acceptable as long as it does not happen where the user is waiting to interact.