App Store Preflight: A Rule Index That Runs Before You Submit

The rejection categories this skill actually covers

Apple's review process rejects apps for reasons that are often visible in the repository long before upload: a missing PrivacyInfo.xcprivacy file, an entitlement declared in Xcode but never used, a subscription screen that shows the monthly price more prominently than the billed amount, or metadata that mentions a competitor platform. App Store Preflight exists to catch those patterns earlier. It is aimed at iOS and macOS developers who submit through Xcode and who want a second pass over the project before they hit submit, not at teams looking for a general static analysis tool. The README frames the goal plainly: catch potential guideline violations before submitting. The scope is narrow by design. The rule set in references/rules/ is organized into five categories (metadata, subscription, privacy, design, entitlements), and each rule maps to a named Apple guideline number. If a rejection reason does not fall into one of those categories, this skill will not see it.

Rules as markdown files, not as a compiler

The mechanism is a directory of markdown documents. Each rule file follows a fixed template: a guideline number, a severity of REJECTION or WARNING, a category, and then four sections (What to Check, How to Detect, Resolution, Example Rejection). The agent reads the rule, applies the detection steps to your project, and reports findings with severity, affected files and resolution steps. That design has a consequence worth stating: the tool has no parser of its own. Detection quality is bounded by how precisely each rule's How to Detect section describes a checkable condition. A rule like privacy_manifest can point at a missing file, which is unambiguous. A rule like minimum_functionality, which targets WebView wrappers and apps with fewer than three screens, requires the agent to judge what counts as a screen. The same file format that makes rules easy to add also makes their reliability uneven, and nothing in the repository enforces a minimum standard of checkability for a new rule.

The five-step loop and where asc fits

The documented workflow is five steps. First, identify the app type and load the matching checklist from references/guidelines/by-app-type/. Second, pull metadata with the asc CLI. Third, scan against the rules in references/rules/. Fourth, report findings with severity, affected files and resolution steps. Fifth, apply fixes and re-run the affected checks. The metadata step is the one with a hard external dependency: the command given is asc metadata pull --app "<APP_ID>" --version "<VERSION>" --dir ./metadata, and the README notes that most metadata examples assume the canonical JSON layout that asc metadata pull writes. If your metadata currently lives in fastlane format, the README's own advice is to adapt the path examples or pull the canonical asc layout first. That is a real migration cost, not a footnote. The skill also leans on the separate app-store-connect-cli-skills repository for metadata sync, so the practical install is two repositories plus the asc binary, which the README installs with brew install asc.

Install and the app-type checklist index

Installation is a single command: npx skills add truongduy2611/app-store-preflight-skills. The references/guidelines/ directory holds an index of the Apple Review Guidelines plus ten app-type checklists, one each for universal submissions, subscriptions and in-app purchases, social and user-generated content, kids category, health and fitness, games, macOS, AI and generative AI, crypto and finance, and VPN. The all_apps.md checklist is described as applying to every submission, which suggests the intended flow is to load all_apps.md plus one type-specific file. The type-specific files matter because the failure modes differ: the kids checklist and the crypto_finance checklist have little overlap. The README does not state how the checklists and the rules interact when they disagree, so treat the checklist as the framing and the rule file as the check.

Metadata rules that assume you know the guideline

The metadata category shows both the strengths and the limits of the approach. review_notes_new_submission targets guideline 2.1 and looks for incomplete review notes: missing screen recording, app purpose, test credentials, external services, regional information or regulatory documents. competitor_terms targets 2.3.1 and searches for Android, Google Play and other competitor brands. china_storefront targets guideline 5 and flags OpenAI, ChatGPT or Gemini references for the China storefront. apple_trademark targets 5.2.5 and covers Apple device images in the icon and Apple trademark misuse. accurate_metadata targets 2.3.4 and checks for device frames in app preview videos. The last two are the interesting ones. An agent can read text and filenames, but detecting a device frame inside a preview video is a visual judgement, and the README does not describe how that detection is performed. If a rule's How to Detect section relies on the agent viewing a video, that rule is only as good as the model running it.

