App Demo GIF: A 20-Second Shot List That Works

Exporting a GIF is the easy half. Deciding what to film is the half that determines whether anyone watches it.

A demo GIF has one job: show a stranger that your app produces a result, in less time than it would take them to read your tagline. Twenty seconds is the whole budget, and it splits into four shots. The empty state with the one control visible, the single input being entered, the work actually happening, and the finished result held still long enough to read. No login screen, no logo card, no cursor wandering around looking for the button. Then you check what the destination accepts before you export, because the App Store and Google Play take no GIF at all, X caps an animated GIF at 5MB on mobile and 15MB on the web, and Product Hunt only animates a GIF thumbnail while someone hovers over it.

That last part is where most demo GIFs die. Someone spends an afternoon on a beautiful recording, exports a 22MB file, and then discovers the surface they made it for will not take it, or takes it and shows a single frozen frame.

What is a demo GIF supposed to prove?

It proves the app is real and that it does something. That is the entire brief.

It is not a tutorial. It is not a feature tour. It does not need to cover the settings panel, the keyboard shortcuts, or the second thing your app does. A person scrolling a launch feed has one question in their head, and it is not "how does this work". It is "does this actually do the thing the headline says". A demo GIF answers that in a few seconds by showing an input going in and an output coming out.

This is why a GIF beats a two-minute walkthrough video at the top of a listing or a README. It autoplays, it has no controls to press, it needs no sound, and it finishes before the viewer has decided to leave. A walkthrough video is a thing you agree to watch. A GIF is a thing you have already watched by the time you notice it.

The corollary is that if your app's value cannot be shown in a screen recording, a demo GIF is the wrong asset. Anything whose payoff is a database query that runs overnight, a report emailed on Fridays, or a saving you notice next quarter needs a diagram or a sentence, not an animation of a spinner.

Which four moments belong in it?

Here is the storyboard. Film against it directly. The durations add up to twenty seconds, and each shot has one job, so if a shot is doing two jobs you have the wrong shot.

Shot	Runs	What has to be on screen	What must not be on screen
1. The empty state	0:00 to 0:03	Your app already open, already signed in, with the one control you are about to use visible in the middle third of the frame. The cursor parked next to it, not moving	A login screen, a logo card, a splash animation, a browser tab bar, a cursor drifting across the frame looking for the target
2. The one input	0:03 to 0:09	A single field being filled with a real, specific value, typed or pasted at a readable pace. One field, not three	Placeholder text like "test" or "asdf", a form where you fill in six fields, any menu you open and close again
3. The work happening	0:09 to 0:13	The state change itself. One to two seconds of the loading or processing state so the viewer registers that something ran, with the rest of the dead time cut out	Ten seconds of a spinner. If the real wait is long, cut it to about two seconds and let the result land
4. The result	0:13 to 0:20	The finished output, complete, held still. Seven seconds is a long hold and it is deliberate, because this is the frame people read. Cursor parked out of the way	A victory scroll through the result, a follow-on click into another screen, a "and here's another feature" bonus shot

Two rules that hold the whole thing together.

The last frame should be a frame you would happily ship as a static screenshot. Some surfaces show only the first or last frame of a GIF, and every surface shows a still of it to someone whose connection is slow or whose client blocked the animation. If the frozen frame is meaningless, the asset fails silently for those viewers.

Make the loop survivable. A GIF loops forever by default, so the jump from shot 4 back to shot 1 happens over and over. Either hold the final result long enough that the loop reads as a deliberate restart, or make the first and last frames similar enough that the cut does not snap. A demo that flickers back to an empty screen every eight seconds reads as broken.

How long should it run and why?

Twenty seconds is the ceiling, not the target. If you can do it in twelve, do it in twelve.

The number is not arbitrary. Apple sets a hard 15 to 30 second window for App Store app previews in its App Store Connect app preview specifications, which is the closest thing this format has to a published standard for how long a product demonstration should run before a stranger stops watching. Twenty seconds sits comfortably inside that window, and it is short enough that a GIF at a sensible frame rate still lands under the file size caps below.

