Dark Mode App Store Screenshots

Dark mode App Store screenshots are a choice of which interface you show, not a second file you can stack on top of the first. App Store Connect keeps one screenshot set for each device size in each localization. A true-black notes app and a paper-white notes app cannot both occupy that slot. If you upload the dark set, the light set is gone from the live page until you replace it.

The first three frames are what search shows. Slots further down are the product page. Read how the first three screenshots work before you spend the opening on a theme toggle. Caption rules live in App Store screenshot text. If your glass, blur, and type are the thing you are selling, pair this with Liquid Glass screenshots.

One slot holds one appearance

People ask for a light set and a dark set because phones have both. The store listing does not. For a given iPhone size and a given language, you upload one ordered set of screenshots. There is no light/dark switch on the product page that swaps your images when the shopper’s phone is in dark mode. The pixels you upload are the pixels they see.

That limit is per localization as well as per device size. Your English (U.S.) iPhone set can be dark while a Japanese set is light, if that is an honest picture of each build. It cannot be both inside English (U.S.). Replacing a screenshot replaces it. There is no hidden second gallery waiting for night mode.

Show the interface a new user opens

Pick the appearance that matches the product, not the appearance that looks fashionable in a mockup. If the app launches in dark mode and the user has to dig through settings to find a light theme, the dark screenshots are the honest ones. If the app follows the system and your screenshots were captured while the simulator was forced into black, say so in your own notes and then decide which state a first launch actually shows.

Guideline 2.3 says customers should know what they are getting, and that screenshots should reflect the app’s core experience. A white marketing frame wrapped around an app that is black in the hand is a mismatch. So is a black marketing frame wrapped around an app that opens on a white page. The theme is part of the product. Treat it that way.

Worked example: a notes app with a true-black theme

Take a notes app whose editor is true black, not dark gray. The ink is off-white. Links are a single amber. The first screen after launch is a list of notes on that black ground. A paper-white theme exists, but it is off unless the user turns it on. The live screenshot set should be the black editor. Uploading the white theme as the default would advertise a product the binary does not open into.

Frame one shows the note list with a short caption about finding a note fast. Frame two shows the editor with the keyboard down so the black page and the type are the picture. Frame three shows search, because that is the job, not a settings pane with a theme switch. The white theme can wait for a test. It should not be the picture of the app.

Ship the true-black interface as the live set, and use a product page test if you want data on the white theme.

Keep type readable on black

Black screenshots fail in a specific way. Designers drop the caption to a medium gray so it feels soft, then view the file at full size on a bright monitor. On a phone, in search, that gray disappears. The note text inside the app has the same problem if you screenshot a long document with thin type. Capture a short note. Use a caption color that still reads when you shrink the file until it is about the width of a search result.

True black also punches holes in busy backgrounds. If you put a device frame, a gradient, and a caption around the editor, you can end up with three layers of black and no edge. Give the caption its own quiet band, or put it on a solid strip that is not the same black as the app. The UI has to stay the subject. A frame is optional decoration, and it still has to leave the editor legible. Pixel size rules are in the screenshot sizes guide, not something a dark theme gets to bend.

Test the other theme instead of uploading it twice

If you genuinely do not know which theme earns the install, run Product Page Optimization. The original can stay true black. A treatment can be the paper-white set, or a black set with a different first caption. Apple lets a test include up to three treatments plus the original. Change the theme, or change the caption. Do not change both and then pretend you learned which one mattered.

The treatment has to be the same device size and the same honest UI. Do not build a white mock that the app cannot display. Do not reuse an iPhone capture on an iPad canvas. When the test ends, put the winner in the live slot and remove the loser. Leaving both in a folder on your desktop is fine. Leaving both in the slot is not possible.

Order the dark set like a product, not a mood board

A black theme is not a story. The story is still the job: capture a thought, find it later, keep the page quiet. Screenshot order past the first three is where proof and objections go. In the notes example, slot four can show a pinned note and a search hit together, which is proof the list is usable. Slot five can show export or lock if those are real and people worry about losing text. Do not spend slot four on a second angle of the same empty editor.

AppGrowthKit is useful here when you need the black set and the white treatment exported at the same pixel size, with captions in the same place, so the test compares theme rather than crop. One workflow, two appearances, one slot live.