App PR: how to earn press coverage for an app launch

Press coverage still moves apps, though not the way launch checklists suggest. One article in the right newsletter can bring a week of installs from exactly the right people, while a release sent to five hundred inboxes usually brings nothing. The difference is preparation done weeks before launch day: a story, a short list of people who care about it, and access that makes their job easy.

This guide covers the mechanics of app PR, from the story to measuring results. Finding the angle and shaping the pitch email are covered in our guide to finding the angle before you promote an app.

Contains affiliate links. As an Amazon Associate I earn from qualifying purchases.

What counts as a story

A new app is an announcement, not news. Writers pick up apps when they connect to something their readers already care about, and the stories that get written tend to take a few shapes:

A real problem solved for a specific group, with someone willing to talk about it. A teacher who built a seating plan app for their own school is a story; a new classroom app is not.
A local angle: a team from the city, a service the region lacked, a launch tied to a local season.
A finding you actually have. If your beta showed something surprising about how people do a task, it can carry a piece. Never invent or round it up.
Craft. Developer and design publications cover how something was built: a hard technical problem or an unusual accessibility approach.
Timing: a rule change, a new platform feature supported on day one, a seasonal need.

If none of these fit, the launch may not be the story. Save the press effort for the first milestone that is.

Build a short press list

A good list for a small app has a few dozen names at most. Each entry is a person, not a publication: someone who has written about your kind of app, or your users' world, in the past few months. Note what they covered, how they like to be contacted and their time zone.

Lead times differ by outlet; the ones below are rules of thumb, so ask when in doubt.

Outlet type	What they want	Rough lead time	What to send
App and tech news sites	News, first looks, platform tie-ins	Days to a few weeks	Pitch, build access, assets
App reviewers	Time with a finished build	A few weeks	Build or code, reviewer guide
Newsletters in your users' niche	Something useful for their readers	One to three weeks	Short pitch, a reader offer if it fits
Podcasts and video creators	A person with a story	Several weeks	Founder availability, demo build
Local and regional press	People and places nearby	One to two weeks	Founder story, team photos
Monthly print magazines	Features planned far ahead	Months	Early contact, exclusive material
Trade press in your users' industry	What changes for professionals	A few weeks	Use cases, a customer willing to talk

Timing the launch

Pick the launch date with the press in mind, not only the build. Avoid weeks when app writers are buried in platform news: Apple's developer conference, usually in early June, its iPhone event, usually in September, Google I/O, usually in May, and the big holiday weeks.

Both stores let you fix a date that coverage can point to. At the time of writing, a brand-new app can go up for pre-order on the App Store 2 to 180 days before release, and it downloads automatically to pre-ordering devices on release day. Google Play's pre-registration can last at most 90 days before the app must launch in production; pre-registered users get a notification, and eligible devices install the app on launch day. Either way, a writer has a working store link before launch.

A timeline that works for most small launches:

Six to eight weeks out: choose the story, draft the press list, and submit a featuring nomination in App Store Connect. Apple's featuring guidance asks for at least two weeks' notice and suggests up to three months for wider consideration.
Four weeks out: put the press kit live and set up test builds for reviewers.
Two to three weeks out: send embargoed pitches to the people who need time, such as reviewers, podcasts and newsletters.
One week out: pitch news writers, and answer every question within a day.
Launch day: lift the embargo at the stated time, add the store links to the press kit, and thank the writers who covered it.
One to two weeks later: send a single follow-up to writers who were clearly a fit and didn't reply, then let it rest.

Embargoes and exclusives

An embargo is an agreement that a writer gets information early and publishes no earlier than a stated time. It only works if the writer agrees before receiving the details, so the first email asks rather than assumes: happy to share the build under embargo until Tuesday at 09:00 CET, if that works for you. Once they agree, repeat the time and zone in the subject line and at the top of the press kit page.

Most writers respect embargoes, but an embargo is a courtesy, not a contract. Don't send anything you couldn't live with seeing a day early. If one breaks, say nothing in public, release to everyone else promptly, and leave that outlet off the next embargoed list.

An exclusive works differently. One outlet gets the story first, often with an interview, and everyone else hears after it runs. Offer it to the single outlet whose readers match your users best, give them a date by which to say yes, and tell them honestly that you will pitch others once their piece is out.

Giving writers access

Writers review what they can use. Before launch, TestFlight lets up to 10,000 external testers install a build through an email invitation or a public link, and each build stays testable for 90 days. Builds for external testers go through Apple's beta review, so add the reviewers' group a few days before you need it. On Google Play, a closed testing track gives reviewers the build without a public listing.

After release, App Store promo codes give a paid app away for free: at the time of writing, up to 100 per version on each platform, each valid for four weeks and usable once. People who redeem a promo code can't rate or review the app, which keeps codes from turning into a ratings tactic. Google Play allows up to 500 promo codes per quarter across non-subscription promotions, and a promotion can run for up to a year. Send each writer a personal code and keep a log of who received what.

Add a reviewer guide to the press kit: one page with what the app does in two sentences, the three things worth trying first, known issues in the current build, the price model and platforms, and who to contact. Writers often reuse your store screenshots, so offer clean versions without device frames.

Following up

Send one follow-up, a few working days after the pitch, and give it something new: a short screen recording, the answer to an obvious question, or a confirmed launch date. Then stop. If a writer replies with questions in launch week, answer within hours; a writer who waits a day for a screenshot moves on to the next app.

When coverage appears, correct factual errors politely and privately, never opinions, and share the piece.

Measuring what coverage did

Give each outlet its own tracked link where you can. On the App Store, campaign links add a provider token (pt) and a campaign token (ct) to your app's URL, and App Analytics reports them under acquisition, once a campaign has at least five first-time downloads and has run for 24 hours. On Google Play, UTM tags on the store link appear as UTM source and campaign in Play Console's store performance reports. Writers don't always use the link you send, so also watch product page views and downloads by day around each article.

Keep a coverage log with the outlet, date, link, tracked visits, downloads in the following week, and whether the piece brought reviews or support questions. After two or three launches it shows which kinds of outlets are worth the effort for your app. For what to do with the people coverage brings in, see our guide to the first 90 days of app growth.

Questions

Is a paid press release distribution service worth it for an app?

Rarely, for a small app. Wire services place a release in databases, not in front of the particular writers who cover your users. A short, personal email to the right few dozen people does more for most launches and costs only time.

Can journalists review the app before it reaches the store?

Yes, through TestFlight on iOS and a testing track on Google Play. Keep reviewer builds close to the release version, list known issues plainly in the reviewer guide, and tell writers when the store version is live so their links work on publication day.

What if nobody writes about the launch?

It happens to good apps. Reread the pitch with fresh eyes, ask whether the story was really news, and plan for the next milestone, such as a major update, a new platform or a genuine finding from your own data. Apple's featuring nominations accept significant updates as well as launches, so put the next nomination in the calendar the week after launch.