Finish Your Google Play Store Listing During the 14-Day Closed Test, Not on Day 15

From the TestMyApps team.

A lot of developers reach day 14 of their closed test, see that 12 testers stayed opted in, and only then open the store listing. Day 15 goes on writing an 80-character short description and resizing screenshots.

You don't have to lose that day. The closed test is the best time to write the listing, because for two weeks you have people using the app and telling you, in their own words, what it's for.

Quick context: Google's help page on app testing requirements for new personal developer accounts says personal accounts created after November 13, 2023 need a closed test with at least 12 testers opted in continuously for 14 days before they can apply for production. The listing work below fits inside that window.

There's one more reason to start early. Google's "Create and set up your app" help page says your store listing is shared across tracks, including testing tracks. Your testers may already be looking at the listing you haven't finished.

If finding those 12 testers is the part holding you up, we at TestMyApps can get you 12 testers for 14 days: 14 testers for 16 days, from $15. Then the listing can be your only job.

What the main store listing needs

This post covers the main store listing only. Data safety and content rating live under App content and are a separate job.

You'll find the listing at Grow users > Store presence > Store listings. These are the limits from Google's Play Console Help pages as of today:

Two notes from the same pages that are easy to miss:

• Google says the character limits apply to both full-width and half-width characters, so a translated title has the same 30-character ceiling.
• Repetitive or irrelevant keywords in the name or descriptions can lead to suspension. Write for people.

For screenshots to be eligible for some Google Play recommendation formats, Google asks apps for at least four screenshots at a minimum of 1080 px, 9:16 for portrait (at least 1080 x 1920). Capture at that size from the start and you won't redo them.

A day-by-day plan

Tester words on the left, listing copy on the right. Most of the move is editing, not inventing.

Days 1 to 3: listen. Don't write copy yet. Keep a note of the exact phrases testers use when they describe the app or ask about it. "Is there a way to export?" tells you a feature belongs in the description. "I used it to track my runs" tells you what the app is for in plain words.

Days 4 to 6: short description. Turn those phrases into the 80-character line. Google's guidance is to summarise the core purpose in simple language and avoid repeating what the screenshots already say. Write five versions and keep the one a tester would recognise.

Days 7 to 9: full description. Open with what the app does, then the features testers actually used, in the order they found them. Leave out features nobody touched during the test, or move them lower. Google also advises against time-sensitive copy, so skip "new this week".

Days 10 to 11: screenshots. Use the current closed-test build, not an old design. Pick the screens that came up in tester feedback. Google advises against small overlay text, calls to action like "Download now", and time-sensitive taglines, and suggests alt text for each screenshot. Let the UI carry the message.

Day 12: feature graphic and icon. Export the 1024 x 500 feature graphic without transparency and the 512 x 512 icon with it. Google suggests avoiding pure white, black or dark grey backgrounds, which blend into the Play Store.

Days 13 to 14: freeze and check. Proofread, run the length check below, and save. Day 15 is then for the production-access application, not for copywriting.

Keep the listing in your repo

If you already use fastlane, its supply action can download your current listing with fastlane supply init and upload changes later. Per the fastlane docs, the metadata lives in a folder per locale:

fastlane/metadata/android/en-US/ ├── title.txt ├── short_description.txt ├── full_description.txt ├── video.txt ├── changelogs/ │ └── default.txt └── images/ ├── icon.png ├── featureGraphic.png └── phoneScreenshots/ ├── 1.png └── 2.png 

Two cautions from the same docs: supply init needs the app to exist with at least one build uploaded (true once your closed test is running), and uploaded images replace the current ones rather than adding to them.

Then a small script catches the limits before Play Console does:

#!/usr/bin/env bash # check-listing.sh: run from the project root before every listing edit set -uo pipefail export LC_ALL=C.UTF-8 dir="fastlane/metadata/android/en-US" status=0 check_len() { # file, limit local n n=$(printf '%s' "$(cat "$dir/$1")" | wc -m) if (( n > $2 )); then echo "TOO LONG $1: $n/$2"; status=1 else echo "ok $1: $n/$2"; fi } check_len title.txt 30 check_len short_description.txt 80 check_len full_description.txt 4000 # PNG width, height and alpha from the IHDR header (stdlib only) png_info() { python3 -c 'import struct,sys d=open(sys.argv[1],"rb").read(26); w,h=struct.unpack(">II",d[16:24]) print(sys.argv[1].rsplit("/",1)[-1], f"{w}x{h}", "alpha" if d[25] in (4,6) else "no alpha")' "$1" } png_info "$dir/images/icon.png" # want 512x512, alpha png_info "$dir/images/featureGraphic.png" # want 1024x500, no alpha echo "phone screenshots: $(ls "$dir"/images/phoneScreenshots | wc -l) (up to 8 per device type)" exit $status 

Plain text files are easy to review in a pull request, and easy to check before upload.

wc -m counts characters in a UTF-8 locale, which is why the script sets one. Treat it as an early warning; the counter in Play Console has the final say. If you don't use fastlane, keep the same files in a listing/ folder and paste them in by hand.

What this doesn't do

A finished listing doesn't make Google grant production access. That decision is Google's. What it does is give you a calm day 15, and copy that sounds like the people who actually used your app.

If you want the tester side covered while you write, here's how our 14-tester, 16-day run works. It ends with a production-access report, and if Google doesn't approve, you get a free retest, and if it still isn't approved, a refund.