Quick answer
Apple lets App Store screenshots include text and image overlays, but the underlying image should show the app in use rather than only title art, a login page, or a splash screen. Screens must accurately reflect the current app, disclose featured content that needs an extra purchase, and stay suitable for a public audience. Use fictional account data, material you have rights to, and imagery focused on Apple platforms.
What Apple allows
That gives you room to design. It doesn't give you room to mislead.
I read Apple's current App Review Guidelines, especially the accurate metadata rules, before writing this answer. Apple treats screenshots as metadata. They aren't a separate advertising zone where the product can become more generous, more complete, or less restricted than the app people will download.
The safest test is direct. Can a reviewer open the submitted app and find the experience shown in the screenshot? If they can't, the image needs another look, because a caption may explain a benefit but shouldn't invent a capability. A decorative background may frame the interface, but it shouldn't hide the fact that the pictured screen doesn't exist.
There is creative freedom here. Apple explicitly permits text and image overlays. You can add a caption, point to an input method, or place the interface inside a composed marketing image. The app must remain the evidence, so think of every screenshot as a promise tied to a real screen. That's the clean line.
I read Apple's current App Review Guidelines, especially the accurate metadata rules, before writing this answer. Apple treats screenshots as metadata. They aren't a separate advertising zone where the product can become more generous, more complete, or less restricted than the app people will download.
The safest test is direct. Can a reviewer open the submitted app and find the experience shown in the screenshot? If they can't, the image needs another look, because a caption may explain a benefit but shouldn't invent a capability. A decorative background may frame the interface, but it shouldn't hide the fact that the pictured screen doesn't exist.
There is creative freedom here. Apple explicitly permits text and image overlays. You can add a caption, point to an input method, or place the interface inside a composed marketing image. The app must remain the evidence, so think of every screenshot as a promise tied to a real screen. That's the clean line.
Show the app doing something real
Apple says screenshots should show the app in use, and they shouldn't consist only of title art, a login page, or a splash screen.
That rule answers a common design temptation. A beautiful logo screen isn't enough, because it doesn't tell a shopper what happens after launch. A login form isn't enough either. It proves that the app has an account gate, not that the app solves the problem named in your listing.
Start with a real task. Show the editor editing, the tracker tracking, or the game in play. The exact scene depends on the product, but the screenshot should carry evidence that the core experience exists.
You can still include a branded opening frame, but don't let title art replace the app experience. If the first image is mostly brand, another visible screen should quickly make the product concrete.
Watch staging data too. A screen filled with perfect values can become misleading when those values imply an outcome the app can't reliably produce. Sample content is fine when it is clearly representative and doesn't turn into a performance claim.
Current matters. Apple tells developers to keep metadata aligned with new versions, so replace any old screenshot that points toward a button that moved or disappeared. That isn't merely untidy. The image no longer reflects the app people receive.
The screenshot rejection guide covers file failures and upload errors. This rule sits one level above them. A technically valid file can still be weak metadata when it shows the wrong experience.
That rule answers a common design temptation. A beautiful logo screen isn't enough, because it doesn't tell a shopper what happens after launch. A login form isn't enough either. It proves that the app has an account gate, not that the app solves the problem named in your listing.
Start with a real task. Show the editor editing, the tracker tracking, or the game in play. The exact scene depends on the product, but the screenshot should carry evidence that the core experience exists.
You can still include a branded opening frame, but don't let title art replace the app experience. If the first image is mostly brand, another visible screen should quickly make the product concrete.
Watch staging data too. A screen filled with perfect values can become misleading when those values imply an outcome the app can't reliably produce. Sample content is fine when it is clearly representative and doesn't turn into a performance claim.
Current matters. Apple tells developers to keep metadata aligned with new versions, so replace any old screenshot that points toward a button that moved or disappeared. That isn't merely untidy. The image no longer reflects the app people receive.
The screenshot rejection guide covers file failures and upload errors. This rule sits one level above them. A technically valid file can still be weak metadata when it shows the wrong experience.
Overlays can explain, not replace
Text overlays are allowed. Image overlays are allowed too. Apple even gives examples involving input mechanisms and Apple Pencil, so captions aren't the problem. The question is what the caption claims and whether the underlying app supports it.
A useful caption helps a stranger understand the screen by naming the outcome, clarifying a control, or connecting the interface to a task. It shouldn't announce an award you can't verify, a price that doesn't apply, or a feature that is still being built.
Keep the interface visible. If decorations cover the controls, the screenshot stops showing the app and starts showing a poster. The caption should help the screen communicate, not become the only meaningful content in the image.
Arrows and touch indicators need care. Apple permits overlays that demonstrate input, but the graphic should point to something that really happens. A pointer aimed at a decorative mock control creates a false interaction even if the text beside it is technically true.
Don't simulate operating system messages, permission dialogs, or purchase confirmation in a way that could be mistaken for the real interface. A store image shouldn't trick a viewer into thinking an action already occurred.
The caption writing guide focuses on wording. Compliance comes first. Once the claim is accurate and specific to the pictured screen, you can work on making the line clearer.
A useful caption helps a stranger understand the screen by naming the outcome, clarifying a control, or connecting the interface to a task. It shouldn't announce an award you can't verify, a price that doesn't apply, or a feature that is still being built.
Keep the interface visible. If decorations cover the controls, the screenshot stops showing the app and starts showing a poster. The caption should help the screen communicate, not become the only meaningful content in the image.
Arrows and touch indicators need care. Apple permits overlays that demonstrate input, but the graphic should point to something that really happens. A pointer aimed at a decorative mock control creates a false interaction even if the text beside it is technically true.
Don't simulate operating system messages, permission dialogs, or purchase confirmation in a way that could be mistaken for the real interface. A store image shouldn't trick a viewer into thinking an action already occurred.
The caption writing guide focuses on wording. Compliance comes first. Once the claim is accurate and specific to the pictured screen, you can work on making the line clearer.
Be plain about paid content
Purchases need honest labeling. Apple says that when screenshots or previews feature items, levels, subscriptions, or other content requiring an additional purchase, the listing must clearly indicate that requirement.
Don't show the premium experience as though every install opens directly into it. If a pictured feature needs a subscription, say so in language a shopper can understand. Hiding that fact in the full description doesn't repair a screenshot that implies the feature is included.
Price claims are risky for another reason. Apple's metadata rules say screenshots and previews shouldn't include prices, terms, or descriptions that aren't specific to that metadata type. The guidelines also call out false pricing in misleading marketing, since prices can differ by storefront, tax treatment, or product configuration and make hard coded artwork inaccurate.
Use durable wording. Paid feature or subscription required may be clearer than a number that needs constant maintenance. The exact disclosure should match how your product is sold, so don't use broad copy if a narrower statement is more accurate.
Free trials deserve the same care. A screen showing full access shouldn't imply that access continues without the condition attached to it. State the condition where it can be read.
Check the app after reading the image. If the screenshot says a feature is included, follow the path from install to that feature. Any account gate, purchase gate, region restriction, or hardware need that changes the promise should be considered in the copy.
This isn't about making paid features look smaller; it is about making the offer understandable before someone downloads.
Don't show the premium experience as though every install opens directly into it. If a pictured feature needs a subscription, say so in language a shopper can understand. Hiding that fact in the full description doesn't repair a screenshot that implies the feature is included.
Price claims are risky for another reason. Apple's metadata rules say screenshots and previews shouldn't include prices, terms, or descriptions that aren't specific to that metadata type. The guidelines also call out false pricing in misleading marketing, since prices can differ by storefront, tax treatment, or product configuration and make hard coded artwork inaccurate.
Use durable wording. Paid feature or subscription required may be clearer than a number that needs constant maintenance. The exact disclosure should match how your product is sold, so don't use broad copy if a narrower statement is more accurate.
Free trials deserve the same care. A screen showing full access shouldn't imply that access continues without the condition attached to it. State the condition where it can be read.
Check the app after reading the image. If the screenshot says a feature is included, follow the path from install to that feature. Any account gate, purchase gate, region restriction, or hardware need that changes the promise should be considered in the copy.
This isn't about making paid features look smaller; it is about making the offer understandable before someone downloads.
Keep every screenshot suitable for everyone
App metadata has its own audience rule. Apple says icons, screenshots, and previews should adhere to a 4+ age rating even when the app itself carries a higher rating.
That means a mature app can't simply lift its most graphic scene into the store carousel. Apple gives the example of choosing game images that don't depict a gruesome death or a gun pointed at a specific character. The listing has to remain appropriate for broad public display, and context doesn't rescue a shocking frame. A caption explaining that the scene appears in the game won't change the metadata requirement. Choose a different moment that communicates genre and play without using the most intense image available.
The same principle applies outside games. Sensitive health details, private messages, financial records, and personal profiles can be inappropriate even without violent content. Use controlled sample data and avoid exposing information that belongs to a real person.
Don't place the burden on a tiny disclaimer, because a small warning in the corner won't make an unsuitable central image appropriate. Change the image.
Review thumbnails as public material. They may appear outside the product page, where the shopper hasn't read your description or chosen to see sensitive content. The screenshot needs to make sense in that context too, and a restrained image can still be specific. Show the actual mechanic, interface, or result, just without the material that makes the public listing unsafe or unnecessarily graphic.
That means a mature app can't simply lift its most graphic scene into the store carousel. Apple gives the example of choosing game images that don't depict a gruesome death or a gun pointed at a specific character. The listing has to remain appropriate for broad public display, and context doesn't rescue a shocking frame. A caption explaining that the scene appears in the game won't change the metadata requirement. Choose a different moment that communicates genre and play without using the most intense image available.
The same principle applies outside games. Sensitive health details, private messages, financial records, and personal profiles can be inappropriate even without violent content. Use controlled sample data and avoid exposing information that belongs to a real person.
Don't place the burden on a tiny disclaimer, because a small warning in the corner won't make an unsuitable central image appropriate. Change the image.
Review thumbnails as public material. They may appear outside the product page, where the shopper hasn't read your description or chosen to see sensitive content. The screenshot needs to make sense in that context too, and a restrained image can still be specific. Show the actual mechanic, interface, or result, just without the material that makes the public listing unsafe or unnecessarily graphic.
Protect people and respect ownership
Apple makes the developer responsible for rights to all materials used in app icons, screenshots, and previews. That includes the obvious artwork and the less obvious pieces inside a screen.
Check photographs, illustrations, logos, fonts, album art, map imagery, and user supplied content. Being visible inside your app doesn't automatically mean you have permission to use it in store marketing. The screenshot is a new public use of that material.
Third party logos need a reason and permission, so don't borrow a familiar brand merely to make your product look connected. The same caution applies to testimonials and profile photographs.
Apple also says to display fictional account information instead of data from a real person. Build a controlled account for capture. Give it invented names, safe messages, and content that can't be traced back to an actual customer.
Blur isn't always enough. A profile image, unusual transaction, partial address, or message fragment can still identify somebody. Replacing the source data is cleaner than trying to hide it after capture.
Check small details. Status bars, notifications, recent searches, open document names, and browser tabs can reveal information that the designer never meant to include. Crop only when the crop remains honest. Otherwise, recapture with a clean account and controlled device state.
Clean capture preparation can help with that setup, and privacy is easier before the screenshot exists.
Check photographs, illustrations, logos, fonts, album art, map imagery, and user supplied content. Being visible inside your app doesn't automatically mean you have permission to use it in store marketing. The screenshot is a new public use of that material.
Third party logos need a reason and permission, so don't borrow a familiar brand merely to make your product look connected. The same caution applies to testimonials and profile photographs.
Apple also says to display fictional account information instead of data from a real person. Build a controlled account for capture. Give it invented names, safe messages, and content that can't be traced back to an actual customer.
Blur isn't always enough. A profile image, unusual transaction, partial address, or message fragment can still identify somebody. Replacing the source data is cleaner than trying to hide it after capture.
Check small details. Status bars, notifications, recent searches, open document names, and browser tabs can reveal information that the designer never meant to include. Crop only when the crop remains honest. Otherwise, recapture with a clean account and controlled device state.
Clean capture preparation can help with that setup, and privacy is easier before the screenshot exists.
Keep the platform story focused
Apple's guidelines say App Store metadata should focus on the experience of the Apple platforms the app supports. They also say not to include names, icons, or imagery of other mobile platforms or alternative app marketplaces unless specific approved interactive functionality makes that material relevant.
This affects device mockups. An Android phone frame in an iPhone listing can suggest the wrong platform even when the interface happens to look similar. Use imagery that matches the version people can download from that store.
Don't add another store badge to the corner, because it distracts from the Apple product page and brings an unrelated marketplace into the metadata. A cross platform app can explain its connected experience without turning the screenshot into a collection of store logos.
There are legitimate connected features. An app may control, sync with, or display something from another platform. If that relationship is real and approved, the screenshot should make the interaction clear rather than using the other platform as generic decoration.
Device frames aren't automatically required. A clean interface capture can be honest and effective without one, but if you use a frame, match it to the supported Apple device and keep the interface visible.
PlayMockUp publishes this post and operates the mockup studio, so that link is a disclosed self recommendation. The studio can place a capture inside a device frame and add text, but it can't decide whether your claim, rights, or platform context satisfies Apple's review rules. That judgment stays with the publisher.
This affects device mockups. An Android phone frame in an iPhone listing can suggest the wrong platform even when the interface happens to look similar. Use imagery that matches the version people can download from that store.
Don't add another store badge to the corner, because it distracts from the Apple product page and brings an unrelated marketplace into the metadata. A cross platform app can explain its connected experience without turning the screenshot into a collection of store logos.
There are legitimate connected features. An app may control, sync with, or display something from another platform. If that relationship is real and approved, the screenshot should make the interaction clear rather than using the other platform as generic decoration.
Device frames aren't automatically required. A clean interface capture can be honest and effective without one, but if you use a frame, match it to the supported Apple device and keep the interface visible.
PlayMockUp publishes this post and operates the mockup studio, so that link is a disclosed self recommendation. The studio can place a capture inside a device frame and add text, but it can't decide whether your claim, rights, or platform context satisfies Apple's review rules. That judgment stays with the publisher.
File rules still apply
Content can be honest and still fail at upload because the file has its own gate.
I checked Apple's current screenshot specifications rather than carrying old dimensions into this post. Apple currently accepts from one to ten screenshots in JPEG, JPG, and PNG formats. Images can't include an alpha channel or transparency.
Device sizes have their own accepted dimensions. Use the official table for the platform and display family you are submitting, because a remembered size can become stale. Don't stretch a nearly correct file. Export for the accepted target instead.
Open the exported image after composition. Check the pixel dimensions, format, orientation, and transparency of the file that will actually be uploaded. A correct design canvas doesn't prove the export preset behaved as expected.
Then inspect the content again at the exported size, since text that was readable in the editor may become too small. A crop may remove the control that made a claim truthful. A device frame may hide the edge of a sheet or dialog.
Separate these reviews. First ask whether the image is technically accepted, then ask whether it accurately represents the app and complies with metadata rules. Passing either check doesn't guarantee the other.
The safest file is both valid and boringly honest. It opens, matches an accepted size, contains no transparency, shows a real experience, and makes no claim the app can't support.
I checked Apple's current screenshot specifications rather than carrying old dimensions into this post. Apple currently accepts from one to ten screenshots in JPEG, JPG, and PNG formats. Images can't include an alpha channel or transparency.
Device sizes have their own accepted dimensions. Use the official table for the platform and display family you are submitting, because a remembered size can become stale. Don't stretch a nearly correct file. Export for the accepted target instead.
Open the exported image after composition. Check the pixel dimensions, format, orientation, and transparency of the file that will actually be uploaded. A correct design canvas doesn't prove the export preset behaved as expected.
Then inspect the content again at the exported size, since text that was readable in the editor may become too small. A crop may remove the control that made a claim truthful. A device frame may hide the edge of a sheet or dialog.
Separate these reviews. First ask whether the image is technically accepted, then ask whether it accurately represents the app and complies with metadata rules. Passing either check doesn't guarantee the other.
The safest file is both valid and boringly honest. It opens, matches an accepted size, contains no transparency, shows a real experience, and makes no claim the app can't support.
Use a content review before upload
Put the final screenshots beside the submitted build. Don't review editable files or yesterday's export.
For each image, find the pictured screen in the app, then confirm that the controls, labels, content, and available features match. If the route no longer exists, remove or replace the screenshot.
Read every overlay as a factual claim. Ask what evidence inside the app supports it. If the sentence needs a long explanation to become true, rewrite it more narrowly.
Check paid content. Mark any pictured feature that requires another purchase, a subscription, or a condition the image might hide. The disclosure shouldn't depend on somebody reaching the full description later.
Scan for real data and borrowed material. Replace both at the source. Then check whether every image is suitable for a public audience and focused on the Apple experience.
Remove title art that doesn't show the app doing anything, and remove screenshots that exist only to repeat the logo. Keep the images that help a shopper understand a real task or result.
Now verify the exports against Apple's current table. Don't rely on a template name. Templates can be old, and the uploaded file is what App Store Connect reads.
One independent review is useful. Give the set to somebody who knows the app but didn't design the screenshots. Ask them to identify every promise and find it in the build. They don't need to like the colors. They need to catch the claim you stopped noticing.
For each image, find the pictured screen in the app, then confirm that the controls, labels, content, and available features match. If the route no longer exists, remove or replace the screenshot.
Read every overlay as a factual claim. Ask what evidence inside the app supports it. If the sentence needs a long explanation to become true, rewrite it more narrowly.
Check paid content. Mark any pictured feature that requires another purchase, a subscription, or a condition the image might hide. The disclosure shouldn't depend on somebody reaching the full description later.
Scan for real data and borrowed material. Replace both at the source. Then check whether every image is suitable for a public audience and focused on the Apple experience.
Remove title art that doesn't show the app doing anything, and remove screenshots that exist only to repeat the logo. Keep the images that help a shopper understand a real task or result.
Now verify the exports against Apple's current table. Don't rely on a template name. Templates can be old, and the uploaded file is what App Store Connect reads.
One independent review is useful. Give the set to somebody who knows the app but didn't design the screenshots. Ask them to identify every promise and find it in the build. They don't need to like the colors. They need to catch the claim you stopped noticing.
Frequently asked questions
Can App Store screenshots contain text?
Yes. Apple permits text and image overlays, but the screenshot should still show the app in use and every claim should accurately describe the pictured experience.
Can an App Store screenshot show only a login page?
Apple says screenshots should show the app in use and not merely a login page, title art, or splash screen. Show a real task or result beyond the gate.
Can I show subscription features in screenshots?
Yes, but Apple requires the listing to make clear when featured content or functionality needs an additional purchase. The screenshot shouldn't imply that paid access is included for everyone.
Can screenshots include customer data?
Use fictional account information rather than data from a real person. A controlled capture account is safer than trying to blur names, messages, or payment details afterward.
Can I use an Android phone frame in App Store screenshots?
Avoid it unless another platform is relevant to specific approved functionality. Apple says metadata should focus on supported Apple platforms, so use the correct device context and review [device frame choices](/blog/device-frames-for-app-mockups) before export.
Build the mockup in your browser.
Drop a screenshot into a real device frame and export at the exact store size — free, no signup.