Asc Submission Health

Monitor the health and status of App Store Connect submissions to identify and resolve deployment issues

Asc Submission Health is a community skill for monitoring and maintaining App Store submission readiness, covering metadata completeness validation, compliance checks, screenshot verification, app review guideline adherence, and automated pre-submission health reports.

What Is This?

Overview

Asc Submission Health provides patterns for validating App Store submissions before review. It covers metadata completeness validation that checks all required fields across locales including descriptions, keywords, and support URLs, compliance checks that verify age rating questionnaire completion and export compliance declarations, screenshot verification that ensures all required device sizes have screenshots in every supported locale, app review guideline adherence that flags common rejection reasons before submission, and automated health reports that score submission readiness and highlight issues. The skill enables teams to avoid common App Store rejection reasons.

Who Should Use This

This skill serves release managers validating submission readiness before triggering App Store review, QA teams running pre-submission checklists for compliance and completeness, and iOS teams with frequent rejections wanting to improve submission success rates.

Why Use It?

Problems It Solves

Submissions with missing metadata are rejected adding days to the release timeline. Screenshot gaps for specific device sizes cause review rejection. Export compliance and age rating omissions block submission. Common guideline violations are discovered only after waiting for review feedback.

Core Highlights

Metadata validator checks all required fields across every supported locale. Screenshot auditor verifies coverage for all device display sizes per locale. Compliance checker validates age rating and export declarations are complete. Health scorer generates an overall readiness score with actionable issue details.

How to Use It?

Basic Usage

from dataclasses\
  import dataclass, field

@dataclass
class HealthReport:
  score: int = 100
  issues: list[dict] =\
    field(default_factory=list)
  passed: list[str] =\
    field(default_factory=list)

class SubmissionHealth:
  def __init__(self, api):
    self.api = api

  def check(
    self,
    version_id: str
  ) -> HealthReport:
    report = HealthReport()

    # Check metadata
    self._check_metadata(
      version_id, report)
    # Check screenshots
    self._check_screenshots(
      version_id, report)
    # Check compliance
    self._check_compliance(
      version_id, report)
    # Check build
    self._check_build(
      version_id, report)
    return report

  def _check_metadata(
    self,
    version_id: str,
    report: HealthReport
  ):
    locales = self.api.get(
      f'/v1/appStoreVersions'
      f'/{version_id}/'
      f'appStoreVersion'
      f'Localizations')

    required = [
      'description',
      'keywords',
      'supportUrl']

    for loc in locales:
      attrs = loc[
        'attributes']
      locale = attrs[
        'locale']
      for fld in required:
        if not attrs.get(fld):
          report.issues.append(
            {'type': 'metadata',
             'severity': 'error',
             'locale': locale,
             'field': fld,
             'message':
               f'Missing {fld}'
               f' for {locale}'})
          report.score -= 10
        else:
          report.passed.append(
            f'{locale}/{fld}')

Real-World Examples

REQUIRED_SIZES = {
  'IPHONE_67': 'iPhone 6.7',
  'IPHONE_65': 'iPhone 6.5',
  'IPAD_PRO_129':
    'iPad Pro 12.9',
  'IPAD_PRO_11':
    'iPad Pro 11',
}

def check_screenshots(
  api, version_id: str,
  locales: list[str]
) -> list[dict]:
  issues = []
  for locale in locales:
    sets = api.get(
      f'/v1/appStoreVersion'
      f'Localizations/'
      f'{locale}/'
      f'appScreenshotSets')

    found = {
      s['attributes'][
        'screenshotDisplay'
        'Type']
      for s in sets
      if s['relationships'][
        'appScreenshots'][
        'data']}

    for size_key, label\
        in REQUIRED_SIZES\
          .items():
      if size_key\
          not in found:
        issues.append({
          'locale': locale,
          'size': label,
          'message':
            f'Missing {label}'
            f' screenshots'
            f' for {locale}'})
  return issues

Advanced Tips

Run submission health checks as a CI step after metadata sync to catch issues before they reach the review queue. Track historical rejection reasons to add custom checks that target your app-specific rejection patterns. Weight the health score by severity so blocking issues like missing builds score lower than optional metadata.

When to Use It?

Use Cases

Run a pre-submission health check that validates all metadata, screenshots, and compliance for every locale. Generate a readiness report that blocks CI submission when critical issues are found. Audit screenshot coverage across device sizes after adding a new supported locale.

Related Topics

App Store submissions, metadata validation, app review, screenshot management, and compliance checking.

Important Notes

Requirements

App Store Connect API key with read access to versions and localizations. Version ID for the submission being validated. Device screenshot size requirements for the target app platforms.

Usage Recommendations

Do: run health checks on every release candidate before submitting for review. Include screenshot coverage validation for all supported device sizes. Check compliance declarations early to avoid last-minute submission blocks.

Don't: submit for review before resolving all critical health check issues. Assume metadata from the previous version carries over to new versions without verification. Skip localization checks for languages with small user bases.

Limitations

Health checks cannot predict subjective App Review decisions about design or content. Screenshot dimension validation cannot verify visual content quality or accuracy. Some rejection reasons relate to runtime behavior that static metadata checks cannot detect.