What the listing check looks at, where the ASO drafts come from, which fields can go live on each store and which wait for a version, how keywords are tracked without invented numbers, and what Publish actually does.
A store listing is the one piece of marketing every app has and almost nobody maintains. The title was written the week before launch, the keywords have not moved since, and the description still mentions a feature that was removed two versions ago. The listing agent is the part of Uprate that reads what is live in both stores, tells you which fields are weak and why, drafts better copy from what your app actually does, and publishes only the fields you approve. In the app it lives under Presence. This is how it works, and where its limits are.
The short version: nothing changes in a store until you press Publish. Drafting, comparing and staging are free on every plan. Pushing a change live is part of the paid plans, and on the App Store most fields cannot go live at all without a new version, which the agent tells you up front instead of pretending otherwise.
What it reads first
When a store is connected with "Store listing & ASO" switched on in Connections, Uprate imports the live listing on its own: every field, every language, and the screenshots. For the App Store that includes the keyword field, which is not on the public page, read through your App Store Connect key. From then on the listing you see in Uprate is a snapshot of the store, and every write re-reads the store first.
The listing agent works per store. App Store Connect and Google Play disagree about almost everything, so each store gets its own workspace with its own fields, limits and rules, and a change to one never silently copies to the other.
The listing check
The first thing to run is the listing check, an ASO audit of the live listing. It looks at the title, the subtitle or short description, the keywords, the description, the screenshots, ratings, how often you ship, which languages you cover and how you compare with tracked competitors. The result is a tier per area, strong, fair or weak, sorted weakest first, and each weak area links straight to the field in the editor where the specific finding is shown. There is no 0 to 100 number, on purpose: 78 against 79 is noise, while "your title uses none of your top keywords" is something you can act on.
The audit runs on the app's public store data plus the private App Store Connect fields when that key is connected, and it is metered per month: one on Free, ten on Indie, fifty on Studio. A first check runs when the listing is imported, and you can re-run it after you change something.
Where the drafts come from
The agent drafts changes as proposals, one field in one language in one store at a time. Each proposal shows the current text and the proposed text with a word-level diff, a rationale, a confidence level and a delivery badge that says when the change would actually land. The context the model gets is bounded and comes from things Uprate already holds: the current listing copy in every language, the latest audit findings, the review themes and rating signals from the review inbox, the keywords you track, and, if you linked the GitHub repository, what the app does according to its README, docs and dependencies. That last one is what keeps a proposal from inventing a feature: capability words that are not backed by store, review or repository evidence get rejected before you see them.
Proposals arrive from several directions. You can ask for a batch from the store workspace. A praised review theme can be turned into a proposal with one click. A quiet daily sweep drafts new ones only when an app has a fresh, meaningful signal, and it stops when you pause it. And two shortcuts work inside the editor: "Draft with AI" rewrites one field in place, and "Ask Copilot" takes one plain-language instruction, "shorter, and lead with the offline mode", and drafts revised values across several fields at once.
Every proposal is clamped to the store's limit before it reaches you, so a title is never 31 characters.
| Field | App Store | Google Play |
|---|---|---|
| Name | 30 characters, changes with the next version | 30 characters, live |
| Subtitle / short description | 30 characters, next version | 80 characters, live |
| Keywords | 100 characters, next version, reviewed by Apple | No keyword field; Play ranks on title and descriptions |
| Description | 4,000 characters, next version, reviewed by Apple | 4,000 characters, live |
| Promotional text | 170 characters, prepared for the next submission | Does not exist |
| Screenshots | Next version, reviewed | Live |
| Store icon | Ships inside the build | 512 × 512, live |
Approving and publishing
You review proposals one by one: approve, edit and approve, or reject. Proposals for the same idea across languages are grouped, so you can accept a subtitle change for all twelve locales at once or dismiss the whole idea. "Publish all safe" takes only the Google Play changes that can go live now and are not low-confidence guesses. Accepted changes collect in a basket, and one Publish button ships the basket for the store you are looking at.
What Publish does depends on the store. On Google Play the copy is written through the Play edits API and is live as far as Uprate is concerned, though Google's own review or Managed publishing may hold it before users see it. Before the write, Uprate re-reads the live listing and refuses to overwrite any field that changed outside Uprate since the last sync; that shows up as drift instead of a silent clobber. Every copy push is recorded in the Activity tab with an undo, single or for the whole batch.
On the App Store, Publish writes the version-bound fields into an editable version in App Store Connect, the same draft version you would prepare by hand, and never submits it for review. The copy waits there until your next release, which is where the submission agent picks it up. While a submission run is writing, building or in review, the listing is locked for the app, because the run owns it.
The agent tells you what a store cannot do A delivery badge on every field says live, next submission or in build. Apple's name, subtitle, keywords and description only change with a new version; the icon only changes with a new binary; Google Play has no keyword field. Nothing in the hub pretends that a change went live when the store does not allow it.
Keywords without invented numbers
The keyword tab tracks the terms you choose, per App Store market. Each tracked keyword gets one real rank reading per day from Apple's public search API, plus two facts read from that same result: difficulty, from how much rating weight sits in the top ten, and whether the App Store's own autocomplete offers the term to people who type its beginning. That autocomplete signal is the closest honest proxy for demand Uprate can observe, because there is no search volume source it is willing to invent. If you connect an Apple Ads account, the popularity index from there is added once a week. Keyword ideas come from your own listing copy and your reviews, each tagged with where it came from, plus model-written terms and spelling variants that only appear once a real rank lookup finds your app for them. Google Play keywords can be tracked as terms, but there is no official rank source, so Uprate shows none.
Languages and screenshots
Adding a language is one action. The agent adapts your existing primary-locale copy into the target language, with the same context and the same limits, and the result is reviewed as one unit: stage every field, discard the draft, or dismiss it. It is an adaptation of your copy, not a translator, and it will not draft a language you have no source copy for.
A daily pass also reads the text inside your live screenshots and compares it with the languages your listing covers, so a German listing with English screenshots shows up as a finding, not a surprise in a review. The Studio tab holds the screenshot sets and icons, imports what is live in the store, and can localize a set into your other languages. On Google Play, screenshots and the store icon are pushed live; on the App Store they are staged for the next version.
Experiments
The Experiments tab is honest about what each store supports. The workhorse is a before-and-after read: install units from the months before a change, the change applied through the normal publish flow, and the months after. Every result carries the same caveat that it is a before-and-after read on monthly data, not a controlled split test, and confidence is never shown as high. Native A/B tests, Apple's Product Page Optimization and Google Play's store listing experiments, are not automated: Uprate drafts the control and challenger variants and tracks the experiment you register in the console.
What it costs
Presence is on every plan, including Free: import, listing check within the monthly audit quota, proposals, staging and undo. A proposal run is 5 credits; the listing check counts against the monthly audit quota rather than credits. Keyword tracking and the screenshot language pass are free. Publishing to a live store is part of the paid plans.
Where this fits
The listing agent is where the review inbox's themes and the submission agent's releases meet. The theory behind the fields is in What is ASO and App Store keyword research, the screenshots in the screenshot guide, and how the three agents divide the work in How to run both stores without a dedicated ops hire.
Was this article helpful?