Mac app release QA checklist for build, assets, and load

A Mac app release QA checklist should end in one evidence packet: the exact candidate, the path a reviewer will follow, current metadata and URLs, accepted screenshot files, plus an idle-to-action performance check. Record a pass or fail for each artifact before you submit or publish.

Disclosure: I build TeenyApps. TeenyColor can collect local sRGB samples from the rendered screen, while TeenyStat can keep aggregate CPU, used memory, and fan data visible during a capture run. Neither app validates App Store files or identifies a busy process. App Store Connect and Activity Monitor remain the authoritative tools for those jobs.

Release evidence packet

01Name the exact candidate and reviewer path

Start the record with the build number, version, commit or archive, distribution channel, and test account. A screenshot from yesterday's build does not prove today's candidate, even when the UI looks unchanged.

Apple's App Review Guideline 2.1 says submissions should be final, include necessary metadata and working URLs, and be tested on device for bugs and stability. Apps with login also need demo account information and a working back end. If legal or security duties prevent a demo account, Apple describes an approved built-in demo mode as the alternative.

Run the candidate from a clean user session. Walk the first-launch permission path, purchase or license state, restore path, support contact, and any feature named in the review notes. Record what the reviewer should see and the point where a missing service or credential would stop the review.

02Match metadata and URLs to the candidate

App Review Guideline 2.3 requires metadata, privacy information, descriptions, screenshots, and previews to reflect the app's current experience. That makes accuracy a release check, not a marketing polish task.

Open every support, privacy, marketing, and download URL from a clean browser session. Confirm the page names the current app and version where relevant, the download points to the intended artifact, and the privacy description matches the build's real data behavior. For direct distribution, add the updater feed and payment-to-license path to the same check.

Keep private review credentials out of screenshots and public issue trackers. The release packet can say where the credential is stored and who verified it without copying the secret into the record.

03Validate the final Mac screenshot files

App Store Connect currently accepts one to 10 screenshots in PNG, JPG, or JPEG format. Images cannot include an alpha channel or transparency. A Mac screenshot must use a 16:10 aspect ratio at one of four sizes: 1280 by 800, 1440 by 900, 2560 by 1600, or 2880 by 1800 pixels.

Check the file that will be uploaded, not the design canvas. Record its dimensions, file type, alpha status, appearance, language, and the candidate state shown. Apple's product-page guidance says the first one to three screenshots may appear in search results when there is no app preview, and it recommends showing Dark Mode when the app supports it.

For the color pass, TeenyColor uses NSColorSampler and converts the sampled color to sRGB when possible. That is useful for documenting a rendered pixel. It does not validate screenshot dimensions, alpha, App Store eligibility, or the semantic color behind that pixel. The Mac app screenshot QA guide keeps those boundaries explicit.

04Compare idle, open, action, and recovery load

A universal CPU or memory cutoff will mislead because hardware, app type, background work, and the tested action all differ. Use the same Mac and account to record four states: idle baseline, candidate open, one representative action, and recovery after the action finishes.

TeenyStat calculates aggregate and per-core CPU from tick deltas. Its current source calculates used memory as active plus wired plus compressed memory, and reads fan data through SMC when available. This is a glanceable trend, not Apple's Memory Pressure calculation. The first CPU read establishes a baseline and can be near zero.

If load does not recover, open Activity Monitor. Apple's CPU view separates System, User, and Idle activity and can show CPU History. The Memory view adds Memory Pressure, app memory, compressed memory, cached files, and swap. The Mac app performance check explains how to record the state without turning the release pass into a fake benchmark.

05Close the packet with decisions

Every row should end as pass, fail, or not applicable. Add the verifier, UTC time, candidate identifier, and a short evidence pointer. A failed screenshot file belongs in the asset task. A broken support URL belongs in the site task. Unexplained load belongs in a performance investigation.

Keep the packet small enough to rerun for the next release. The useful record is not a folder full of screenshots. It is a list that tells another person which candidate was checked, what source of truth was used, what failed, and whether the release may proceed.

Mac app release QA checklist

1. Record the version, build, commit or archive, channel, and verifier.
2. Test first launch, permissions, login or license state, and the reviewer path from a clean session.
3. Open support, privacy, marketing, and download URLs without relying on an existing sign-in.
4. Match descriptions, screenshots, previews, and review notes to the final candidate.
5. Check each Mac screenshot for count, file type, 16:10 dimensions, alpha, appearance, and language.
6. Confirm the first screenshots communicate the current app experience at their submitted size.
7. Record idle, open-app, representative-action, and recovery load on the capture Mac.
8. Use Activity Monitor if CPU or memory does not recover or the responsible process is unclear.
9. Mark every artifact pass, fail, or not applicable and assign each failure to the right task.
10. Keep private credentials and unreleased assets out of public tools and screenshots.

Common questions

What should I check before releasing a Mac app?

Verify the exact build, reviewer access, metadata, support and privacy URLs, Mac screenshot files, and a representative performance recovery check. Record each item as pass, fail, or not applicable in one release evidence packet.

What are the Mac App Store screenshot requirements?

Apple currently requires one to 10 Mac screenshots in PNG, JPG, or JPEG format without transparency. Each Mac screenshot must use a 16:10 size accepted by App Store Connect, such as 1280 by 800 or 2560 by 1600 pixels.

How do I check Mac app performance before release?

Record an idle baseline, open the final build, run one representative action, and confirm that CPU and memory recover afterward. Use Activity Monitor if the load remains high or you need process names, Memory Pressure, swap, or energy detail.

Sources checked

• TeenyColor claims were checked against the TeenyColor homepage and local Swift source for NSColorSampler, sRGB conversion, color formats, history, pins, palette export, and contrast calculations.
• TeenyStat claims were checked against the TeenyStat homepage and local Swift source for CPU reads, memory reads, fan availability, timed polling, thresholds, and alerts.
• Apple Developer: App Review Guidelines, including App Completeness and Accurate Metadata.
• Apple Developer: Screenshot specifications.
• Apple Developer: Upload app previews and screenshots.
• Apple Developer: Creating your product page.
• Apple Support: View CPU activity in Activity Monitor on Mac.
• Apple Support: View memory usage in Activity Monitor on Mac.