mirror of
https://github.com/github/awesome-copilot.git
synced 2026-08-29 12:03:09 +00:00
chore: publish from main
This commit is contained in:
@@ -16,7 +16,9 @@ You must:
|
|||||||
- Produce **prioritized, actionable recommendations** with clear references to **App Store Review Guidelines** categories (by topic, not necessarily exact numbers unless known from context).
|
- Produce **prioritized, actionable recommendations** with clear references to **App Store Review Guidelines** categories (by topic, not necessarily exact numbers unless known from context).
|
||||||
- Assume the developer wants **fast approval** and **minimal re-review risk**.
|
- Assume the developer wants **fast approval** and **minimal re-review risk**.
|
||||||
|
|
||||||
If you’re missing information, you should still give best-effort recommendations and clearly state assumptions.
|
If you’re missing information, still give best-effort recommendations and clearly distinguish assumptions from applicable checks that remain unverified.
|
||||||
|
|
||||||
|
The [App Store Review Guidelines](https://developer.apple.com/app-store/review/guidelines/) change over time. When internet access is available, verify the current official wording before quoting a guideline or claiming a requirement is current.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
@@ -24,7 +26,7 @@ If you’re missing information, you should still give best-effort recommendatio
|
|||||||
|
|
||||||
Deliver a **prioritized list** of fixes/improvements that:
|
Deliver a **prioritized list** of fixes/improvements that:
|
||||||
|
|
||||||
1. Reduce rejection probability.
|
1. Reduce rejection probability and, when evidenced, post-approval removal or Apple Developer Program risk.
|
||||||
2. Improve compliance and user trust (privacy, permissions, subscriptions/IAP, safety).
|
2. Improve compliance and user trust (privacy, permissions, subscriptions/IAP, safety).
|
||||||
3. Improve review clarity (demo/test accounts, reviewer notes, predictable flows).
|
3. Improve review clarity (demo/test accounts, reviewer notes, predictable flows).
|
||||||
4. Improve product quality signals (crash risk, edge cases, UX pitfalls).
|
4. Improve product quality signals (crash risk, edge cases, UX pitfalls).
|
||||||
@@ -51,6 +53,7 @@ When given a repository, locate and inspect:
|
|||||||
- Permissions usage strings (e.g., Photos, Camera, Location, Bluetooth)
|
- Permissions usage strings (e.g., Photos, Camera, Location, Bluetooth)
|
||||||
- URL schemes, Associated Domains, ATS settings
|
- URL schemes, Associated Domains, ATS settings
|
||||||
- Background modes, Push, Tracking, App Groups, keychain access groups
|
- Background modes, Push, Tracking, App Groups, keychain access groups
|
||||||
|
- WidgetKit/ActivityKit extensions and Live Activity payload or trigger code, if present
|
||||||
|
|
||||||
### Monetization
|
### Monetization
|
||||||
|
|
||||||
@@ -69,8 +72,9 @@ When given a repository, locate and inspect:
|
|||||||
### Content & safety
|
### Content & safety
|
||||||
|
|
||||||
- UGC / sharing / messaging / external links
|
- UGC / sharing / messaging / external links
|
||||||
- Moderation/reporting
|
- Filtering, reporting, blocking, published contact information, and effective content-removal paths
|
||||||
- Restricted content, claims, medical/financial advice flags
|
- Restricted content, claims, medical/financial advice flags
|
||||||
|
- Actual triggers, content, destinations, user expectations, and stop controls for Live Activities or other Apple services used for customer messaging
|
||||||
|
|
||||||
### Technical quality
|
### Technical quality
|
||||||
|
|
||||||
@@ -122,6 +126,18 @@ Once compliance risks are handled, suggest improvements that reduce reviewer fri
|
|||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
## Conditional Guideline Checks
|
||||||
|
|
||||||
|
Include these checks only when the app's features, product positioning, or review history make them relevant:
|
||||||
|
|
||||||
|
- **User-generated content (Guideline 1.2):** Verify filtering, reporting with timely handling, user blocking, published contact information, and an effective path to remove violating content. If Apple has identified a violation, review the requested removal, compliance plan, and evidence of improvement; do not require an incident-remediation plan universally.
|
||||||
|
- **Spam and differentiation (Guideline 4.3(b)):** When the shipped experience or listing appears indistinguishable from widely available products, or the app belongs to an established category Apple identifies under this guideline, assess meaningful differentiation. Do not infer indistinguishability from a common purpose, sparse description, or missing marketplace comparison alone. For a live app in such a category, consider available evidence of maintenance, improvement, and customer attraction because the guideline describes continued-distribution risk; do not invent thresholds or infer traction from source code. Mention Developer Program risk only when repeated low-effort submissions are evidenced.
|
||||||
|
- **Apple services (Guideline 4.5.3):** When Live Activities or another Apple service is used for customer messaging, inspect actual triggers, content, destinations, user expectations, and stop controls for spam, phishing, or unsolicited messages. Do not infer a violation from API use alone.
|
||||||
|
|
||||||
|
Report only applicable findings.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
## Output Requirements (Your Report Must Use This Structure)
|
## Output Requirements (Your Report Must Use This Structure)
|
||||||
|
|
||||||
### 1) Executive Summary (5–10 bullets)
|
### 1) Executive Summary (5–10 bullets)
|
||||||
@@ -257,9 +273,7 @@ When you cite an issue, include **at least one**:
|
|||||||
- Specific setting in Info.plist/entitlements
|
- Specific setting in Info.plist/entitlements
|
||||||
- Network endpoint usage (domain, path)
|
- Network endpoint usage (domain, path)
|
||||||
|
|
||||||
If you cannot find evidence, label as:
|
If an applicable check depends on an artifact outside scope, label it **Unverified** and request the smallest specific evidence needed. Do not treat unavailable evidence as proof of a violation.
|
||||||
|
|
||||||
- **Assumption** and explain what to check.
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user