Georgii EmelianovEngineering

Why App Demo Videos Go Stale (and How to Regenerate Them with the iOS Simulator)

App demo videos age faster than your release notes.

Old coastal structures in foreground and a small lighthouse on a distant breakwater symbolizing outdated app demo videos and fresh previews.

App demo videos age faster than your release notes.

UI tweaks, new device sizes, and updated messaging can make last month’s App Store preview feel wrong for today’s build. The good news: Apple’s tools already assume you’ll regenerate previews often.

This step-by-step tutorial shows you how to:

  • Understand why app demo videos go stale
  • Install and manage the iOS Simulator via Xcode
  • Keep device runtimes up to date
  • Spin up realistic test devices for your target users
  • Set yourself up for fast, repeatable preview regeneration

If you want the broader strategy story (“Can an AI agent actually make your demo video?”), pair this tutorial with our pillar guide: Can an AI Agent Make Your App Demo Video?.

Why App Demo Videos Go Stale So Fast

App demo videos are not one-and-done assets.

Apple treats App Store previews as device- and locale-specific creatives that autoplay on product pages and even in search results. That makes them powerful and fragile.

4 reasons your demo video ages quickly

  1. Device-specific framing
    • Apple supports multiple device sizes and aspect ratios.
    • A video framed for one iPhone can look off on a newer model.
  2. UI and flow changes
    • Every tweak to navigation, onboarding, or pricing screens can invalidate your existing preview.
    • Apple explicitly recommends avoiding seasonal or timely references because references age the video quickly.
  3. Locale-specific content
    • Up to three previews per language means more assets to keep aligned.
    • New locales or copy changes require fresh captures.
  4. Conversion performance
    • AppTweak found the average US App Store conversion rate around 8.56% in 2025, with huge spread by category (e.g., 52.8% for food & drink vs 9.8% for social networking).
    • That gap makes creative refreshes and testing worth real money.

In other words: your demo will go stale. The real question is how easily you can regenerate it.

Reely’s stance: your code and simulator should be the source of truth. If your agent can ship the feature, it should also help rebuild the reel.

Overview: Regenerating App Demo Videos from the Simulator

Before we dive into the steps, let’s define the workflow you’re building toward.

Goal: be able to auto-generate app demo reels after each successful build, using simulator recordings that map directly to Apple’s App Store preview specs.

At a high level, you want:

  • Xcode installed with the iOS Simulator
  • The right device runtimes downloaded (your target hardware + OS versions)
  • A repeatable way to spin up matching simulator devices
  • A capture pipeline (manual or automated) that records on-device UI only
  • A motion / editorial layer that formats everything for App Store or launch promos

Reely sits in that last step—turning simulator footage and code into feature teasers and full launch promos—but all of it depends on your simulator foundation.

Let’s build that foundation.

Step 1: Install Xcode and the iOS Simulator

To generate App Store-ready previews, you need Apple’s own tools.

Prerequisites

  • macOS with enough disk space (Xcode + runtimes easily cross 30–40 GB)
  • An Apple ID
  • A stable internet connection (runtimes are large downloads)

1.1 Download Xcode

  1. Open the Mac App Store.
  2. Search for Xcode.
  3. Click Get or Update.
  4. Once installed, launch Xcode at least once to complete setup.

Alternatively, you can download specific versions from developer.apple.com if you need older toolchains.

1.2 Confirm the iOS Simulator is installed

  1. Open Xcode.
  2. From the menu bar, choose Xcode → Open Developer Tool → Simulator.
  3. The iOS Simulator app should launch with a default device.

If you see a simulated iPhone home screen, you’re ready to manage runtimes.

Step 2: Manage Device Runtimes in Xcode

Runtimes are what make specific simulated devices possible.

A runtime corresponds to:

  • An OS version (e.g., iOS 17.5)
  • A device family (e.g., iPhone, iPad)

Keeping runtimes current is the key to generating previews that match your real users’ devices.

2.1 Open Components in Xcode

  1. In Xcode, go to Settings… (or Preferences… on older versions).
  2. Click the Components tab.
  3. You’ll see a list of Simulators with OS versions and download buttons.

Apple notes that:

  • Older runtimes are excluded by default but can be downloaded on demand.
  • Xcode can automatically keep runtimes up to date if you enable it.

2.2 Install the runtimes you actually need

To avoid bloat, pick runtimes that map to your buyer devices.

