Mac app performance check for CPU, memory, and recovery

The short answer: record the same Mac at idle, with the release candidate open, during one representative action, and after that action should have recovered. Proceed when expected spikes settle and the final state moves back toward the starting range. Investigate when load stays elevated, memory keeps growing across repeated runs, or fan activity rises after the work has stopped.

Disclosure: I build teenystat. It is useful for a glanceable same-machine comparison. Its memory number is calculated used memory, not Apple's Memory Pressure signal, and it does not name the process causing load. Activity Monitor remains the source for process details, CPU history, Memory Pressure, swap, and quit controls.

Record four states, not one isolated number

01Capture an honest idle baseline

Use the same Mac, power mode, display setup, and background stack that will capture the release evidence. Note the Mac model and whether Xcode, a browser, a recorder, a simulator, a design file, or cloud sync is open. A comparison loses meaning when those conditions change between states.

Start before opening the release candidate. Let known setup work finish, then record a small range rather than one reading. TeenyStat's first CPU read establishes the tick baseline, so an initial value near zero is not evidence that the Mac is truly idle.

There is no universal CPU or memory number that makes every Mac ready. The useful baseline is this machine under this repeatable setup. If the starting state is already busy, identify or pause the unrelated work before attributing the load to the candidate.

02Separate launch from the representative action

Open the candidate and wait for known launch work to settle. Record that open state before triggering the action you care about. Otherwise launch initialization, data migration, update checks, or cache creation can be mistaken for the cost of an export or interaction.

TeenyStat reads per-core processor ticks and calculates usage from the change between reads. The aggregate display is the average of those per-core results. This makes direction and recovery useful, but it is not the same presentation as a process-level CPU percentage in Activity Monitor.

Now perform one representative action, such as opening the main popover, loading the real sample data, exporting an asset, or starting the demo path. Note what you did and when it ended. A spike that corresponds to known work can be normal; unexplained activity after the work ends deserves a closer look.

03Interpret TeenyStat's memory number correctly

TeenyStat reads macOS host statistics and defines used memory as active plus wired plus compressed pages. That number can support a same-machine trend, but it is not Apple's Memory Pressure graph and should not be described as one.

Memory may not return to the exact starting value because macOS and apps retain caches. The stronger warning is repeated growth under the same action, especially when responsiveness worsens or swap also rises. Repeat the action when the risk justifies it, then compare each recovery state.

Fan speed is supporting context only when the Mac exposes a fan through SMC. A delayed fan change can reflect accumulated heat rather than current CPU work. Record it when available, but do not treat a fanless Mac as missing required evidence.

04Escalate unexplained load to Activity Monitor

Open Activity Monitor when the recovery state stays abnormal, memory grows across repeated actions, or you need to separate the candidate from Xcode, a browser, Spotlight, sync, capture, or another process.

Apple's CPU pane shows System, User, and Idle percentages plus CPU Load and CPU History. Its Memory pane adds Memory Pressure, physical memory, memory used, cached files, and swap used. Those views answer questions that a compact menu bar total cannot.

Sort and inspect before quitting anything. If a process may be writing files, exporting assets, or syncing release data, use normal Quit when possible. Force Quit can discard work and should not become a cosmetic step for a cleaner screenshot.

05Close with a pass, investigate, or retest decision

A compact record needs the candidate build, Mac and power context, background stack, representative action, four observed states, and final decision. Use a range or direction when an exact number would imply more precision than the check provides.

Pass when expected spikes settle and the recovery state returns toward the baseline without repeated memory growth or a responsiveness problem. Investigate when the cause is unexplained. Retest after changing the setup so the final screenshot or demo is tied to the actual capture state.

The broader Mac app release QA checklist connects this baseline to the candidate, reviewer path, metadata, and screenshot files. Use TeenyColor's Mac app screenshot QA for color, size, and alpha on the final visual asset.

Mac app release performance checklist

1. Record the Mac, power mode, and background stack.
2. Let the first CPU sample and known setup work settle.
3. Capture a small idle baseline range.
4. Open the candidate and record its settled state.
5. Perform one named representative action.
6. Watch whether CPU, used memory, and fan activity recover.
7. Repeat when memory growth or delayed cleanup is the concern.
8. Use Activity Monitor for processes, Memory Pressure, swap, and CPU history.
9. Record pass, investigate, or retest before capturing release assets.

Common questions

How do I check Mac app performance before release?

Record the same Mac at idle, with the candidate open, during one representative action, and after the action should have recovered. Investigate in Activity Monitor when CPU, used memory, or fan activity does not return toward that Mac's baseline.

Is this a benchmark?

No. It is a same-machine release comparison. It helps catch unexplained load and weak recovery, but it does not produce a portable performance score or prove how other Macs will behave.

Can TeenyStat identify the busy process?

No. TeenyStat shows aggregate CPU, used-memory, and available fan signals. Use Activity Monitor for process names, Memory Pressure, swap, CPU history, columns, and quit controls.

Sources checked

• TeenyStat feature and limitation claims were checked against the TeenyStat homepage and local Swift source for per-core tick deltas, aggregate CPU calculation, first-read behavior, active/wired/compressed memory, fan availability, SMC reads, three-second polling, and dropped overlapping reads.
• Apple Support: View CPU activity in Activity Monitor on Mac.
• Apple Support: View memory usage in Activity Monitor on Mac.
• Apple Support: View information about Mac processes in Activity Monitor.
• Apple Support: Quit an app or process in Activity Monitor on Mac.