The Press Kit an Indie Game or App Actually Needs

Most submissions do not fail because somebody disliked the game. They fail four fields in, when the developer realises they do not have a square icon that is not a screenshot crop, or a privacy policy URL, or a picture of the build that is actually live. The tab gets closed, and a listing that would still be sending installs next year never happens.

A press kit fixes that, and it is much smaller than the phrase suggests. It is not a PDF. It is not a logo suite in nine formats, or a fact sheet with a pull quote from yourself. It is one folder, assembled once, that answers every question a store form, a directory, or a reviewer is going to ask — so that submitting anywhere takes five minutes instead of an evening.

The nine things everyone asks for

Store consoles, directory forms, and journalists want the same core set in slightly different shapes. Write each of these once and every submission after the first is copy and paste.

1. The name, spelled and capitalised exactly the way it should appear everywhere.
2. A one-line description of about 60 characters.
3. A short description of roughly 150 characters, for cards and previews.
4. A long description of two or three real paragraphs.
5. A square icon exported at 1024×1024, with no rounded corners of your own.
6. Three to six screenshots from the build that is live right now.
7. A wide image around 1280×720 for the places that want a banner.
8. Every link: store pages, web build, your site, support, privacy policy.
9. A contact address you will still be reading in a year.

That is the whole kit. Everything below is about getting items two through six right, because those are the ones that decide whether somebody installs.

The three descriptions are three different jobs

Writing one description and trimming it to fit is the most common mistake, and it produces three bad versions of the same sentence.

The one-liner sits under your name in lists and search results. It has to say what the thing is, not how it makes you feel. "A one-tap orbit game you can play offline" tells somebody whether to keep reading. "Reach for the stars" does not. Aim for a line that still makes sense read aloud with no icon next to it.

The short description is the card blurb — the 150-odd characters somebody skims while deciding. Give it the mechanic and the one honest differentiator. If your game is a Sudoku with real-time multiplayer, the words "real-time multiplayer" belong here, not in paragraph four of the long version.

The long description is where you get to be specific. Two or three paragraphs: what it does, who it is for, and what is honestly limited about it. That last part converts better than people expect. "Single player works offline, multiplayer needs a connection" answers a question the reader already had, and it prevents the one-star review claiming the offline mode is broken.

Write all three in a plain text file. Do not write them in a store console, where you cannot easily get them back out.

Screenshots are the part that decides it

More installs are lost here than anywhere else in the kit. The rules are boring and they work.

• Shoot the build that is live. Not a mockup, not a version from three releases ago. If the screenshots show an old interface, the first thing a new user feels is that they were sold something else.
• Make the first one carry the whole pitch. In most places it is the only one that appears before a tap. It should show the thing being used, in the state it looks best in — not a title screen, and not a menu.
• Show the product, not marketing. A device frame on a gradient background with four words of copy over it is an advert, and people scroll past adverts. They stop on a picture of a screen that looks like something they would use.
• Keep them readable at thumbnail size. Open your own screenshots at about 150 pixels wide. If you cannot tell what the app does, neither can anybody else.
• Stay in one orientation. If it plays in portrait, every screenshot is portrait. A mixed set reads as a mistake even when it is not.

Six good ones beat ten that repeat each other. If two screenshots make the same point, delete one.

The icon, briefly

Export a square PNG at 1024×1024 with no rounded corners, no drop shadow, and no baked-in transparency, then downscale for anything that wants smaller. Every surface applies its own mask, so corners you rounded yourself get clipped or double-rounded. Now look at it at 48 pixels: an icon that reads as one shape in two colours survives that, and an icon with your studio name in it does not.

Store specifications change, so check the current ones in the console on the day you submit. Keeping a 1024 master means you are never re-exporting from scratch when they do.

Links, and the one that stalls everything

Collect them in the same file: App Store URL, Google Play URL, the web build if there is one, your site, a support address, and the privacy policy.

The privacy policy is the field that stops submissions dead. Both app stores require a policy URL for every listing, plenty of directories ask for one, and it is the item nobody has thought about in advance. It has to be a real page at a stable URL — not a shared document, and not something that 404s in six months when you move hosts. Write it before you start submitting anywhere and the process stops having a wall in the middle of it.

What a human actually checks

We read every submission that comes into the directory, so this part is first-hand rather than inferred. Submissions almost never come back for quality. They come back because:

• there is no working link to get the thing, so there is nothing to verify;
• the screenshots are of a different build than the one on the store page;
• the description is three sentences of adjectives and never names a mechanic;
• the icon is a cropped screenshot, so it turns to mush at card size;
• or what the listing says about ads and purchases does not match what the app does when you open it.

Every one of those is an asset problem rather than a product problem. That is the entire argument for assembling the kit once, properly, before you need it.

What you can skip

• A press release. Nobody asked for it and nobody will read it. The long description does the same job in a format people actually consume.
• A logo pack. One icon and one wide image cover nearly every submission you will ever make.
• A fact sheet of awards and press quotes. If you have them, work them into the long description. If you do not, an empty accolades section is worse than no section.
• A trailer you have not made. A good one helps. One assembled in a hurry from the same six screenshots does not, and no submission form requires it.

Keep it in two places

Put the folder in your repository, next to the code, so it is versioned alongside the build it describes. Then put a copy on one public page on your own site — a /press page is the convention — with the images downloadable and the text selectable. When a curator or a reviewer asks, you send one link instead of hunting for a zip file.

Update it when the product changes. Screenshots from this month read as maintained. Screenshots from last year read as abandoned, whatever the version number says.

Then actually use it

The point of the kit is that the second submission costs nothing. Once it exists, work through the places worth listing on in one sitting — there is a filtered list of the free ones in where to submit your indie game or app for free.

If it is ready now, put it on the board. Listing is free, nothing on it is sponsored, and every listing starts on zero and moves on what the people who tried it do next.

All articles