How to design screenshot sets for companion-device apps

A lot of app store screenshot advice assumes one simple story: one device, one user flow, one screen sequence.

That breaks down fast for companion-device apps.

If your product depends on a phone plus a smartwatch, a phone plus a car display, a phone plus glasses, or a phone plus another Android device, the listing has a harder job. Your screenshots need to explain not only what the app looks like, but how the product works across devices without overwhelming a first-time visitor.

That challenge matters more now because multi-device development is getting easier. In April 2026, Google highlighted new Android Emulator support for zero-configuration peer-to-peer connectivity across virtual devices, making it simpler to test flows between phones, watches, automotive surfaces, glasses, and other Android form factors. As teams ship more connected experiences, screenshot systems have to catch up.

Mockupper is useful in this workflow because it helps teams turn raw product screens into cleaner, repeatable store assets after they decide how the multi-device story should be presented.

Why companion-device screenshot sets fail so often

Most weak screenshot sets for connected apps make one of three mistakes:

• they show too many devices too early,
• they never explain which device starts the workflow,
• or they treat the companion experience like a separate product instead of part of one clear user outcome.

A user opening your App Store or Google Play listing is usually asking a simple question first: what does this app help me do?

If the first screenshot answers with a hardware diagram, a brand slogan, or a split-screen collage of five surfaces, comprehension drops immediately.

For connected apps, clarity is more important than visual ambition.

Start with the primary device, not the full ecosystem

The first screenshot should usually anchor the experience in the primary device.

That means showing the screen where the user understands the main value fastest. In many cases, that is still the phone.

Examples:

• For a running app with watch support, lead with the phone view that shows planning, insights, or progress.
• For a car companion flow, lead with the phone screen that sets up navigation, playback, or trip control.
• For smart glasses or XR pairing, lead with the phone setup or control surface that makes the use case legible.

The companion device should enter the sequence only after the core promise is clear.

A good rule is this: screenshot one explains the product. Screenshot two or three explains how the second device expands the experience.

Show the handoff, not just the second screen

A common mistake is dropping a watch screen or vehicle screen into the sequence without context.

That creates a visual jump. Users see a different interface, but they do not understand why it matters.

Instead, dedicate one screenshot to the handoff moment:

• start on phone,
• continue on companion device,
• finish with the outcome.

That structure is much easier to understand than a random collection of surfaces.

For example, a connected fitness workflow can be framed as:

1. plan or start from the phone,
2. track live from the watch,
3. review results back on the phone.

A connected driving or audio workflow can be framed as:

1. configure on the phone,
2. control or continue in the car,
3. return to the phone for history, settings, or follow-up actions.

The sequence should explain movement between surfaces, not just prove that multiple surfaces exist.

Reduce device count per frame

Companion-device listings become hard to read when every screenshot contains two or three hardware frames at once.

That usually happens because teams are afraid users will miss the connected-device story.

In practice, overloading the frame makes the story harder to understand.

A cleaner system is:

• one dominant device per screenshot,
• one secondary cue only when necessary,
• and one message per frame.

If you need to show a phone paired with a watch, the phone should still remain the dominant element unless the screenshot is explicitly about the watch moment. If you need to show an in-car continuation, the phone can appear as setup context, but the screenshot should still communicate one action, not a collage.

Separate setup screens from payoff screens

Connected apps often spend too much visual real estate on pairing.

Pairing matters, but it is rarely the best selling point.

Your screenshot set should distinguish between:

• setup screens, which prove the workflow is easy to enable,
• and payoff screens, which prove the workflow is worth using.

Most companion-device apps should include both, but in different proportions.

A useful sequence looks like this:

1. core value on the main device,
2. companion extension or handoff,
3. live-use payoff,
4. convenience or automation proof,
5. trust, summary, or results.

This keeps the listing focused on benefits instead of technical wiring.

Design separate copy roles for each device surface

Multi-device screenshot sets get repetitive when every frame uses the same generic headline style.

Instead, give each surface a different copy job:

• the phone frame introduces the main promise,
• the companion frame explains context or continuity,
• the final frame reinforces the result.

That avoids duplicate messages like:

• “Track your health anywhere”
• “Use it on your watch too”
• “Stay connected everywhere”

Those lines sound broad but say almost nothing.

A stronger approach is more specific:

• screenshot one: what the user starts,
• screenshot two: where the workflow continues,
• screenshot three: what the user gains.

Even short overlay copy becomes clearer when each device has a distinct role.

Plan device-specific variants without rewriting the story

Apple’s App Store Connect guidance is useful here. If the same UI applies across multiple device sizes and localizations, you can often provide only the highest required resolution and let the system scale down. But when a device family needs a truly different presentation, custom assets can be added through Media Manager.

That matters for companion-device apps because the story may stay stable while the framing changes.

For example:

• your iPhone screenshots may lead with setup and control,
• your iPad set may emphasize dashboard depth,
• and your localized variants may keep the same sequence while adjusting copy density.

The message architecture should remain consistent even when the visual treatment changes across device families.

Use testing environments to map screenshot coverage

Google’s recent Android Emulator update matters beyond QA. It is also a reminder that more teams can now test connected-device flows earlier and more reliably.

That creates a useful screenshot habit: build a coverage map while testing.

For each screenshot candidate, note:

• which device starts the action,
• which device receives the handoff,
• which benefit the frame proves,
• and whether the frame is setup, continuity, or payoff.

This prevents two common problems:

• over-indexing on setup screens because they were easiest to capture,
• and forgetting to represent the real cross-device moment that makes the product interesting.

Keep the visual system reusable when flows evolve

Connected apps change quickly.

Pairing gets simplified. Watch flows get deeper. Car surfaces add a new control state. A glasses companion experience moves from experimental to core.

If the screenshot system is built from one-off compositions, every product change becomes a redesign project.

A better workflow keeps three things reusable:

• the message order,
• the role of each screenshot,
• and the visual treatment rules for primary versus companion surfaces.

That is where Mockupper helps operationally. Once the team knows which frames belong in the sequence, it becomes easier to regenerate polished assets from fresh raw screens without rebuilding the whole listing from zero.

A simple framework for connected-app screenshot sequences

If your app depends on more than one surface, this five-part structure is a good starting point:

1. Primary device promise — what the app helps the user do.
2. Companion handoff — where the second device enters.
3. Live-use proof — how the connected experience works in motion.
4. Convenience or automation — why the second surface saves effort.
5. Outcome or trust frame — what the user gets back from the full system.

That framework is flexible enough for:

• phone and watch apps,
• phone and car experiences,
• phone and tablet workflows,
• and phone plus glasses or XR companion flows.

The exact devices can change. The need for clarity does not.

Conclusion

Companion-device apps do not need busier screenshot sets. They need more disciplined ones.

The best connected-app listings explain the primary value first, introduce the second device at the right moment, and show the handoff as part of one coherent user story. When teams structure the sequence that way, multi-device complexity becomes easier to market instead of harder to understand.

If you want a faster way to turn raw product screens into cleaner, reusable store visuals, explore Mockupper.

Sources

• Android Developers Blog, Test Multi-Device Interactions with the Android Emulator
• Apple Developer, Upload app previews and screenshots