How to Prepare Demo Data for App Store Screenshots

Start with an account that cannot expose a customer

Create a dedicated account or local demo profile for the version of the app you plan to show. Apple’s screen-content guidelines say to display fictional account information instead of data from a real person. That principle should extend beyond the profile name: a renamed customer account may still contain their messages, photos, locations, or records.

Keep the demo environment separate from live records. If the app syncs contacts, calendars, cloud files, or other connected services, leave those connections off unless you can populate them with safe fictional content. Do not copy production data and assume that blurring the most obvious name will catch every identifying detail.

• Use a fictional display name and profile details; check whether an email address, handle, avatar, or account identifier appears anywhere in the views you will capture.
• Enter records from scratch, including any titles, notes, images, and dates needed to make the intended screens understandable.
• Open each intended view in the demo account before capture. A safe home screen does not guarantee that a detail view, search result, or generated output is safe.

Build a small example the app can actually produce

An empty dashboard may be accurate for a new account, but it often says little about what someone can do after setup. Add enough sample data to show a normal use case, with labels, quantities, and dates that agree across screens. Apple advises using images captured from the app’s UI to communicate the experience, while Google Play says screenshots must demonstrate the actual in-app experience. Populate the app first; do not paint extra results into the capture later.

Consider a hypothetical meal-planning app whose new weekly plan is empty. Assume the current app lets someone add meals with ingredients and generate a shopping list from that plan. In a fresh demo account named “Demo Cook,” add oatmeal with oats and milk, tomato pasta with pasta and tomatoes, and bean tacos with tortillas and beans. Use the app’s normal controls to place those meals in the same week, then generate the list. The resulting example should show those six ingredients—not unrelated groceries—and the plan and list should refer to the same week.

Capture the populated plan and generated list only if the app genuinely produces both views. If it cannot generate a list, show the populated plan without suggesting otherwise. Keep sample portions and totals modest enough to make sense together; a dramatic number may look attractive in artwork but can turn an illustrative state into an implied performance claim.

Check privacy and implied claims before capturing

Review the device and every visible part of the app, not just the data you deliberately entered. Google Play’s metadata policy includes screenshots among the assets that must not be misleading. A fictional chart or success message can still misrepresent the product if its numbers, badge, or wording suggest an outcome users cannot obtain.

• Notifications and overlays: clear banners, lock-screen previews, incoming calls, and other interruptions before capture. Recheck the saved image in case one appeared at the last moment.
• Identifiers and third-party content: inspect names, addresses, account IDs, avatars, maps, photos, and shared content. Replace anything you do not intend to publish or do not have the right to show.
• Dates and consistency: check that the selected week, entries, generated list, and device display agree. Refresh sample data if a previously useful screen now shows an expired event or an implausible timeline.
• Claims: read totals, badges, recommendations, and success messages as a new user would. If a screen appears to promise an automated result or achievement the available app does not provide, choose a different state rather than explaining away the mismatch in a caption.

Save clean captures before designing the artwork

Capture each approved state from the app, then inspect the saved images at full size. Look again for cropped names, tiny identifiers, stale dates, or a notification that slipped into one frame. Keep the unedited captures so you can compare later artwork against the UI you actually showed.

Once the captures pass that review, they are ready for the image-design stage. If you are considering Minimalist Screens for a store image kit, bring those prepared captures to the artwork workflow; do not leave demo-data creation or screen capture for that stage. Choose and order the finished images separately. The decision here is whether each underlying app state is safe, coherent, and truthful.