LaunchLint Academy
The short answer
- App Store metadata spans app-level properties and version-specific fields. Some values remain editable, while others depend on the current app or submission status.
- Validate the name, subtitle, keywords, description, screenshots, support and privacy URLs, age rating, review information, and What's New against the exact submitted build.
- Localization is not a word-for-word translation task. Search language, value proposition, screenshots, URLs, and legal information need to work together for each storefront.
1. Inventory every metadata layer first
App Store Connect separates properties shared by the whole app from information attached to a platform version. Name, subtitle, primary language, category, and bundle identity do not follow the same lifecycle as screenshots, description, support URL, What's New, and review notes. Treating everything as one form hides edit restrictions and creates inconsistent submissions.
Build a field matrix before writing copy. Record the owner, locale, source, last update, approval state, and build represented by each value. Mark whether a field is public, private to review, or derived from the binary. This prevents a marketing edit from silently leaving a privacy disclosure, support destination, or review credential behind.
Capture in the matrix:
- App-level versus version-level properties
- Public and review-only information
- Localizable and fixed values
- Editability by submission status
- Owner and approval evidence
- Version and build relationship
2. Choose a precise name, subtitle, and category
Apple's current reference limits both the app name and subtitle to 30 characters. Do not spend those characters on a chain of near-duplicate keywords. Together they should identify the product and explain its primary value without borrowing third-party marks or promising functionality the submitted build does not provide.
Choose the primary category for the app's core job, not for perceived lower competition. Then compare the store name with the installed display name, onboarding, support site, and privacy policy. A reviewer or customer should not have to infer that differently named products are the same service. Check truncated displays and ambiguous translations on real devices.
Name and positioning checks:
- Measure limits with actual Unicode text
- State primary value without unverifiable superlatives
- Avoid third-party marks and platform stuffing
- Choose category by core functionality
- Align installed and store-facing names
- Review localized meanings and truncation
3. Cover search intent without keyword spam
Apple can use the app name, subtitle, keyword field, and developer name for discovery. The keyword field is not a second description. Prioritize terms users employ for the problem, recurring task, and audience. Avoid mechanically repeating strong words already present elsewhere and never insert competitor names merely to attract unrelated impressions.
Create a dedicated keyword set for every language. Literal translation often misses the local query or wastes limited space. Map each candidate to an actual feature and a visible product-page message. A term with no defensible product relationship may increase low-quality impressions while reducing conversion and making the listing look misleading.
Keyword review:
- Problem and task vocabulary
- Audience and technical context
- Local search language rather than literal translation
- No avoidable repetition
- No competitor or unauthorized brand names
- Every term supported by a real feature
4. Align description and promotional text with the build
The description should explain the outcome, major workflows, and material requirements to a person who has never seen the app. Order features by user value rather than the internal roadmap. Claims such as fully anonymous, always offline, or no tracking require especially careful evidence from SDKs, backend behavior, and the production configuration.
Promotional text can be updated without a new version, but it must not advertise a feature absent from the live build. Separate durable product copy from time-limited campaigns. Verify subscription conditions, hardware dependencies, links, and region-specific availability. Never use copy or screenshots from a branch newer than the artifact under review.
Copy approval:
- Outcome before feature inventory
- Requirements and limitations stated
- Absolute privacy and offline claims verified
- Paid capabilities identified
- No future functionality presented as live
- Copy tested against the release build
5. Treat support, marketing, and privacy URLs as product surfaces
A privacy policy URL is required for iOS apps and should open an active public policy. The support URL should lead to real help or contact information rather than an empty homepage. Test every destination while logged out, in a private browser, on mobile, and from an external network. Redirect loops, certificate failures, cookie walls, and geographic blocking can stop review.
The destination pages should identify the app and responsible provider and reflect current practices. Update them alongside store metadata whenever SDKs, account types, purchases, or deletion flows change. Assign monitoring ownership and a repair target for failures. A link working once during copy review is not durable release evidence.
URL preflight:
- HTTPS without certificate errors
- Reachable without login or company VPN
- App and provider clearly identified
- Support contact actively monitored
- Privacy content matches current practices
- Redirects, locale, and mobile layout tested
6. Answer age rating, content rights, and regional questions accurately
The age rating applies across the app and should account for content users can actually reach: user-generated material, web views, ads, medical topics, violence, gambling references, or unrestricted browsing. Do not evaluate only curated demo content. Dynamic feeds and community features can determine the appropriate answer even when onboarding looks harmless.
Confirm rights for third-party brands, music, images, articles, and data feeds. Regional availability can introduce additional declarations. Record the product decision behind each answer and reopen it whenever moderation, audience, or content providers change. A form completed for the first launch does not remain correct by default.
Policy information checks:
- UGC and moderation included
- Web views and external content covered
- Ads and regulated topics assessed
- Rights and licenses documented
- Kids and audience choices consistent
- Regional requirements checked before availability
7. Keep version fields and What's New concrete
Version number, copyright, release settings, screenshots, description, and What's New belong in the release handoff. For updates, What's New should name visible changes instead of repeating bug fixes and improvements. Avoid describing functionality that exists only behind an experiment or in some localized builds unless that condition is explicit.
Review information is private, but it determines whether the submission can be tested. Provide durable credentials, a monitored contact, and concise paths to non-obvious features. If a flow depends on region, role, hardware, or subscription state, explain the exact condition and expected result rather than assuming internal product knowledge.
Version handoff:
- Marketing version and build are unambiguous
- What's New names visible changes
- Release mode selected intentionally
- Review contact can respond
- Credentials tested immediately before submission
- Regions, roles, and feature flags explained
8. Have a second person run the metadata preflight
The strongest final control is an independent walkthrough. Someone who did not prepare the release opens each localization, follows support and privacy links, compares screenshots and copy with the build, and uses the review notes on a clean device. This exposes gaps that character-limit validators and spellcheck cannot detect.
Archive a snapshot of the submitted metadata with version, build, date, and approvers. If review raises an issue, the team can reconstruct exactly what Apple saw. LaunchLint can connect repository signals to known metadata risks, but without authenticated store access it cannot claim to have verified the final App Store Connect state.
Final evidence:
- Every localization opened
- External links tested
- Build and claims compared
- Screenshot order confirmed
- Review access independently followed
- Approved snapshot archived
Frequently asked questions
What are the current app name and subtitle limits?
Apple currently documents a maximum of 30 characters for the name and 30 for the subtitle. Verify the live reference before submission because fields and limits can change.
Can screenshots and descriptions be changed after approval?
Editability depends on the property and app status. Updating approved screenshots generally requires a new version, while some other metadata fields have more flexible rules.
Should I translate the same keywords into every language?
No. Research how the audience actually searches in each market. Literal translations often target a different intent or waste limited characters.
Can LaunchLint fully verify App Store metadata?
Only when the relevant metadata is provided through input or an integration. Repository evidence cannot replace a final review of the values saved in App Store Connect.