Get a clean 9:41 status bar in every App Store screenshot

There is no App Store rule that says your status bar must read 9:41. What there is, is a very obvious difference between a set where every panel shows 9:41, full signal and a full battery, and a set where panel one says 14:37 with 23% battery and panel four says 14:52 with 19%.

The second one tells a browsing user these are screenshots someone took on their own phone over a coffee break. The first one says this is marketing material. Both are honest; only one looks considered.

The command

The Simulator has this built in. It is simctl status_bar, and it persists until you clear it or the device reboots:

xcrun simctl status_bar booted override \
  --time "9:41" \
  --dataNetwork wifi \
  --wifiMode active \
  --wifiBars 3 \
  --cellularMode active \
  --cellularBars 4 \
  --batteryState charged \
  --batteryLevel 100

Then capture as normal:

xcrun simctl io booted screenshot panel-01.png

To put it back:

xcrun simctl status_bar booted clear

--operatorName is worth knowing about too. It sets the carrier label, and --operatorName '' removes it entirely, which is usually what you want — a real carrier name in a screenshot is a small, free distraction.

Why 9:41 specifically

It is the time Apple has shown on iPhone marketing material since the original keynote, and it is the Simulator's own default in many contexts. Using it costs nothing and makes your set look like it belongs next to Apple's. Using a different consistent time is equally fine. Using an inconsistent time is the only actual mistake.

What this does not fix

1. Real device captures. simctl only drives the Simulator. On a physical phone you have no override, which is why the QuickTime trick exists (below).
2. A reboot. Overrides do not survive one. If you are scripting a capture run, set the override after boot and before the first screenshot, every time.
3. Reinstalling the app. That does not clear the status bar, but it does reset your app's own preferences — so any first-run overlay flags you set need re-applying.

Capturing from a real device

Sometimes you need the real thing: a feature that does not work in the Simulator, hardware camera output, or performance you cannot fake. There is no status-bar override, but there is a long-standing workaround:

Plug the phone into a Mac, open QuickTime Player, choose File → New Movie Recording, and select the iPhone as the camera source. iOS switches the device's status bar to a clean marketing state — full bars, full battery, and 9:41 — for as long as it is mirroring. Screenshot the QuickTime window, or take screenshots on the device itself while it is connected.

It is a genuinely odd trick and it has worked for years.

The mistake that actually costs you

A clean status bar is polish. It is worth ten minutes and no more. What is worth considerably more is the thing people do while chasing it: they capture a clean, consistent, beautifully uniform set of screenshots of an empty app.

An honest screenshot of an empty list sells nothing. Seeding believable data before you capture is the single biggest quality lever in the entire process, and it is the one most capture guides skip because it is work rather than a command you can paste.

A minimal capture loop

Putting it together, the shape of a scripted run:

UDID=booted
BUNDLE=com.example.app
OUT=./shots

xcrun simctl status_bar $UDID override \
  --time "9:41" --dataNetwork wifi --wifiBars 3 \
  --cellularBars 4 --batteryState charged --batteryLevel 100 \
  --operatorName ''

shot () {   # shot <name> <env>
  xcrun simctl terminate $UDID $BUNDLE 2>/dev/null
  env $2 xcrun simctl launch $UDID $BUNDLE >/dev/null
  sleep 2
  xcrun simctl io $UDID screenshot "$OUT/$1.png"
}

shot 01-home  SIMCTL_CHILD_APP_SCREEN=home
shot 02-search SIMCTL_CHILD_APP_SCREEN=search

The SIMCTL_CHILD_ prefix passes an environment variable through to the app, which is how you drive it to a specific screen without synthetic taps. Adding a small launch-argument hook to your app for this is far more reliable than trying to automate the UI, and it is the difference between a capture run you can repeat and one you babysit.

Then look at every frame. The failure mode is never a script that errored — it is a technically successful screenshot of an empty list behind a permission dialog.