Every week, app launch submissions arrive in our inbox. Some get reviewed. Most do not.
The difference is almost never the quality of the app. We have passed on genuinely good apps because the submission gave us nothing useful to work with. We have covered modest, early-stage apps because the developer made our job easy, told a clear story, and sent everything we needed in a single well-structured email.
After reviewing hundreds of Android apps, this is the honest editorial perspective on what editors actually want in an app press release – what makes a submission stand out in a full inbox, what sends it straight to the archive, and what developers consistently get wrong precisely when they think they are getting it right.
What We Actually Want
A Story, Not a Feature List
Every press release we receive tells us what the app does. Very few tell us why it exists.
Features are the skeleton of a press release. The story is the flesh. We can write a functional review from a feature list – but we cannot write a compelling, readable article from one. The reviews that get read, shared, and ranked consistently in search are the ones built around a narrative: a developer who noticed a problem nobody else was solving, a gap in the market that the existing top apps were missing, a personal frustration that became a product because no solution existed.
The best submission we have ever received opened with three sentences about a developer who moved cities during the pandemic and could not find a single app that helped manage a household budget across two currencies simultaneously. By the fourth sentence we were already interested in the app itself. That is exactly what a story does – it creates the reader’s investment before they have seen a single screenshot.
Before you write your press release, answer this one question in writing: why did you build this specific app, for this specific person, at this specific moment in time? The honest answer to that question is your lede. Everything else in the press release follows from it. Check our submission guidelines for the full format we expect – but the story is always the most important element regardless of format.
Specificity Over Superlatives
“Revolutionary.” “Seamless.” “Powerful.” “Intuitive.” “Game-changing.” These words appear in the majority of submissions we receive and they communicate nothing useful to us. Every developer believes their app is intuitive. Every app in the category is described as powerful by the person who built it. These are not differentiators. They are filler.
What we need from a submission is specificity. Not “a powerful task manager” – but “a task manager that lets you set tasks using voice notes, automatically transcribes them, and sorts them by deadline without any manual input required.” Not “a seamless budget tracker” – but “a budget tracker that reads your SMS bank transaction alerts and categorises spending automatically, with no manual data entry at any point.”
Specific language accomplishes three things simultaneously that superlative language cannot. It tells us precisely what the app does. It differentiates the app from competitors in the same category. And it gives us directly quotable, accurate copy for the review article – sentences we can use as written because they are already factual and specific. Superlative language does none of these things. Read your press release back and mark every adjective. If the adjective could describe any app in your category without being false, delete it and replace it with a specific, verifiable claim.
Verified Claims and Honest Numbers
If your submission states “over 10,000 downloads,” we will check that against your Play Store listing before we proceed. If the listing shows 1,000–5,000 installs, your submission goes into the archive and your credibility with our editorial team is gone permanently – including for any future submissions about future apps.
Be accurate about where you are. “500 beta testers across six weeks of closed testing” is a real, specific, verifiable number with a real story attached to it. “Early access users in 12 countries” is specific and checkable. Both are perfectly acceptable for a launch press release, and both are more compelling to an editor than a vague claim about download milestones.
If you have no numbers at all – you are launching cold, no beta group, no pre-registrations, no prior version – say exactly that. “This is our studio’s first Android release” is an honest, workable statement that an editor can write around. We cover first-launch stories regularly. We do not cover stories from developers who have misrepresented their traction, and we remember the ones who tried.
A Press Release That Has Already Been Published Somewhere
This requirement surprises most developers when they first encounter it. Why should it matter to us whether the press release has been published elsewhere before you send it?
Because prior publication signals commitment and seriousness in a way that nothing else does at the submission stage. A developer who has already invested the time to publish their launch on a dedicated Android press platform – like AndroidNewswire, which distributes Android developer press releases to an editorial network and indexes them for search – has demonstrably done the foundational launch work. Developers who go a step further and use the platform’s dedicated App Launch Service signal an even higher level of intent, since they have committed to a structured, professionally distributed release rather than a basic submission. It tells us the app is real, the launch is imminent or live, and the developer is treating this as a genuine product launch rather than a casual Play Store upload.
Prior publication also gives us a practical cross-reference point. We can verify the app details against the published piece, check the developer’s claims against a third-party document, and pull the formal quote block if we need it without asking for it separately. Developers who submit a press release only to our inbox, with no prior publication anywhere else, are asking us to be their first and only editorial coverage. That places the entire editorial credibility risk on us. We are substantially more likely to cover an app that already has an indexed public presence than one that exists only in an email thread.
Publish first. Then pitch. This is the correct sequence. Our app review archive is full of apps that followed this sequence – and the coverage they received was better for it.
What Sends a Submission Straight to the Archive
A subject line that reads only “Press Release.” This tells us nothing and makes us work harder before we have even opened the email. A functional subject line names the app and states one specific fact: “HabitFlow – Offline Habit Tracker for Android, Launching June 10.” That subject line answers our first question before we open the email. “Press Release” answers nothing.
No Play Store link in the first paragraph. If we have to search for your app after reading your press release, we will not search. We will move to the next submission. The Play Store URL belongs in the opening paragraph where we can click it without reading further, and again in the specifications block at the end. Both instances, every time, without exception.
Screenshots that are obviously marketing mockups. Illustrated phone frames with perfect UI rendering, gradient backgrounds, and no evidence of a real interface. We know what mockups look like because we have seen thousands of them. Real screenshots show real interfaces – slightly imperfect, honest, representative of what a user will actually see after they install the app. Send us real screens from a real build. Mockups tell us the real UI is not ready to be seen, which tells us the app may not be ready to be reviewed.
An unformatted wall of text. A press release is a structured document with a recognisable format: headline, lede, body paragraphs of three to four sentences maximum, a developer quote block, a specifications section, and a media contact. A single undivided block of text signals that the developer has not read a press release before writing one. Format the document correctly. If you are unsure of the format, read three published press releases from any Android platform before you write yours.
A follow-up email within 24 hours asking if we received it. We did. We review submissions on our own editorial schedule. A follow-up the day after sending tells us the developer will be anxious and difficult to manage throughout the editorial process and after publication. One follow-up after five to seven business days with no response is entirely reasonable. One within 24 hours of the original submission is not.
A Gmail or personal email address in the media contact field. This appears in every press release formatting guide ever published. It is still ignored in the majority of submissions we receive. Register a domain. Set up a branded email address. The annual cost is negligible. The difference in how editors perceive a developer with [email protected] versus [email protected] is not negligible.
The Submission That Gets Covered Every Time
After reviewing enough apps to see patterns emerge with complete clarity, the submissions that consistently convert to published editorial reviews share the same profile. Not the same app quality. The same submission quality.
| Element | What It Should Contain | Why It Matters |
|---|---|---|
| Subject line | App name plus one specific differentiating fact | Earns the open before we have read a word |
| Lede paragraph | Who, what, when, where, and why in under 60 words | Answers every editorial gatekeeping question immediately |
| Developer quote | Something specific and human – not “we are excited to launch” | Gives us publishable first-person voice without a separate interview |
| Specifications block | Play Store URL, price, minimum Android version, developer contact | Every fact an editor needs to write the review accurately |
| Press kit link | Icon, feature graphic, and full-resolution screenshots at a shareable URL | Removes the only remaining reason to delay publication |
| Prior publication evidence | Link to a press release or editorial mention already indexed somewhere | Signals seriousness, provides cross-reference, reduces editorial risk |
That is the complete wishlist. It is not a long list. It is a precise one. Developers who send us all six elements in a single well-formatted email get covered. Developers who send us anything less are asking us to do part of their job for them – and we do not have the editorial capacity to do that on top of our own work.
The submission is not the app. It is the argument that the app deserves editorial attention. Make that argument well and the app gets its chance. Make it poorly and the app never does – regardless of what it could have done if someone had taken the time to present it correctly.
Frequently Asked Questions
How long should an Android app press release be for editorial review submission?
Between 350 and 500 words is the optimal range for a review submission press release. Long enough to cover the lede, three to four feature details, a developer quote, and a specifications block with full contact information. Short enough that an editor can read it completely in under two minutes and make a coverage decision without effort. Longer press releases that bury the essential information in later paragraphs are weaker submissions than shorter ones that front-load every important fact.
Does the developer quote in a press release need to be different from “we are excited to launch”?
Always. “We are excited to launch” is the default quote because it requires no thinking – which is exactly what it communicates to editors who read it. A useful developer quote says something specific: why this problem was worth solving, what surprised you during development, what you learned from beta testing that changed the final product, or what you specifically hope a user feels the first time they open the app. Specific, human quotes get used in articles. Generic excitement statements get deleted and replaced with paraphrase.
Can I submit an app for review before it is live on the Play Store?
Yes, and in many cases pre-launch submission is preferable. Submitting one to two weeks before your Play Store listing goes live gives editors time to review, write, and schedule coverage to go live simultaneously with or immediately after your listing – which is the window when editorial coverage has the most direct impact on launch-day download momentum. Submit with an Early Access link or a TestFlight equivalent if the listing is not yet publicly available, and specify your intended launch date clearly in the submission.
Should I follow up if I receive no response to a press release submission?
One follow-up after five to seven business days is appropriate and professionally expected. Send a brief, single-paragraph email referencing your original submission, confirming the app is still on track for launch, and asking if there is anything additional you can provide. Do not resend the full press release. Do not follow up more than once unless the editor has engaged and requested something specific from you. An unrequested second follow-up within a short window signals the kind of developer behaviour that makes post-publication working relationships difficult.
How do I submit my Android app to Apps4Review for editorial consideration?
Use our app submission page and follow the format guidelines linked there. Include your press release in the body of the submission form or as a plain text attachment, your Play Store link in the first paragraph, a link to your media asset pack, and a link to any prior press coverage already published. Apps that arrive with all six elements of the submission checklist above in place move to the front of our review queue. Browse our existing reviews before submitting to understand the categories and quality standard we apply.
Apps4Review publishes independent editorial app reviews for Android. Submissions are reviewed on an ongoing basis via our submission page. Read our submission guidelines before reaching out – submissions that follow the guidelines are reviewed first.
