Guide · 8 min read
App Press Kit: 7 Assets Journalists Actually Need (2026 Template)
Most indie app press kits fail before a journalist opens them. A PDF attached to a cold email, a Google Drive folder requiring sign-in, a ZIP named press_kit_FINAL_v3.zip — these formats signal friction before any asset is reviewed. Journalists covering apps evaluate dozens of pitches per week. The ones that turn into published articles have materials that work without friction, in formats editors can embed and link to immediately. Here are the seven assets that separate usable press kits from ignored ones.
Why most app press kits fail before a journalist reaches the assets
App press kits fail because of delivery, not content. A Google Drive link that prompts a sign-in removes itself from consideration in under 10 seconds. A 200MB ZIP the journalist has to download and decompress before seeing a single image loses to the next email in the queue. A PDF that is a PowerPoint export in disguise answers none of the questions an editor needs answered quickly.
The benchmark is 30 seconds. In 30 seconds, a journalist should be able to find your app name, your category, a usable screenshot, and a contact email. If any of those four things takes longer than that, the press kit is failing — regardless of how good the app behind it is.
The solution is a public /press page on your app's website: no login, no Dropbox, no Google Drive share. A direct URL that opens to a page listing every asset as an individual download, plus a single ZIP of everything. This takes a few hours to build and permanently removes the most common friction point in indie app PR.
App press kit fact sheet: 6 fields journalists copy verbatim
Every press kit should start with a fact sheet — a plain-text file or one-page PDF with six fields. App name. Category. Price and monetization model. Platform or platforms. Launch date or current version date. Developer name and country. Below those six: a single-sentence pitch that a journalist can copy directly into their article without rewriting.
Journalists are writers who need raw material, not researchers who will dig for basic facts. A fact sheet removes the step where they have to guess your price, verify your category on the App Store, or paraphrase your product based on screenshots. Apps that make copy-and-paste easy get quoted accurately. Apps that don't get summarized incorrectly — and a wrong price in a published article creates real confusion for users who search for your app afterward.
The one-sentence pitch is the most underworked element in most indie dev press kits. It must work standalone, with no surrounding context. 'A habit tracker for people who have tried every habit tracker and quit' works. 'The most comprehensive AI-powered productivity platform with cross-platform sync' does not — no journalist will reproduce that sentence, so they will write their own, and it may not be favorable.
Two press descriptions: 50 words for roundups, 200 words for features
Write two press descriptions and include both in your press kit: a short version under 50 words for product roundups and listicles, and a long version of roughly 200 words for feature articles. Both must be ready to paste directly into a draft — a journalist should be able to use either without rewriting more than a phrase.
The most common mistake is submitting the App Store description as press copy. App Store descriptions are conversion documents written for browsers already on your product page who just need a nudge. Press descriptions introduce your app to readers with no prior interest. The voice is entirely different. The App Store description sells; the press description informs. Write press descriptions from scratch and do not cross-pollinate the two.
The 200-word version should cover three things in order: what the app does, who it is for, and what makes it different from everything else in the same category. Founding story and mission belong in the founder bio section. Editors who want extra context will ask; editors who cannot find the basics in the first paragraph will move to the next pitch.
Press screenshots: 1920×1080 minimum, no device frames, no overlaid text
Press kit screenshots must be at 1920×1080 minimum, 16:9 or 4:3 aspect ratio, with no device frames and no overlaid text — the opposite of what App Store screenshots require. The App Store set is designed with device frames, headline overlays, and marketing copy to convert browsers at thumbnail size. In an editorial article, those same screenshots read as advertisements; editors decline to use them or crop them badly.
Six to eight screenshots covering your core flows is the right number. Name each file descriptively — habit-tracker-dashboard-dark.png rather than screenshot_4.png — because editors file images in CMS tools and a descriptive filename tells them what to use where. For App Store-specific pixel requirements by device, the screenshot sizes reference covers every format and resolution.
The practical shortcut: take the UI layouts behind your App Store screenshots, export them without device frames at 2560×1440, and add them to a /press/screenshots/ subfolder. That is two hours of work at most, and it is the difference between a press kit editors can use and one they cannot. If your screenshots were built in AppsTemple's screenshot editor, exporting the underlying UI layer without the device frame is all that is needed.
App icon and logo files: 4 formats every editor can actually use
Provide your app icon and any brand logo in four files: a transparent PNG at 1024×1024, a white-background PNG at 1024×1024, an SVG if your logo has a vector source, and a PNG at 512×512 for newsletter-width contexts. Editors assemble assets into CMS templates with varying background colors — a transparent PNG handles every background correctly without manual cleanup. The white-background version is the fallback for editors whose tools do not support transparency.
Do not provide only a JPG, and do not export at compressed quality settings that introduce artifacts at small sizes. Editors scale images down, not up — the largest clean source is always the right starting point. App Store icon submission dimensions differ from these press requirements; the app icon sizes guide covers platform-specific specs for submission. For the press kit, a 1024×1024 transparent PNG is the single most useful icon file you can provide.
Video and GIF: the assets journalists embed without asking
A promotional video is the highest-signal asset in a press kit after screenshots. Host it on both YouTube and Vimeo — YouTube because it is the format every editorial CMS supports for embedding, Vimeo as a fallback for outlets with policies against YouTube. Include both URLs as plain links on the /press page, not as embedded players that obscure the raw link. Keep the video under 90 seconds; 60 seconds is the editorial sweet spot.
If a full promotional video is not ready, a 15-second GIF is a defensible substitute. Newsletter writers and smaller blogs use GIFs in contexts where video embeds are unavailable. Capture three to five representative flows: opening the app, completing the core task, arriving at a result. Export at 1080px width, keep the file under 3MB, and host it as a direct download URL — not behind a preview page requiring click-through.
The GIF of your app's main feature flow is often the only asset a journalist from a smaller outlet has time to embed. Having it available and directly downloadable is the difference between a text-only mention and a visual one. Press coverage with an embedded image consistently drives higher referral traffic than text-only coverage across every category of indie app.
Demo access: the highest-leverage app press kit asset almost nobody includes
Include either a working demo account — email address and password — or a public TestFlight link. This is the most important item in the entire press kit and the asset almost no indie developer provides. A journalist who wants to write seriously about your app needs to use it. If getting access requires emailing you first, most journalists will not send that email.
A demo account with realistic, preloaded content converts a potential mention into a confident write-up. A reviewer who uses your app for 20 minutes writes something substantively different from one who only viewed screenshots. Create a dedicated demo account — not your personal account, not an empty shell. Populate it with synthetic but realistic data: completed tasks, progress streaks, sample projects, whatever a real user's account looks like after two weeks. That populated state shows journalists what your app actually does for people. For how to coordinate press outreach with your overall launch timeline, see the indie app launch checklist.
Pair the demo credentials with a single orientation paragraph on the press page. Four sentences: what to do first, where the main feature lives, what the expected result looks like, and who to contact with questions. That paragraph is the difference between a reviewer who understands your app in five minutes and one who bounces after two and writes a shallow summary. If you are also planning a Product Hunt launch, the Product Hunt launch playbook covers how to sequence press outreach and community launch in the same window.
Host it on a /press page — no login, no friction
The press kit lives on a public /press page on your app's website. Not a Dropbox folder. Not a Google Drive share. A URL that opens directly to a page with every asset available as an individual download and a single ZIP of everything. Include the /press URL in the first paragraph of every pitch email so journalists can bookmark it and return when timing is right — without needing to email you for a resend.
Update the press kit after every major version release: new screenshots if the UI changed significantly, updated fact sheet if pricing or category changed, new video if the app looks substantially different. A press kit showing an outdated version of the app is worse than no press kit — a journalist who installs the current version and finds it does not match the screenshots will lose confidence in everything else you sent.
Build your App Store screenshots in the editor →
Frequently asked questions
what should an app press kit include?
A complete app press kit includes a fact sheet (app name, category, price, platform, launch date, developer name), two press descriptions (50 words and 200 words), press-grade screenshots at 1920×1080 minimum with no device frames or marketing overlays, icon files in transparent PNG and white-background PNG at 1024×1024, a promotional video on YouTube and Vimeo, a 100-word founder bio, and demo access — either login credentials or a TestFlight link. Host everything on a public /press page with no sign-in required.
what format should press kit screenshots be?
Press kit screenshots should be PNG files at 1920×1080 minimum, 16:9 or 4:3 aspect ratio, with no device frames, no overlaid marketing text, and no watermarks. These differ from App Store screenshots, which include device frames and marketing copy for conversion. Editors embedding images in articles need clean UI screenshots. See the <a href='/screenshot-sizes'>screenshot sizes reference</a> for App Store-specific submission dimensions.
how do i send an app press kit to a journalist?
Include a direct /press URL in the first paragraph of your pitch email — not a Dropbox link, not a Google Drive share, not a ZIP attachment. The URL should open to a page with all assets available for individual download without sign-in. A journalist who has to log in or download a large file before seeing anything will usually move on. The press URL in the pitch lets them access your materials without replying to you first.
do indie apps need a press kit?
Yes — even small launches benefit from having materials ready before pitching. Journalists who cover indie apps write about apps with modest download counts when the story angle is strong. The press kit is not what gets them interested; a targeted pitch does that. But once a journalist decides your app is worth their time, a kit that works without friction is the difference between a feature article and a brief mention in a roundup.
how often should i update my app press kit?
Update after every major version release: new screenshots if the UI changed significantly, updated fact sheet if pricing or category changed, new video if the app looks substantially different. A press kit showing an old version of the app can work against you — a journalist who installs the current version and finds it doesn't match the screenshots will question the accuracy of everything else you sent. Add a version date or 'last updated' note to the press page itself.