The practical constraint pushes the same way. GIF stores animation as a sequence of frames, so file size scales almost linearly with duration. Doubling the length roughly doubles the weight. Every second you cut is a second of load time you give back, and the seconds worth cutting are always the same ones: the app launching, you deciding what to click, and the real processing wait.

What kills a demo GIF in the first two seconds?

Four things, in the order they cost you viewers.

A logo card at the front. A two second brand animation before the product appears is two seconds of a twenty second budget spent on something the viewer already knows, since your name is written directly above the GIF. Cut it entirely.

A login screen. Nobody wants to watch you type a password. Start signed in, on the screen where the work happens.

An unmoving frame. If the first second looks like a static screenshot, people scroll past before the motion starts. Shot 1 should be short, and shot 2 should begin while the viewer is still deciding whether to look.

A wandering cursor. The cursor is the viewer's eye. When it drifts, hovers, opens the wrong menu and backs out, the viewer learns that nothing important is happening. Plan the click path before you record, and re-record rather than editing around a fumble. This is also why you should turn off click-highlight effects that draw a coloured ring around every click, since at thumbnail size they read as visual noise rather than emphasis.

There is a fifth one that only shows up later: unreadable text. A demo GIF gets embedded at whatever width the page gives it, often a few hundred pixels. Record at a smaller window size than you think you need, or zoom the interface in before recording, so the type is still legible when the file is scaled down. The same logic governs still images, and the app screenshot sizes and safe zones guide goes through the crop maths in detail.

GIF, WebM or video: which does each surface accept?

This is the part to check before you export, not after. Every row below comes from the platform's own current documentation.

Surface	Animated GIF	Video	The detail that catches people out
GitHub README, issues and pull requests	Yes	Yes, as .mp4, .mov or .webm	GitHub's docs on attaching files list PNG, GIF, JPEG, SVG and video as supported, and cap attachments at 10MB for images and GIFs. Video attachments are capped at 10MB on a free plan and 100MB on a paid one
Product Hunt	Yes, for the thumbnail	YouTube link	Per Product Hunt's guide to posting a product, a thumbnail GIF has to be under 3MB and "not too flashy", and it only animates while someone hovers over the post. Gallery images are recommended at 1270 by 760, and the gallery needs at least two images before it is viewable
X	Yes	Yes	X's help page on posting photos and GIFs allows animated GIFs up to 5MB on mobile and 15MB on the web, accepts GIF, JPEG and PNG only, and permits exactly one GIF per post. A GIF cannot be combined with other images in the same post
LinkedIn articles	Yes, within the article body	Separate upload	LinkedIn's guidance on rich media in articles supports GIF, JPEG, PNG and WebP in the body, requires GIFs to be under 400 frames, and no longer allows a GIF as the article cover image
Apple App Store	No	Yes, as an App Preview	Apple's app preview specifications accept H.264 in .mov, .m4v or .mp4, or ProRes 422 HQ, 15 to 30 seconds, up to 500MB. Screenshots are JPEG or PNG. There is no GIF slot anywhere on a product page
Google Play	No	YouTube link only	Google Play's preview asset requirements take JPEG or 24-bit PNG for screenshots and the feature graphic, a 32-bit PNG icon, and a single preview video supplied as a YouTube URL. No direct video upload, no GIF
Your own landing page	Yes, but do not	Yes, and prefer it	You control the markup here, so serve a muted, autoplaying, looping <video> with a WebM source. It is the same animation at a fraction of the weight
TryMy listing	Not applicable	Not applicable	Our submission form is a single URL field. We open the app, write the listing and capture the screenshot ourselves, and the listing card renders a still image. What matters for us is what your landing page shows above the fold, not what you upload

Reddit is the one common surface where we could not find a published file size or format specification for image posts in its help centre, so treat its ceiling as unknown and keep any GIF you post there well under the smallest limit in this table.

