app-store-review

Name: app-store-review
Author: dpearson2699

915stars45forks

How to install app-store-review?

dpearson2699/swift-ios-skills/app-store-review

$npx -y skills add dpearson2699/swift-ios-skills --skill app-store-review

Installs into the current project.

Summary

Audits App Store submission readiness and rejection risk across current review guidelines, PrivacyInfo.xcprivacy and required-reason APIs, privacy labels, ATT, StoreKit payments, metadata, entitlements, widgets, and Live Activities. Use when preparing a submission, responding to

Files · 1

View on GitHub

SKILL.md

1	# App Store Review Preparation
2
3	Catch App Store rejection risks before submission. Treat policy, SDK, privacy, entitlement, payment, and metadata checks as current release evidence rather than durable facts.
4
5	## Contents
6
7	- [Top Rejection Reasons and How to Avoid Them](#top-rejection-reasons-and-how-to-avoid-them)
8	- [PrivacyInfo.xcprivacy -- Privacy Manifest Requirements](#privacyinfoxcprivacy-privacy-manifest-requirements)
9	- [Data Use, Sharing, and Privacy Policy (Guideline 5.1.2)](#data-use-sharing-and-privacy-policy-guideline-512)
10	- [In-App Purchase and StoreKit Rules (Guideline 3.1.1)](#in-app-purchase-and-storekit-rules-guideline-311)
11	- [HIG Compliance Checklist](#hig-compliance-checklist)
12	- [App Tracking Transparency (ATT)](#app-tracking-transparency-att)
13	- [EU Digital Markets Act (DMA) Considerations](#eu-digital-markets-act-dma-considerations)
14	- [Entitlements and Capabilities](#entitlements-and-capabilities)
15	- [Submission Workflow](#submission-workflow)
16	- [Metadata Best Practices](#metadata-best-practices)
17	- [Appeal Process](#appeal-process)
18	- [Common Mistakes](#common-mistakes)
19	- [Review Checklist](#review-checklist)
20	- [References](#references)
21
22	Start every audit by fetching the current App Review Guidelines, Upcoming Requirements, screenshot specifications, required-reason API documentation, and applicable storefront/entitlement payment rules. Record the checked date and source beside each release blocker. Then archive-build and validate the exact submission, separate blockers from cleanup, fix one class of evidence mismatch, and rerun the same checks against the rebuilt archive.
23
24	For prompts about keywords, screenshot captions, product-page metadata, or metadata rejection risk, answer from a compliance angle and explicitly defer keyword research, ranking strategy, conversion optimization, screenshot ordering, and A/B testing to `app-store-optimization`. Keep App Review metadata guidance limited to accuracy, field limits, misleading-content risk, and screenshot compliance. Load the dated format, screenshot, and toolchain facts from [Current Release Requirements](references/review-checklists.md#current-release-requirements).
25
26	For full submission readiness audits, separate blocking upload/review issues from ordinary cleanup. Cross-check privacy manifests, App Store privacy nutrition labels, privacy policy, ATT state, runtime network behavior, and SDK behavior against each other; the declarations and observed behavior must align.
27
28	### Blocking Submission Checks
29
30	Escalate these as blockers before ordinary cleanup:
31
32	- The archive misses the current Xcode or platform SDK upload floor
33	- Unresolved privacy evidence mismatches; reconcile them with the [PrivacyInfo.xcprivacy requirements](#privacyinfoxcprivacy-privacy-manifest-requirements)
34	- Payment paths that fail the [StoreKit rules](#in-app-purchase-and-storekit-rules-guideline-311)
35	- Missing screenshot sets required by the current App Store Connect specification
36	- Review access that fails the Guideline 2.1 completeness evidence below
37
38	## Top Rejection Reasons and How to Avoid Them
39
40	\| Guideline risk \| Release evidence \|
41	\|---\|---\|
42	\| 2.1 completeness \| No placeholders, broken/empty flows, inaccessible hardware-only features, or login gates without working demo credentials and review notes. \|
43	\| 2.3 metadata \| App name, category, description, keywords, and screenshots accurately represent the submitted binary and actual UI. \|
44	\| 4.2 minimum functionality \| The app provides meaningful app-specific value beyond a thin website or trivial duplication of system behavior. \|
45	\| 2.5.1 software requirements \| Archive uses public APIs and does not download code that changes reviewed functionality outside documented exceptions. \|
46
47	Verify these against the current guidelines and the exact archive; do not carry version or screenshot requirements forward from an older release checklist.
48
49	## PrivacyInfo.xcprivacy -- Privacy Manifest Requirements
50
51	A privacy manifest is required when your app code, an executable, a dynamic library, or a third-party SDK uses Apple's required-reason API categories or declares collected data/tracking behavior.
52
53	See: [references/privacy-manifest.md](references/privacy-manifest.md) for the full structure, reason codes, and checklists.
54
55	### Summary
56
57	- Required-reason API categories are file timestamps, system boot time, disk space, active keyboards, and UserDefaults; each requires an approved reason code when used.
58	- Before final submission, re-check Apple's current required-reason API documentation and do not choose broad, convenient, or i

People who liked this also viewed

6 picks

Type

app-store-review

915stars45forks

View on GitHub

How to install app-store-review?

dpearson2699/swift-ios-skills/app-store-review

$npx -y skills add dpearson2699/swift-ios-skills --skill app-store-review

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# App Store Review Preparation
2
3	Catch App Store rejection risks before submission. Treat policy, SDK, privacy, entitlement, payment, and metadata checks as current release evidence rather than durable facts.
4
5	## Contents
6
7	- [Top Rejection Reasons and How to Avoid Them](#top-rejection-reasons-and-how-to-avoid-them)
8	- [PrivacyInfo.xcprivacy -- Privacy Manifest Requirements](#privacyinfoxcprivacy-privacy-manifest-requirements)
9	- [Data Use, Sharing, and Privacy Policy (Guideline 5.1.2)](#data-use-sharing-and-privacy-policy-guideline-512)
10	- [In-App Purchase and StoreKit Rules (Guideline 3.1.1)](#in-app-purchase-and-storekit-rules-guideline-311)
11	- [HIG Compliance Checklist](#hig-compliance-checklist)
12	- [App Tracking Transparency (ATT)](#app-tracking-transparency-att)
13	- [EU Digital Markets Act (DMA) Considerations](#eu-digital-markets-act-dma-considerations)
14	- [Entitlements and Capabilities](#entitlements-and-capabilities)
15	- [Submission Workflow](#submission-workflow)
16	- [Metadata Best Practices](#metadata-best-practices)
17	- [Appeal Process](#appeal-process)
18	- [Common Mistakes](#common-mistakes)
19	- [Review Checklist](#review-checklist)
20	- [References](#references)
21
22	Start every audit by fetching the current App Review Guidelines, Upcoming Requirements, screenshot specifications, required-reason API documentation, and applicable storefront/entitlement payment rules. Record the checked date and source beside each release blocker. Then archive-build and validate the exact submission, separate blockers from cleanup, fix one class of evidence mismatch, and rerun the same checks against the rebuilt archive.
23
24	For prompts about keywords, screenshot captions, product-page metadata, or metadata rejection risk, answer from a compliance angle and explicitly defer keyword research, ranking strategy, conversion optimization, screenshot ordering, and A/B testing to `app-store-optimization`. Keep App Review metadata guidance limited to accuracy, field limits, misleading-content risk, and screenshot compliance. Load the dated format, screenshot, and toolchain facts from [Current Release Requirements](references/review-checklists.md#current-release-requirements).
25
26	For full submission readiness audits, separate blocking upload/review issues from ordinary cleanup. Cross-check privacy manifests, App Store privacy nutrition labels, privacy policy, ATT state, runtime network behavior, and SDK behavior against each other; the declarations and observed behavior must align.
27
28	### Blocking Submission Checks
29
30	Escalate these as blockers before ordinary cleanup:
31
32	- The archive misses the current Xcode or platform SDK upload floor
33	- Unresolved privacy evidence mismatches; reconcile them with the [PrivacyInfo.xcprivacy requirements](#privacyinfoxcprivacy-privacy-manifest-requirements)
34	- Payment paths that fail the [StoreKit rules](#in-app-purchase-and-storekit-rules-guideline-311)
35	- Missing screenshot sets required by the current App Store Connect specification
36	- Review access that fails the Guideline 2.1 completeness evidence below
37
38	## Top Rejection Reasons and How to Avoid Them
39
40	\| Guideline risk \| Release evidence \|
41	\|---\|---\|
42	\| 2.1 completeness \| No placeholders, broken/empty flows, inaccessible hardware-only features, or login gates without working demo credentials and review notes. \|
43	\| 2.3 metadata \| App name, category, description, keywords, and screenshots accurately represent the submitted binary and actual UI. \|
44	\| 4.2 minimum functionality \| The app provides meaningful app-specific value beyond a thin website or trivial duplication of system behavior. \|
45	\| 2.5.1 software requirements \| Archive uses public APIs and does not download code that changes reviewed functionality outside documented exceptions. \|
46
47	Verify these against the current guidelines and the exact archive; do not carry version or screenshot requirements forward from an older release checklist.
48
49	## PrivacyInfo.xcprivacy -- Privacy Manifest Requirements
50
51	A privacy manifest is required when your app code, an executable, a dynamic library, or a third-party SDK uses Apple's required-reason API categories or declares collected data/tracking behavior.
52
53	See: [references/privacy-manifest.md](references/privacy-manifest.md) for the full structure, reason codes, and checklists.
54
55	### Summary
56
57	- Required-reason API categories are file timestamps, system boot time, disk space, active keyboards, and UserDefaults; each requires an approved reason code when used.
58	- Before final submission, re-check Apple's current required-reason API documentation and do not choose broad, convenient, or i

People who liked this also viewed

6 picks

Type