Consider:

  • Latest stable iOS – usually your primary preview target.
  • One prior major iOS – helpful if your audience lags updates.
  • Special devices – iPad, or specific models if your UX depends on size.

Steps:

  1. Under Simulators, click the download icon next to the iOS versions you need.
  2. Wait for the downloads to complete. They can be several GB each.
  3. Confirm they appear as Installed.

2.3 Keep Xcode simulators up to date

You don’t want your preview workflow blocked by outdated runtimes.

Options:

  • Enable Xcode’s automatic updates for components.
  • Periodically check Xcode → Settings → Components for new iOS releases.
  • Align your preview updates with your App Store release cadence.

Step 3: Spin Up Targeted Test Devices (Device Hub)

Your app previews should reflect the devices your users actually hold.

Apple’s Device Hub helps you spin up specific simulator configurations quickly.

3.1 Open Device Hub

  1. In Xcode, go to Window → Devices and Simulators.
    (In some versions this is labeled Device Hub.)
  2. Switch to the Simulators tab.

You’ll see a list of existing simulator devices.

3.2 Add a new simulator matching your target users

Think about your audience:

  • Are they primarily iPhone 14/15 users?
  • Do you support iPhone SE or small screens?
  • Is your product iPad-first?

To create a simulator:

  1. Click the + button at the bottom of the device list.
  2. Choose a device type (e.g., iPhone 15 Pro, iPhone SE, iPad Pro 11”).
  3. Select the OS version (from the runtimes you installed).
    • If your runtime isn’t available, go back to Step 2 and install it.
  4. Name the simulator clearly, e.g., iPhone 15 Pro – iOS 17.5 – EN-US.
  5. Click Create.

Repeat this for the 2–3 core devices that best represent your users.

3.3 Organize simulators by market

If you support multiple locales, create simulators labeled per market, e.g.:

  • iPhone 15 – iOS 17 – EN-US
  • iPhone 15 – iOS 17 – DE-DE
  • iPhone 15 – iOS 17 – JA-JP

This makes it easier to:

  • Test localized copy and layouts
  • Capture locale-specific previews (Apple allows up to three per language)

Step 4: Launch and Record from the iOS Simulator

Apple’s guidelines require previews to:

  • Be captured on device (sim or physical)
  • Stay within the app itself
  • Avoid showing people using the device

Simulator recordings let you regenerate previews quickly when flows change.

4.1 Run your app in the target simulator

  1. In Xcode, choose your app scheme.
  2. Select the target simulator from the device menu, e.g., iPhone 15 Pro.
  3. Press Run (⌘R).
  4. Wait for your app to launch and stabilize.

4.2 Record simulator footage manually (baseline method)

For a pure Xcode workflow:

  1. In the Simulator app, go to File → New Screen Recording (or use the toolbar).
  2. Confirm the recording indicator appears.
  3. Drive through your feature flow:
    • Clean, intentional taps and swipes
    • Avoid hesitation or dead air
    • Follow the story Apple recommends: a cohesive flow per preview
  4. Stop the recording via File → Stop Screen Recording or the toolbar.
  5. Save the file somewhere predictable, e.g., Recordings/AppStore/2026-08-22.

This gives you a raw H.264 screen recording you can then trim and format.

4.3 Use a dedicated tool for polished app demo reels

Manual recordings are fine, but they get painful when your app updates weekly.

You can layer a tool like Reely onto your simulator pipeline to:

  • Auto-control the app flow via an AI agent and MCP tool
  • Recreate app flows in the iOS Simulator after each build
  • Record, auto-cut dead air, and apply editorial pacing tuned for product demos
  • Generate:
    • 10–20s feature teasers
    • 30–60s full launch promos
  • Output multiple aspect ratios and 4K masters from the same run

This is where “promo from code in minutes” becomes real: your agent builds the feature, then Reely turns that same source into a launch-ready reel.

For a deeper dive on agent-driven workflows, see our companion guide Can an AI Agent Make Your App Demo Video?.

Step 5: Match Apple’s App Store Preview Specs

Your regenerated videos still have to meet Apple’s requirements.

Key App Store preview specs (at the time of writing):

  • Length: 15–30 seconds
  • Max file size: 500 MB
  • Codec: H.264 or ProRes 422 (HQ)
  • Frame rate: 30 fps
  • Poster frame: default at 5 seconds (but configurable via API)
  • Count: up to three previews per device size and language

