Mac app screenshot QA for color, size, and alpha
Check the file App Store Connect will receive, not a nearby design export. File rules, visible content, rendered color, and upload state all need their own evidence.
The short version: freeze the final screenshot file and source app state. Verify that the file is JPEG or PNG, has no alpha, and uses one of Apple's accepted 16:10 Mac sizes. Inspect the copy and current UI, sample stable pixels from the final file, check real foreground and background pairs, then confirm the saved upload is attached to the intended app version.
Disclosure: I build teenycolor. It is useful for collecting rendered sRGB color evidence from the screen. It does not inspect image dimensions, detect an alpha channel, identify semantic or adaptive colors, or approve an App Store submission.
What each screenshot check proves
| Check | Source of truth | Pass condition |
|---|---|---|
| File eligibility | The final JPEG or PNG plus Apple's current screenshot specifications. | Accepted 16:10 Mac dimensions and no alpha channel. |
| Visible content | The release candidate and final exported file. | Current UI, honest state, readable copy, and no private or test data. |
| Rendered color | Stable filled areas in the final file and, when useful, the live app. | Important roles remain recognizable after capture, crop, and scaling. |
| Contrast | The actual foreground and background pair in each shown appearance. | The pair meets the chosen criterion and stays readable at listing size. |
| Upload state | App Store Connect after save. | The checked file appears in the right order on the intended version. |
01Freeze the final file and source state
Give the screenshot an identity before checking it: app version or build, appearance, window state, sample data, filename, pixel dimensions, and capture date. Keep the final exported file separate from working crops so the release issue points to one artifact.
Open the release candidate and compare the file with the state it claims to show. Remove debug controls, stale labels, private data, expired pricing, and cursor or notification clutter. Apple's review guidelines require screenshots and other metadata to reflect the current app experience accurately.
If the first one to three screenshots may appear in App Store search results because there is no app preview, make those files understandable at a small size. Apple also recommends considering a Dark Mode screenshot when the app supports it.
02Verify size, type, and alpha separately
Apple currently accepts one to ten screenshots per device size. Screenshot files can be JPEG or PNG, but they cannot contain alpha transparency. For Mac, accepted 16:10 dimensions are 1280 by 800, 1440 by 900, 2560 by 1600, or 2880 by 1800 pixels.
Do not infer those facts from how the image looks in Preview or a browser. Inspect the actual final file. A color picker answers a different question: what a rendered pixel looks like on the screen. It cannot prove that the file has accepted dimensions or no alpha channel.
Upload the exact checked file. Apple notes that screenshots can be rearranged before submission, but changing them after a version is approved requires a new app version. Save the App Store Connect record, then verify the file order and version association rather than treating a successful file selection as proof.
03Sample stable rendered pixels from the final file
The app window and exported screenshot can disagree after scaling, cropping, compression, compositing, or a color-profile conversion. Sample the final file when the question is what buyers will see. Sample the live app as a separate reference when you need to locate where the change entered the workflow.
TeenyColor uses macOS NSColorSampler and converts a picked color to sRGB when that conversion is available. It then formats the rendered value as Hex, lowercase hex, RGB, RGB decimal, HSL, HSB/HSV, SwiftUI Color, UIColor, or CSS rgba. That makes comparisons portable, but it does not recover the source asset's color space or a SwiftUI semantic color name.
Choose stable filled areas rather than antialiased text edges, shadows, gradients, or translucent overlays. Name samples by role and state, such as "release hero accent, dark appearance, final PNG." For a closer source-versus-export workflow, use the image color shift check.
04Check real pairs, not a badge in isolation
Listing screenshots are often displayed smaller than the live app, so a readable label can become weak in the final composition. Sample the actual foreground and background from the exported file, record the pair, and judge the result at the size where people will see it.
WCAG 2.2 uses 4.5:1 for normal text and 3:1 for large-scale text at Level AA. Non-text UI components use a separate 3:1 criterion against adjacent colors. These criteria apply to real pairs and roles, not a color by itself.
TeenyColor's current quick badges calculate the picked color against white and black. They can flag an obvious problem or suggest which neutral backdrop is safer, but they do not test an arbitrary text/background pair. Use a full contrast checker for the actual pair, and review light, dark, selected, disabled, and focus states where they matter.
05Keep one compact release record
Record the final filename, dimensions, type, alpha result, app build, appearance, approved order, and any color or contrast decision. Attach evidence only when it helps another person reproduce the pass. A pile of unnamed hex values is not a release record.
Prerelease screenshots can expose pricing, unreleased features, internal names, test data, license state, or private routes. A local picker keeps pixel sampling on the Mac. Use the issue tracker or review system that already belongs in the release process when evidence needs to leave the machine.
The broader Mac app release QA checklist ties this artifact to the final build, reviewer path, metadata, and URLs. Run TeenyStat's Mac app performance check before capture when build, export, or sync work may still be distorting the machine state.
Mac app screenshot QA checklist
- Name the release candidate and the exact screenshot file.
- Compare its visible state with the app version it represents.
- Verify JPEG or PNG, an accepted Mac size, and no alpha.
- Check copy, controls, private data, and appearance.
- Sample stable roles from the final rendered file.
- Compare the live app only when it answers a source question.
- Test actual foreground and background pairs where readability matters.
- Upload the checked file, save, and confirm order and version.
Sources checked
- TeenyColor feature and limitation claims were checked against the TeenyColor homepage and local Swift source for
NSColorSampler, conditional sRGB conversion, output formats, local history, names, pins, exports, and white/black contrast badges. - Apple App Review Guidelines, especially metadata accuracy in section 2.3.
- Apple Developer: Screenshot specifications.
- Apple Developer: Upload app previews and screenshots.
- Apple Developer: Creating your product page.
- W3C WCAG 2.2: Success Criterion 1.4.3 Contrast (Minimum).
- W3C WCAG 2.2: Success Criterion 1.4.11 Non-text Contrast.
FAQ
How do I check a Mac app screenshot before release?
Freeze the final file and source app state, verify an accepted file type and Mac screenshot size with no alpha, inspect the visible content, sample stable pixels, check real contrast pairs, then confirm the uploaded screenshot is attached to the intended version.
Should I sample colors from the app or the exported screenshot?
Sample both when they answer different questions. The app state records the source UI, while the exported screenshot is the artifact App Store Connect and buyers will receive.
Can TeenyColor approve App Store screenshots?
No. TeenyColor helps collect local color evidence. Use Apple Developer and App Store Connect documentation for screenshot specifications and upload requirements.
Collect the rendered color evidence locally.
teenycolor samples screen colors, copies nine formats, keeps local history, supports names and pins, exports palettes, and shows quick white/black contrast badges. Use separate file inspection for dimensions and alpha.