Animated app onboarding screens to MP4

An app onboarding video is the short auto-play sequence you put on a landing page, an App Store listing, or a paid social ad to demonstrate the first 30 seconds of using your app. The template that actually converts is the same one you ship inside the app itself — a three-screen carousel with a headline, an illustration, and a page-dots indicator — captured as an animated MP4 instead of as live UI.

This post is that template: each screen slides in from the right, the headline fades, the illustration scales up with a slight overshoot, and the page dots advance in step. The whole loop is six seconds and hf-seek-driven.

What an onboarding video is for

Three jobs, in order:

1. Establish that the app exists and what kind of thing it is (note-taking, fitness, finance, dating).
2. Show three specific actions the user will take in the first session.
3. End on a screen that telegraphs the first reward — the moment of value.

The viewer is making a decision in under fifteen seconds. The onboarding video has to walk them through the carousel they'd see if they downloaded — literally the same flow — so that by the time they install, the first three screens are familiar and they tap through without friction.

The slide-in mechanic

Each screen slides in from the right edge (translateX(100%)) to its resting position (translateX(0)) over 0.6 seconds with a cubic ease-out. The outgoing screen slides out to the left in the same window — this is critical. Two-screen-pass during a transition reads as a carousel; a fade-only swap reads as a slideshow. The horizontal motion preserves the "swipeable" affordance even though no swipe is happening.

const slide = Math.min(1, Math.max(0, (t - startT) / 0.6));
const easeOut = p => 1 - Math.pow(1 - p, 3);
screen.style.transform = `translateX(${(1 - easeOut(slide)) * 100}%)`;

The 0.6-second duration is the Goldilocks setting: 0.4s feels jittery (too snappy for the viewer to register the transition); 0.9s feels slow (the viewer's eye starts wandering). 0.6s is the right tempo for a carousel that's neither tutorial nor cinematic.

The illustration scale-up

The center illustration on each screen starts at scale(0.7) and pops up to scale(1.0) with a slight back-ease overshoot — the curve goes scale(0.7) → scale(1.04) → scale(1.0). The overshoot is what gives each screen the feeling of landing. Without it, the illustration just appears, and the screen reads as flat.

const easeBack = p => {
  const c1 = 1.5, c3 = c1 + 1;
  return 1 + c3 * Math.pow(p - 1, 3) + c1 * Math.pow(p - 1, 2);
};
illustration.style.transform = `scale(${0.7 + easeBack(ip) * 0.3})`;

The illustration animates after the screen slides in — there's a 0.25-second offset so the slide completes (or nearly so) before the illustration starts scaling. Trying to do both at once is a visual collision: the eye can't track translate and scale simultaneously without losing one of them.

The headline-and-body fade

The copy block fades in 0.45 seconds after the slide starts, with a small translateY(8px) lift. The fade is intentionally later than the illustration so the visual hierarchy is preserved: illustration first, copy second. The viewer's eye lands on the illustration, registers the metaphor, and then reads the headline that confirms it.

This order matters. If the copy arrives before the illustration, the viewer reads the headline against an empty stage and the illustration arrives as a redundant decoration. With the illustration first, the headline reads as a caption — which is what it is.

The advancing dots

The page-dots advance discretely. The active dot is wider (22px vs 8px) and inked, with a 4px border-radius (so it reads as a pill rather than a circle). The transition between active and inactive is instant — no fade, no slide. The user's mental model of dots is "discrete index of position," and any animation on the dot itself fights that model.

The dots sit outside the screen frame, under the carousel. Putting them inside the frame reads as part of the app's UI, which causes a brief confusion when the actual app's dots are in a slightly different position. Outside, they read as video chrome — clearly the video's indicator, not the app's.

Determinism, again, but specifically for paid social

Paid social platforms (Meta, TikTok, X) require precise asset dimensions and durations. A 6-second 9:16 onboarding video at 1080×1920 fits Reels, Stories, and TikTok In-Feed; a 1:1 1080×1080 fits Meta feed; a 16:9 1920×1080 fits YouTube pre-roll. Same HTML, four renders.

If the renders aren't deterministic, you can't trust that "we updated the headline" produces only the expected diff — the whole pipeline has to be re-QA'd. With hf-seek-driven animation and pinned dependencies, you change one CSS variable and re-render only the affected aspect.

For a deeper argument see deterministic video rendering in CI.

Render to MP4

hyperframes render input.html --out clip.mp4 --duration 6 --fps 30

For the four standard ad aspects:

# 9:16 Stories/Reels/TikTok
hyperframes render onboarding.html --out onboard-9x16.mp4 \
--width 1080 --height 1920 --duration 6 --fps 30

# 1:1 Meta feed
hyperframes render onboarding.html --out onboard-1x1.mp4 \
--width 1080 --height 1080 --duration 6 --fps 30

# 16:9 YouTube pre-roll
hyperframes render onboarding.html --out onboard-16x9.mp4 \
--width 1920 --height 1080 --duration 6 --fps 30

# 4:5 Instagram feed
hyperframes render onboarding.html --out onboard-4x5.mp4 \
--width 1080 --height 1350 --duration 6 --fps 30

Common mistakes

Six-screen onboarding videos. Three is the limit. The viewer is making a decision in fifteen seconds; six screens means two seconds each, which is below the read time for a headline. Cut.

Animated dots. Don't animate the dot transition. The user's mental model of pagination dots is discrete; smoothly morphing them reads as a glitch.

Slide-in from the bottom. It feels novel for one screen and exhausting after three. Horizontal carousels are horizontal because the next screen sits to the right. Bottom-up motion reads as modal popovers, not pagination.

Skipping the dwell. Each screen needs at least 1.4 seconds of held frame after the animation completes, so the headline can be read. If the screens slide through without a dwell, the video is a transition reel, not an onboarding.

For the related App Store-specific format see App Store preview videos; for the broader case for animated marketing see HTML is the next video codec.

FAQ

How many screens should the video have?

Three. Occasionally two, never more than four. Three is the cognitive cap for a fifteen-second video; the viewer can hold three distinct ideas across the duration and recall them at the install screen.

Should the video have audio?

Plan for muted. Most onboarding videos play in feeds that auto-mute by default; voiceover narration won't be heard. Captions in the video itself are the right channel. If you ship an audio track, treat it as a bonus, not the primary message.

What's the right dwell per screen?

1.6 to 2.0 seconds after the slide-in completes. So each screen consumes roughly 2.0–2.4 seconds total. Three screens at that pace fits the 6-second window with a little time at each end.

Can I match my actual in-app onboarding 1:1?

You should. Copy the headlines verbatim. Use the same illustrations (export them from your design system). The point isn't to make the video look better than the app; it's to make the install feel like a continuation of the video.

How do I handle dark mode?

Render two versions — a light and a dark variant — and let the ad platform serve based on user preference where supported. The HTML template uses CSS variables; you swap --bg and --ink and render both passes from the same source.

Close

App onboarding videos are a templated genre with strict rules: three screens, six seconds, slide-in with cubic ease-out, illustration overshoot, headline fade, dots advance. Build the template once in HTML, render every aspect, and the next time marketing wants to change a headline you ship the new asset in five minutes.

Start at the quickstart, browse the playground, or read the data-driven render pipeline at programmatic video from data.