The pattern is clear enough to act on. GIF is the format for developer and social surfaces. Video is the format for the app stores and for your own site. Nothing on either app store takes an animated GIF, so if you are building a mobile app, film once and export twice: a GIF for the README and the launch posts, and a properly encoded video for the store listing.

How do you keep the file small enough to load?

Understand why GIF is heavy and the levers become obvious. MDN's reference on image file types explains that GIF stores 8-bit indexed colour, meaning a palette of at most 256 colours per frame, with dithering used to fake anything beyond that. Screen recordings of modern interfaces are full of gradients and antialiased type, which is exactly the content that dithering handles badly and expensively. MDN's own recommendation is to consider WebP, AVIF or APNG for animation sequences instead.

So, in the order that actually saves bytes:

Crop hard. Halve the dimensions and you quarter the pixel count. Record the region where the app is working, not the whole desktop.

Cut the duration. Weight scales with frames, and the easiest frames to lose are the ones where nothing changes.

Drop the frame rate. A screen recording of a UI does not need 30 frames a second. Somewhere between 10 and 15 is usually indistinguishable for this kind of content and roughly halves the frame count.

Reduce the palette. Most export tools let you set the number of colours. Flat interfaces survive a smaller palette far better than photographs do.

Ship video where the surface allows it. A WebM or MP4 of the same recording will usually be a small fraction of the GIF, which is why GitHub allows video attachments at all.

For a target, use the tightest cap among the places you plan to post it. Across the surfaces above that publish a number, the binding constraint is Product Hunt's 3MB thumbnail, and X's 5MB mobile limit is the next one up. Build to the smallest and everything else has room to spare. The same asset discipline applies to the words next to it, and the guide on writing an app description for directory listings covers that side. For where each version of the file ends up, the rundown of places to post your app lists the surfaces worth the export.

Frequently asked questions

How long should a product demo GIF be?

Twenty seconds at the outside, and shorter is better. The four-shot storyboard above fits in twenty and most apps can compress it to twelve or fifteen. Apple's app previews are capped between 15 and 30 seconds, which is a reasonable outer bound for how long anyone will watch a product demonstrate itself. Past that you are making a walkthrough video, which is a different asset with a different job.

Should the GIF have sound or captions?

No sound. GIF has no audio track at all, and even a video embedded on a launch page will play muted by default in most browsers, so anything you say out loud is lost.

Captions are a judgement call. A short label burned into the frame, three or four words naming what just happened, can help when the interface alone is ambiguous. Keep it large, keep it in a consistent corner, and do not let it become a subtitle track. Since the animation itself carries no alternative text, write a real description into the alt attribute wherever you embed it, so that people using a screen reader and anyone whose client blocks the animation still learn what the demo showed.

Do directories accept GIFs in listings?

Mostly no, and it varies enough that you have to check each one. Neither app store takes a GIF anywhere on a product page. Product Hunt takes one as a thumbnail under 3MB, but it only animates on hover. Most indie directories, including this one, do not have an upload field for one at all. Our submission form takes a single URL and we capture the listing image ourselves, so the useful move is to put the demo on your own landing page above the fold, where it does the work for every directory that renders a preview of your site.

What tool makes the cleanest screen recording?

Any of them, honestly. The tool is not what makes a demo good, the shot list is. Open source options that people have used for years include ScreenToGif on Windows, Kap on macOS and Peek on Linux, and both macOS and Windows have built-in screen recorders that produce a video file you can convert. If you want precise control over frame rate, palette size and cropping, ffmpeg does all of it from the command line and is what most of the graphical tools are wrapping anyway.

The part worth spending money or time on is not the recorder. It is recording the sequence three times until the cursor moves like someone who knows where they are going.

A good twenty seconds does more selling than a paragraph ever will. When it is ready, put the app somewhere it stays visible after launch week: submit it free, and a person will open it, try it, and write the listing.