Before designing App Store screenshots, put each proposed caption beside the screen that is supposed to support it. A still image can show a setting, an interaction state or a recorded result. It cannot establish that an alarm always rings, a detector never misses, or a routine changes someone's life.
I make Squatti, the NaguBuilds alarm app currently listed in the US App Store as Squat Alarm: Stop Snoozing. Below is a caption-review worksheet using proposed examples for its public features. These are planning exercises, not a report of newly captured screenshots or a conversion experiment.
Apple's product-page guidance recommends screenshots captured from the app's interface that communicate its experience. Its review guidelines also require accurate metadata, an app shown in use, and clear purchase context when featured items require an additional purchase.
Separate the visible screen from the larger claim
Take a proposed screenshot of an alarm editor. It may show a selected time and repeat days. That supports a caption describing those controls. It does not prove the alarm fired later, at the intended volume, under every device condition.
A camera counter can show a counted repetition. A single frame cannot establish detection accuracy across rooms, lighting or body positions. A progress screen can display completed mornings; it cannot prove the app will make every buyer consistent.
Explain the visible feature in the caption. Put behavior that needs a test in a separate verification record, and keep its wording within the conditions actually checked. The alarm release checklist covers that device-testing task.
Make one claim record per proposed image
Copy these fields into your working document:
- Reader's question:
- Proposed caption:
- Released screen and state to capture:
- What the image visibly demonstrates:
- What the caption implies beyond the image:
- Supporting evidence for that extra claim:
- Required permission, plan or other condition:
- Build, device and locale used for the capture:
- Decision: keep, narrow, recapture or hold:
Fill the record before making a polished composition. If the required state exists only in a design file, leave the capture field unverified. Do not let a realistic mockup become the evidence that a feature ships.
Three proposed Squatti caption decisions
The public listing describes choosing an alarm time, days and squat target, a front-camera challenge, and progress tracking. That supports planning the following images; it does not replace checking the actual build and capture.
Alarm setup
Reader question: Can I choose the task?
Proposed caption: "Choose your alarm time and squat target."
Capture needed: the released editor with those controls readable. Verify the target shown is selectable in that build. Hold a caption such as "Never oversleep again": the editor cannot support that outcome.
Camera challenge
Reader question: How does the app count the task?
Proposed caption: "Follow the squat counter on your iPhone."
Capture needed: the released challenge with the counter visible, using an appropriate demonstration subject who has agreed to appear. Record the camera setup separately. A privacy claim about camera processing needs its own evidence; a screenshot alone cannot prove where data goes. Squatti's public product page describes its on-device camera processing and separate analytics boundary.
Progress
Reader question: What can I review afterward?
Proposed caption: "See your completed mornings."
Capture needed: the released progress view with representative demonstration data. Do not present a staged streak as a customer result or as evidence that the app creates a habit. If the caption promises a particular metric, make sure that metric is visible and available in the released version.
Review the finished image, including its conditions
Squatti currently requires Pro, according to its public product page. The screenshot set needs clear purchase context; a working feature shown in an image should not leave readers assuming it is included without that subscription. Recheck the current offer when preparing actual assets.
Read each exported image at a realistic viewing size. Can someone see the screen detail supporting the caption? Has a crop hidden a required setting? Does the localized caption still make the same claim?
Use Squatti's current store listing as the public feature reference, then complete the capture and evidence fields for the exact version you are preparing.