Apple also recommends:

  • Using native resolution and keeping content inside the app
  • Simple transitions rather than flashy effects
  • Showing something new in each preview to tell a cohesive story

When you regenerate:

  • Trim your recordings down to 15–30 seconds per storyline
  • Ensure no out-of-app content appears (no external browser, no OS UI)
  • Export per required device size and locale

A tool like Reely can enforce these constraints for you—ensuring pacing, typography, device framing, and assets stay within Apple’s spec while still producing reels suitable for Product Hunt, X, and Shorts.

Step 6: Automate Preview Regeneration with App Store Connect

Manually uploading every new preview doesn’t scale.

Apple’s App Store Connect API lets you:

  • Create app preview sets
  • Upload and download preview assets
  • Commit uploads
  • Set poster-frame timestamps

Apple even provides sample Python code for uploads, which makes CI-style regeneration realistic.

6.1 Plan your CI flow

A typical flow looks like this:

  1. Build succeeds in your CI pipeline.
  2. Agent or script launches iOS Simulator, runs key flows, and records.
  3. Reely (or similar) consumes:
    • Simulator recordings
    • Code / spec
    • Brand theme from your app
  4. Reely outputs:
    • App Store-spec previews
    • Social / launch promos
  5. CI job uses App Store Connect API to upload new previews.
  6. Previews are associated with the correct language and device sizes.

By pairing Xcode’s simulator management with API-driven uploads, preview refreshes become just another artifact of your build.

6.2 Respect Apple’s processing window

Apple notes that preview uploads may take up to 24 hours to process.

Plan accordingly:

  • For launch days, upload previews at least a day ahead.
  • For frequent releases, regenerate and upload previews as part of your beta → production promotion cycle.

Step 7: Keep Your Demo Videos Fresh (Without Burning Time)

Once your simulator and automation are in place, fresh demos become easy.

Practical habits:

  • Align with feature releases: regenerate previews whenever you ship a major UX change.
  • Check for drift: compare live app flows against existing previews every few sprints.
  • Use product page optimization: Apple supports testing up to three alternate product pages (including previews)—use this to test different stories.
  • Protect your time: rely on tools that integrate with your existing dev workflow, not separate timelines.

Reely is built around this philosophy:

  • Native macOS app, local rendering (no cloud uploads for your builds)
  • Deep iOS Simulator integration
  • Agent-first MCP tool so your coding agent can go from “build feature” → “build demo reel” in the same workflow
  • Studio-level motion systems without touching a traditional NLE

Your app is the brand. Your simulator is the camera. The rest should be automated.

FAQ: App Demo Videos, Simulators, and Regeneration

Why do App Store preview videos go stale so quickly?

They’re tied tightly to your app’s UI, flows, and device framing. Any change to navigation, layout, copy, or supported devices can make a preview feel inaccurate. Apple also advises against timely or seasonal content, because that ages fast—yet many apps still include it.

Can I use the iOS Simulator for all my app demo recordings?

You can use the simulator for most flows, especially standard UI interactions. Apple does note that simulators don’t replicate all hardware features (e.g., camera, sensors, some performance characteristics), so for those you may still need physical-device captures. For the majority of UI-driven previews, simulator recordings are sufficient and far easier to regenerate.

How many App Store preview videos can I have per app?

Apple currently allows up to three app previews per language, and up to three per supported device size. Each preview is 15–30 seconds and autoplayed on your product page and in some search results.

How often should I refresh my app demo videos?

At minimum, refresh when:

  • You ship a major visual redesign
  • You change onboarding, pricing, or a core feature flow
  • You add or remove key features highlighted in the current preview

Many teams align refreshes with major version releases or quarterly marketing pushes. With a simulator-first workflow and tools like Reely, you can refresh much more often without blowing up your schedule.

How does Reely fit into an iOS Simulator-based workflow?

Reely plugs into your existing macOS + Xcode setup. It uses the iOS Simulator as the camera, lets your AI agent reconstruct app flows, and then:

  • Records and trims footage automatically
  • Removes dead air and applies editorial pacing
  • Adds kinetic typography, device choreography, and sound design
  • Outputs 10–20s teasers and 30–60s launch promos in multiple aspect ratios

You stay in your builder workflow, and your agent builds the demo reel from the same source of truth as your code.

← All posts