Sync, validate, and apply App Store metadata with the current asc canonical metadata workflow. Use when updating metadata, localizations, keywords, or migrating legacy fastlane metadata.

asc metadata sync Use this skill to keep App Store metadata in sync with App Store Connect. Prefer the canonical asc metadata workflow for app info and version localization fields. Use the lower level asc localizations and asc migrate commands only when the user specifically needs .strings files or legacy fastlane format metadata. Current canonical workflow 1. Pull canonical metadata If the app has multiple app info records, resolve the app info ID first and pass it explicitly: 2. Edit local files Canonical files are written under: metadata/app info/<locale .json for app level fields: name , subtitle , privacyPolicyUrl , privacyChoicesUrl , privacyPolicyText metadata/version/<version /<locale .json for version fields: description , keywords , marketingUrl , promotionalText , supportUrl , whatsNew Copyright is not a localization field. Manage it with: 3. Validate before upload For subscription apps, include the extra Terms of Use / EULA heuristic: 4. Preview and apply Run a dry run first: Apply after the plan looks correct: Use asc metadata apply when the user wants the apply named command shape for the same canonical files: For a review artifact workflow with explicit approval before mutation, use the metadata review commands introduced in asc 2.6.1: Use asc metadata approve key "version:1.2.3:en US:whatsNew" or scope app info,version when the user wants selective approval artifacts before the guarded apply. Version scoped keys include the App Store version string. Keyword only workflow Use this when only the version localization keywords field should change: For importing keyword research: Quick field updates For one off version localization edits, pass an explicit version selector. Use version id for deterministic updates when you already have it, or version plus platform when working from a version string. For app info fields, prefer the post create setup command: Lower level localization files Use .strings files when the user specifically wants import/export files instead of canonical JSON: For app info localizations: Legacy fastlane metadata Use this only for existing fastlane format trees: Deliverfile metadata path and screenshots path values take precedence and resolve relative to the Deliverfile. With fastlane dir "./fastlane" , use metadata path "./metadata" rather than "./fastlane/metadata" ; the latter resolves to ./fastlane/fastlane/metadata . Fix stale values in the Deliverfile, or remove them to use the conventional metadata/ and screenshots/ directories. Paths outside the selected Fastlane directory fail unless the operator explicitly trusts them with allow external metadata or allow external screenshots . Keep those flags off for untrusted imports. Inspect the validation body as well as the process exit: asc migrate validate can return a report with valid: false and a nonzero errorCount while exiting 0. A confirmed import can print status: "partial" with completed stages and failure details while exiting nonzero, so non empty stdout does not mean success. Character limits Field Limit Name 30 Subtitle 30 Keywords 100 comma separated characters Description 4000 What's New 4000 Promotional Text 170 Agent behavior Start with asc metadata pull unless the user specifically asks for .strings or fastlane metadata. Always run asc metadata validate before remote writes. Preview remote changes with dry run when the command supports it. Use asc metadata plan plus approve / status when the user wants a durable review artifact before apply. For quick edits, always pass version id or version plus platform ; do not rely on ambiguous latest version behavior. Keep app info fields and version fields separate. Use output table for human verification and JSON for automation.

asc-metadata-sync