Subscriptions, privacy and entitlements: the checkable end

The subscription rules are the most concrete. missing_tos_pp targets 3.1.2 and checks for Terms of Service and Privacy Policy links in the app or metadata. misleading_pricing targets 3.1.2 as well and flags a monthly price shown more prominently than the billed amount. Both are text and layout checks against files the agent can read. Privacy has two rules: unnecessary_data targets 5.1.1 and looks for required personal data that is not relevant to the app's function, and privacy_manifest targets 5.1.1 and checks for a missing PrivacyInfo.xcprivacy. The privacy manifest check is the cleanest rule in the set because the file either exists at the expected location or it does not. Entitlements has one rule, unused_entitlements, targeting 2.4.5(i), which looks for entitlements declared in the Xcode project that the code never uses. That check requires cross-referencing the entitlements file against source usage, which is the kind of task an agent can do but where a false negative is easy to produce if the usage is indirect.

Where this is the wrong tool

Three cases stand out. First, if your metadata pipeline is fastlane-only and you do not want to introduce asc, the metadata rules will not have the layout they expect. Second, if you want deterministic output, this is not that. The rules are natural-language instructions interpreted by a model, so two runs over the same repository can produce different findings, and there is no test suite or fixture set in the repository to pin behaviour. Third, the rule coverage is a snapshot. Apple changes guidelines, and a rule file that maps to a guideline number does not update itself. The repository shows no release history in the supplied material, so there is no evidence about how quickly rules track guideline changes. For a solo developer shipping once a quarter, that lag is probably tolerable. For a team whose submission cadence depends on the check passing, it is a risk to weigh.

Compared with fastlane's precheck and deliver

The nearest established alternative is fastlane's precheck, which runs a fixed set of metadata validations (including competitor name checks and placeholder text detection) as part of a fastlane lane, and deliver, which uploads metadata and screenshots. The difference in approach is structural. fastlane's checks are code: a fixed list of validations that produce the same output every run. App Store Preflight's checks are documents: a rule directory an agent interprets, which can cover judgement-based conditions like whether an app has minimum functionality, but cannot promise identical output across runs. If you need reproducibility and already run fastlane, precheck covers a narrower but more predictable slice. If you need coverage of guideline areas that precheck does not touch, such as PrivacyInfo.xcprivacy or unused entitlements, this skill's rule directory is the broader set. The two are not mutually exclusive, but running both means maintaining two metadata layouts unless you standardize on the asc pull output.

Adding rules, maintenance and the MIT licence

The extension path is documented and cheap: create a markdown file in the appropriate references/rules/ subdirectory using the template (guideline number, severity, category, then What to Check, How to Detect, Resolution, Example Rejection). There is no build step, no schema validation and no test harness mentioned, so a new rule takes effect as soon as the agent reads the directory. That is the maintenance model in full. The cost you carry is review discipline: someone has to verify that a new rule's detection steps are actually checkable, and someone has to revisit existing rules when Apple renumbers or rewrites a guideline. The project is MIT licensed, which permits commercial use and modification, but the repository contains no warranty or support commitment, and the licence covers the rule text and skill instructions rather than any guarantee about review outcomes. Treat the rules as your own once you fork them, because that is effectively what the licence allows and what the project's update model assumes.

Editorial conclusion

Adopt it if you already submit through the asc CLI and want a structured pass over metadata, subscriptions, privacy and entitlements before upload, and if you are willing to read the rule files to see what each one actually matches. Skip it if your metadata lives only in fastlane format, if you want a binary pass or fail from a compiler-style tool, or if you expect it to detect anything outside the categories listed in references/rules/. Before relying on it, open references/rules/privacy/privacy_manifest.md and references/rules/design/minimum_functionality.md and check whether the detection steps they describe are things an agent can actually see in your repository.

Official sources

1. Issues
2. License: MIT
3. README
4. truongduy2611/app-store-preflight-skills on GitHub