Automating App Store Metadata QA: Catch Errors Before Submission

Manual App Store metadata QA is one of those tasks that feels fast until it isn't. You're checking character counts on six localizations, making sure no keyword appears in both the title and the keyword field, confirming the subtitle actually fits, and verifying that a promo text change didn't inadvertently wipe a field in a locale you rarely touch. One slip and you're looking at a rejection, a live listing with a truncated title, or weeks of wasted keyword budget on a duplicate term the algorithm already ignores.

Workflow automation fixes this. Not partially — fully. Every validation rule that a human runs manually can be encoded, executed in seconds, and logged before anyone touches the Submit button in App Store Connect or the Google Play Console.

This post walks through building that pipeline: what to validate, how to structure the automation, where to plug it into your existing workflow, and what tooling makes the most sense depending on your team's stack.

Why Manual QA Keeps Failing

The core problem isn't carelessness. It's that App Store metadata has a surprisingly high number of interdependent rules, and humans aren't good at running rule-sets consistently across multiple fields, multiple localizations, and multiple release cycles.

A few failure modes that come up repeatedly in our engagements:

Character limit overflows that aren't obvious. App Store Connect and Google Play Console both enforce limits at save time, but they don't always surface them clearly mid-edit. Copying a title from a doc, pasting it in, and not noticing the count is 32 instead of 30 is extremely common.
Keyword duplication across fields. Apple's algorithm ignores keywords that appear in both the title/subtitle and the keyword field. Teams spend budget on terms that are doing nothing.
Missing fields in secondary localizations. If your base locale is en-US and you have six other localizations, it's easy for a French or Portuguese field to be blank after a metadata refresh.
Promo text treated as permanent copy. Promo text doesn't require a new app submission, so it gets updated ad hoc — and sometimes inconsistently across localizations.
Rating and age-gate mismatches. If you update a content descriptor during resubmission but the metadata file hasn't been updated to match, you can end up with a discrepancy that delays review.

A validation pipeline catches all of these before they reach the stores.

What the Pipeline Needs to Validate

Before writing a single line of automation, document your full rule set. Here's a reference table covering the major fields for both Apple App Store and Google Play:

Field	Apple App Store	Google Play
App Name / Title	30 chars max	50 chars max
Subtitle	30 chars max	N/A
Short Description	N/A	80 chars max
Full Description	4,000 chars max	4,000 chars max
Keyword Field	100 chars max (comma-separated)	N/A (keywords inferred)
Promo Text	170 chars max	N/A
"What's New"	4,000 chars max	500 chars max

Beyond character limits, the rules your pipeline should enforce:

No keyword overlap between title/subtitle and keyword field (Apple)
No repeated keywords within the keyword field (Apple)
No trailing/leading spaces in any field (causes subtle display and indexing issues)
No placeholder text — a regex check for strings like "TBD", "TODO", "Lorem ipsum", or empty brackets
All required localizations populated — compare populated locales against a canonical list
Description doesn't exceed platform-specific formatting rules — Google Play strips unsupported HTML; Apple doesn't render any markup at all
Promo text doesn't duplicate subtitle (Apple) — a common lazy copy-paste error
Age rating consistency — if you track this in your metadata file, validate it matches the declared content descriptors

Pipeline Architecture

The cleanest approach stores your metadata in version-controlled plain text files — one JSON or YAML file per locale — and runs a CI step that validates them on every pull request. Here's the structure that works well in practice.

1. Metadata Source of Truth

Keep all metadata in a /metadata directory at the root of your repo, organized like this:

/metadata
  /ios
    en-US.json
    fr-FR.json
    es-ES.json
  /android
    en-US.json
    fr-FR.json
    es-ES.json

Each file contains every field for that locale. This makes diffing changes trivial — a PR that modifies a title shows exactly what changed, across every locale simultaneously.

2. Validation Script

Write a Node.js or Python script (whichever your team already runs in CI) that imports the field rules as a config object and validates every file against them. The script should:

