Scroll Phone Screens — Free GSAP App Showcase Snippet

The scroll phone screens pattern is the app-landing-page staple: a phone mockup pins in the center of the viewport, and as you scroll, the app's screens slide vertically inside the device frame — as if the page's scrollbar were your thumb flicking through the app. Captions above the phone hand off in sync with each screen. This snippet builds it with GSAP ScrollTrigger (from a CDN), a pure-CSS phone frame, and one master timeline.

The device frame is CSS, and its viewport is a clipping window

The phone is a rounded aspect-ratio: 9/19 box with an inset shadow for the bezel and an absolutely positioned notch. Inside it, .pss-viewport has overflow: hidden with the screen's corner radius — that's the clipping window. The four app screens live in a .pss-screens column set to height: 400%, so each screen fills the viewport exactly and everything outside the window is invisible. The entire effect is translating that one column.

One yPercent tween moves all four screens

The column tweens to yPercent: -75 (that is, -100 × (n−1)/n) across the pinned scroll. Because each screen is 25% of the column, every -25% step brings the next screen fully into the window. Translating a single element is cheaper than animating four separately, stays perfectly seamless at the boundaries, and — since yPercent is a transform — runs on the compositor without any layout work.

Captions are choreographed on the same timeline

Each caption owns one screen-length of the master timeline: it fades and rises in just before its screen arrives (i − 0.3) and lifts out as the next one takes over (i + 0.7). Because entrances and exits are positioned on the *same* timeline that moves the screen column, caption handoffs can never drift out of sync with the screens — scrub position is the single source of truth.

Scroll distance scales with the screen count

The trigger's end is computed as SCREENS × 90%, so adding a fifth screen automatically grants the section more scroll room and keeps the per-screen pacing constant. The duration of the column tween (SCREENS − 1) matches the caption loop's timeline positions, so the choreography scales with zero manual retuning.

scrub: 0.4 mimics a real swipe

A raw scrub: true locks the screens rigidly to the scrollbar, which feels mechanical. The 0.4-second smoothing window lets the column glide briefly after each wheel tick — close to the momentum of a real touch flick — while still settling exactly where the scrollbar says.

Why vertical screens instead of crossfades

A crossfade says "here's another screenshot"; a sliding column says "this is one continuous app." The shared column also means adjacent screens are briefly co-visible during the transition, exactly like mid-swipe on a real device — a detail crossfade approaches can't reproduce.

The bezel layers so screens slide underneath the notch

Layering order does quiet work here: the phone's bezel is an inset box-shadow (so it never affects inner layout), the screen viewport clips at its own radius inside the frame's padding, and the notch sits at z-index: 3 — above the sliding column. As screens travel, their content passes *under* the notch exactly as pixels do on a real device. If you swap in screenshots, keep their status-bar areas empty or the notch will overlap real UI; alternatively move the notch into each screen and let it travel, which reads as a scrolling screenshot instead of a live device.

Customizing it

Swap the gradient screens for real app screenshots (<img> per .pss-screen), change SCREENS, or flip the motion horizontal with xPercent and flex-direction: row. Pair it with a sticky scroll features section, a scroll zoom hero opener, or a phone mockup for static screens elsewhere on the page.