Load all locale files
Run each field through the rule set
Accumulate all errors (don't bail on the first one — report everything)
Exit with a non-zero code if any errors exist

A simplified Node.js skeleton:

const rules = {
  ios: {
    title: { maxLength: 30, required: true },
    subtitle: { maxLength: 30, required: false },
    keywords: { maxLength: 100, noDuplicates: true, noOverlapWith: ['title', 'subtitle'] },
    promoText: { maxLength: 170, required: false },
    description: { maxLength: 4000, required: true },
    whatsNew: { maxLength: 4000, required: true },
  },
  android: {
    title: { maxLength: 50, required: true },
    shortDescription: { maxLength: 80, required: true },
    description: { maxLength: 4000, required: true },
    whatsNew: { maxLength: 500, required: true },
  }
};

The keyword duplication check is worth spelling out explicitly because it's the most frequently missed:

function checkKeywordOverlap(keywords, titleFields) {
  const kwList = keywords.split(',').map(k => k.trim().toLowerCase());
  const titleWords = titleFields.flatMap(f => f.toLowerCase().split(/\s+/));
  return kwList.filter(kw => titleWords.includes(kw));
}

3. CI Integration

Wire the validation script into GitHub Actions (or whatever CI system you're using) as a required check on any PR that touches the /metadata directory. The job takes roughly two to three seconds to run and blocks the merge if validation fails.

- name: Validate App Store Metadata
  run: node scripts/validate-metadata.js

That's the whole integration. No external service required. No API calls. Just a fast, local script that runs on every change.

If you're also thinking about how to build more sophisticated agent-based automation around your app workflows, the post on AI agent evaluation frameworks covers how to score and validate agent behavior before shipping — the same "validate before it goes live" principle applies directly.

Extending the Pipeline with AI Validation

Character counts and field presence are deterministic rules — easy to automate. But some metadata quality issues are qualitative:

Is the first line of the description compelling enough to function as above-the-fold copy?
Does the subtitle reinforce the title's keyword without repeating it?
Is the "What's New" text actually communicating something useful to a user, or is it boilerplate?

You can add an optional LLM-based review step that runs after the deterministic checks pass. This step doesn't block the PR — it posts a comment with suggestions. Keep the deterministic gate hard and the AI feedback advisory. Mixing them turns the system into something nobody trusts.

A simple prompt structure that works:

You are reviewing App Store metadata for an app called [APP NAME].
Evaluate the following fields for quality. Flag any that are generic, 
unclear, or miss an opportunity to reinforce the primary value proposition.
Do not flag character-limit issues — those are already validated separately.

Title: [VALUE]
Subtitle: [VALUE]
Description (first 200 chars): [VALUE]

Return the output as a structured JSON object with a flags array so it's easy to parse and post as a PR comment.

This kind of hybrid pipeline — deterministic rules as gates, AI as reviewer — is a pattern worth applying beyond metadata. If you want to go deeper on where agent-based automation breaks down in production contexts, Agent Failure Modes: What Breaks Custom AI Agents in Production is worth reading before you invest heavily in the AI layer.

Integrating with Fastlane and Deliver

If your iOS release process already uses Fastlane, you can slot the validation step before deliver runs. Add a custom lane:

lane :validate_metadata do
  sh "node scripts/validate-metadata.js"
end

lane :release do
  validate_metadata
  deliver(
    metadata_path: "./metadata/ios",
    submit_for_review: false
  )
end

This means metadata validation runs every time anyone triggers a release lane — not just on PRs. You're covered at two checkpoints.

For Google Play, the same pattern works with supply. Run the validation before supply uploads the metadata directory.

What a Mature Pipeline Looks Like

Once the basics are in place, teams typically layer in a few more capabilities over subsequent sprints:

Localization completeness scoring — track what percentage of localizations are fully populated across all fields, reported on every build
Keyword density reporting — flag if the keyword field is significantly underutilized (e.g., using only 60 of 100 available characters)
Historical diffing — automatically generate a human-readable summary of what changed between the current metadata and the last submitted version, useful for App Review context
Competitive overlap alerts — compare your keyword field against a manually maintained list of high-value terms to ensure none were accidentally dropped during an edit

None of these require external services. They're all implementable in the same local script, extended incrementally.

Frequently Asked Questions

Does this pipeline work for both App Store Connect and Google Play?

Yes. The validation logic is the same — you just maintain separate rule configs for each platform since the character limits differ. The metadata files live in separate subdirectories (/ios and /android) and the script validates them independently.

Do we need to store metadata in JSON, or can we use another format?

YAML and TOML both work fine. JSON is convenient because most CI environments have native parsing support and it's easy to diff. Pick whatever format your team already works with. The important thing is that the files are version-controlled and text-based, not locked inside a GUI.

What happens if a field is optional and we intentionally leave it blank?

Mark optional fields as required: false in your rule config. The validator skips the presence check for those fields. Promo text is a good example — it's optional on iOS, and many teams legitimately leave it empty outside of active campaigns.

Can this catch issues with screenshots or preview videos?

Not directly, since those are binary assets. But you can extend the pipeline to validate that a screenshot manifest file (listing expected screenshot filenames per device size and locale) is complete, and that the referenced files actually exist in the assets directory. That's a different kind of check but follows the same pattern.

How long does this take to set up from scratch?

In our engagements, a team with an existing CI pipeline and version-controlled metadata can have a working validation script running in under a day. If you're migrating metadata out of App Store Connect's GUI for the first time, budget a sprint to restructure the files and establish the directory convention.

Does this replace human review entirely?

No, and it shouldn't. The pipeline handles deterministic rules and flags qualitative issues for review. A human should still read the metadata before every submission — the automation just ensures they're reading something that already passes the basic checks, so their time is spent on judgment calls, not counting characters.

Metadata errors are entirely preventable. If your team is still doing this manually — running through a checklist in Notion, counting characters in a Google Doc, eyeballing localizations one by one — you're taking on a risk that a few hours of automation work eliminates permanently.

Our mobile app marketing team builds and manages ASO and metadata workflows for apps across categories, including the validation infrastructure that keeps submissions clean. If you want to talk through how this fits into your release process, book a 30-minute call and we'll map it out.