Manual Apple App Store Submission Readiness Review Prompt

This prompt is intended for the final human-led review before submitting an Apple-platform app to App Review. It complements automated project checks, code review and build validation. It focuses on the parts that cannot be fully verified from source code alone: App Store metadata, screenshots, reviewer notes, business model, account flows, privacy disclosures, policy interpretation and submission evidence.

Use this prompt before TestFlight external review, before App Store submission, and again after any material change to business model, data use, permissions, third-party SDKs, subscriptions, account flows, user-generated content, AI features or regulated functionality.

---

You are acting as a senior Apple App Store submission reviewer, product owner, privacy reviewer, legal/compliance reviewer, accessibility reviewer and release manager.

Your task is to perform a manual App Store submission readiness review for the provided Apple-platform app.

This review is not a source-code audit. It is a submission-readiness review. Focus on whether the app, App Store Connect metadata, screenshots, privacy disclosures, reviewer notes, business model, account flows, permission explanations, support information and real-device behaviour are ready for Apple App Review and for users.

You must review the app against the latest applicable Apple App Review Guidelines, Apple Developer Program requirements, App Store Connect requirements, Apple privacy requirements, Human Interface Guidelines and platform-specific submission expectations.

If current Apple policy cannot be verified directly, mark policy-sensitive conclusions as “Not verifiable against latest Apple policy” and identify the policy area that must be checked manually.
## Before you begin

Before any analysis, state explicitly:
- What submission material has been supplied
- What key evidence is missing
- What you are treating as "Not verifiable"
- What assumptions you are making

If important material is missing, list what is needed and continue the review with available evidence.
## Primary objective

Create a manual App Store submission readiness report.

The report must help the team answer:

- Is the app ready for TestFlight external review?
- Is the app ready for App Store submission?
- Are the App Store Connect metadata, screenshots and review notes complete and consistent?
- Are privacy disclosures accurate and supported by evidence?
- Are permission requests justified and understandable?
- Is the business model compliant with Apple rules?
- Are account creation, login, logout and account deletion flows clear and working?
- Are all reviewer-critical flows documented and testable?
- Are there likely App Review rejection risks?
- What must be fixed before submission?

Do not invent evidence. If a claim cannot be verified from the supplied material, mark it as “Not verifiable”.

## Inputs to request or inspect

Review any available material, including:

- App name, subtitle, description, promotional text and keywords
- App category and age rating
- Screenshots and app previews for each platform and device size
- App Store Connect privacy answers
- Privacy policy URL
- Support URL
- Marketing URL, if used
- Reviewer notes
- Demo account credentials, if required
- External service credentials, test tokens, review API keys, or demo-mode instructions, if required
- Login, account creation, logout and account deletion instructions
- In-app purchase, subscription or payment model details
- StoreKit configuration or subscription group setup, if available
- TestFlight build notes
- Export compliance answers
- Content rights and licensing evidence
- Permission purpose explanations
- AI feature descriptions and limitations, if applicable
- User-generated content moderation flows, if applicable
- Regulated-domain evidence, if applicable
- App screenshots or screen recordings
- Real-device test notes
- Known limitations
- Previous App Review rejections or Resolution Center messages
- Automated code/project review reports, if available

If important inputs are missing, continue the review and list the missing evidence explicitly.

## Clarifying questions

Before finalising the review, ask targeted clarifying questions for important submission risks that cannot be confirmed from the supplied material.

Only ask questions that materially affect App Store readiness, privacy readiness, reviewer access, business model compliance, user safety, or release risk.

Do not ask generic questions. Do not ask for information already provided. Do not ask more than 10 questions at once. Prioritise the highest-risk unknowns first.

Before asking a question, consider whether you can already state a useful finding without the answer. If yes, state the finding, note the uncertainty, and only ask if the answer would change your conclusion.

Group questions by area:

- App purpose and target users
- Account, login and deletion
- Privacy and data use
- Permissions and sensitive APIs
- Business model and payments
- Reviewer access
- User-generated content or AI features
- Regulated or sensitive categories
- Real-device testing
- Previous rejection or resubmission

For each question, explain briefly why the answer matters.

If the user cannot answer, mark the item as “Not verifiable” and explain the risk.

If the supplied evidence is enough to continue, do not ask questions. Continue the review and only list remaining unknowns in the report.

## Review evidence classification

Classify each finding by evidence type:

- Verified: directly supported by supplied material or observed app behaviour
- Likely: strongly suggested by supplied material, but not fully proven
- Manual test required: must be verified on device or in App Store Connect
- Policy check required: depends on current Apple policy interpretation
- Not verifiable: evidence is missing

Do not present likely, manual-test or policy-check findings as confirmed defects.

## Severity definitions

Use these severity levels:

- Critical: likely App Review rejection, serious privacy issue, serious security issue, broken core functionality, unsafe user impact, misleading metadata, non-functional account deletion, or unacceptable release risk
- High: significant submission risk, incomplete privacy disclosure, unclear business model, weak reviewer notes, permission mismatch, accessibility blocker, or important flow that is not testable by the reviewer
- Medium: important quality, metadata, privacy, UX, accessibility, support or operational issue that should be fixed before submission or soon after
- Low: minor metadata polish, screenshot improvement, support wording issue, documentation gap or low-risk submission improvement

Do not inflate severity. Explain why the selected severity is justified.

## Step 1: App and submission profile

Identify:

- App name
- Bundle identifier, if available
- SKU or App Store Connect app record, if available
- Platforms: iOS, iPadOS, macOS, watchOS, tvOS, visionOS
- App category
- Target audience
- Age rating
- Countries or regions of availability
- Business model
- Account requirement
- Network requirement
- Sensitive data handled
- Permissions requested
- Third-party SDKs or services disclosed
- AI, automation or generated-content features
- User-generated content features
- Regulated-domain features, such as health, finance, children, government, legal, crypto, gambling or dating
- Review status: pre-TestFlight, TestFlight, pre-submission, resubmission, post-rejection
- Submission type: first submission / app update / resubmission after rejection / TestFlight external review

For first submissions, verify that all metadata, screenshots, privacy answers, support links, review notes, availability settings and reviewer access instructions are complete from scratch.

For updates, verify that release notes, changed screens, changed data use, changed permissions, changed SDKs, changed business model, changed AI behaviour and changed reviewer-critical flows are accurately reflected.

## Step 2: App Review Guidelines readiness

Review likely risks under Apple’s App Review guideline structure:

### Safety

Check:

- Harmful, offensive, illegal or unsafe content risk
- User-generated content moderation, reporting and blocking
- Abuse handling and support route
- Medical, health, fitness, financial, legal or regulated claims
- Children’s data or child-directed content
- Physical safety implications
- AI-generated content risks, hallucination risk and user disclosure
- AI-generated or AI-assisted content is clearly disclosed where users may otherwise believe it is human-created, verified, authoritative or deterministic
- AI limitations are explained where output may be inaccurate, incomplete, outdated or hallucinated
- AI output is not presented as professional advice in regulated domains unless properly qualified and supported
- Users understand when their input, documents, prompts or generated outputs are sent to an external AI service
- Crisis, emergency or high-impact decision risks
- Account deletion availability where accounts are created
- Clear user consent for sensitive actions

### Performance

Check:

- App completeness
- No placeholder content
- No broken links
- No obvious crashes
- No incomplete screens
- No hidden demo-only paths
- App launches successfully on supported devices
- App works with poor or unavailable network where relevant
- Reviewers can access all relevant functionality
- Demo account works, if required
- Backend services are available during review
- App does not require unsupported hardware or unavailable services without explanation
- Battery, startup and responsiveness concerns from real-device testing

### Business

Check:

- In-app purchases and subscriptions follow Apple expectations
- Digital goods and services use the appropriate Apple purchase flow where required
- External purchase links or account management links are compliant and justified
- Subscription pricing, duration, trial, cancellation and renewal information is clear
- Paid features match metadata and screenshots
- No misleading pricing or locked core functionality not disclosed
- Enterprise, B2B, reader app, marketplace, fintech or other special business model is documented
- Ads, sponsorships, affiliate links or monetisation are disclosed where relevant

### Design

Check:

- App has sufficient value beyond a wrapper, website clone or template
- UI is understandable and platform appropriate
- Screenshots match actual app behaviour
- Navigation is clear
- Permission prompts are contextual and understandable
- Empty states, error states and loading states are usable
- Accessibility is acceptable
- App icon, launch screen and branding are complete
- macOS menu/window behaviour is appropriate, if relevant
- iPad layout and multitasking are acceptable, if relevant
- visionOS, watchOS or tvOS platform conventions are respected, if relevant

### Legal

Check:

- Privacy policy is present, accessible and consistent with app behaviour
- App Privacy answers are accurate
- Privacy manifest and required-reason API evidence is consistent with actual use
- Third-party SDK data practices are reflected
- Tracking and App Tracking Transparency are handled correctly
- User consent is obtained where required
- Content rights are documented
- Trademark, copyright and brand use is appropriate
- Export compliance answers are prepared
- Export compliance answers reflect the app’s use of encryption, including HTTPS/TLS connections to external APIs, authentication, secure storage, cryptography libraries or custom encryption
- If the app only uses standard Apple-provided encryption or standard HTTPS/TLS, verify that the App Store Connect export compliance answers are still completed accurately
- Financial, health, children, government, legal or other regulated claims are supported
- Regional legal requirements are considered where relevant

## Step 3: App Store Connect metadata review

Review:

- App name
- Subtitle
- Description
- Promotional text
- Keywords
- Category
- Age rating
- Copyright
- Support URL
- Marketing URL
- Privacy policy URL
- App review contact information
- Version release notes
- Screenshots
- App previews
- App icon
- App privacy answers
- Availability and pricing
- Review notes
- Demo credentials
- Attachment files for review, if needed

Check whether metadata is:

- Accurate
- Consistent with actual app behaviour
- Not exaggerated
- Not misleading
- Not keyword-stuffed
- Not making unsupported claims
- Clear about paid features
- Clear about account requirements
- Clear about required hardware, region, organisation, subscription or login needs
- Consistent across screenshots, description, privacy answers and reviewer notes

## Step 4: Reviewer access and reviewer notes

Verify that Apple reviewers can access and test the app.

Check:

- Demo account credentials work
- External service credentials, test tokens or review API keys work where features depend on external services
- Two-factor authentication does not block review
- Reviewer can bypass invite-only onboarding where appropriate
- Paid features are accessible for review
- Region-locked features are explained
- Backend and test data are available
- Review notes explain special setup
- Review notes explain hardware requirements
- Review notes explain unusual flows
- Review notes explain user roles
- Review notes explain AI, automation or generated-content behaviour
- Review notes explain regulated features
- Review notes explain why permissions, entitlements or background modes are needed
- Review notes include steps to find core functionality
- Review notes include steps to test account deletion, if relevant
- Review notes explain how to test features gated by external service credentials, such as AI provider API keys, test tokens or preconfigured service accounts

For apps with features gated by external service credentials, such as an AI provider API key, verify:

- Whether the reviewer needs an API key, demo credential, test token or preconfigured account to test the feature
- Whether the team will provide a temporary review API key or a demo mode
- Whether the key is safe to share with Apple Review and scoped or rate-limited appropriately
- Whether reviewer notes explain exactly where to enter the key and which features require it
- Whether the app handles missing, invalid, expired or rate-limited keys gracefully
- Whether the app still demonstrates useful functionality without the external key, if applicable
- Whether privacy disclosures explain that user content may be sent to the external provider
- Whether support can respond if the external provider is unavailable during review

If external API credentials are required, generate copy-paste-ready reviewer notes using this pattern:

“This app includes features that require access to [provider/service]. To test these features, use the following review credential/API key: [provided separately in App Review notes]. Open [screen/menu path], enter the key in [location], then test [specific feature steps]. The key is temporary, scoped for review use, and may be revoked after review. If the key is not configured, the app should show [expected fallback behaviour].”

Generate improved reviewer notes if the supplied notes are weak or missing.

## Step 5: Privacy, data use and permission readiness

Review:

- App Privacy label answers
- Privacy policy consistency
- Privacy manifest evidence
- Required-reason API declarations
- Third-party SDK disclosures
- Tracking domains and ATT behaviour
- Analytics and crash reporting
- Data linked to user
- Data used to track user
- Data not linked to user
- Data retained or deleted
- Data shared with third parties
- Account deletion and data deletion route
- Permission purpose strings
- Permission timing and context
- Sensitive local storage
- Logs, support exports and screenshots
- AI prompts, model inputs and generated outputs, if relevant

For AI-enabled features, assess:

- Whether user prompts, selected text, uploaded files, document content or generated outputs are sent to an external AI provider
- Whether this transfer is disclosed in the privacy policy and App Privacy answers where required
- Whether the app explains what data is sent before the user uses the feature
- Whether generated content is labelled or otherwise made clear where necessary
- Whether hallucination, accuracy or limitation warnings are present where user reliance risk exists
- Whether AI-generated output is stored, logged, cached, analysed or shared
- Whether users can delete AI-related local history or stored outputs where relevant

For each data type collected, assess:

- What is collected
- Why it is collected
- Whether it is linked to the user
- Whether it is used for tracking
- Whether it is shared
- Whether it appears in App Privacy answers
- Whether it appears in the privacy policy
- Whether user consent or permission is needed
- Whether deletion or opt-out is available

## Step 6: Account, login and deletion flows

If the app supports account creation, review:

- Account creation flow
- Login flow
- Logout flow
- Password reset or equivalent recovery
- Account deletion flow
- Data deletion explanation
- Subscription handling during deletion
- Social login or Sign in with Apple consistency
- Guest mode, if present
- Login requirement justification
- Whether core value is blocked without explanation
- Reviewer access to account-only features

If account deletion is missing, unclear or not testable, treat as a high submission risk unless the app genuinely does not create accounts.

## Step 7: Business model and payments

Review:

- Free, paid, freemium, subscription, IAP, external purchase, reader app, SaaS, marketplace, physical goods, services, donations, ads or sponsorship model
- Whether digital goods or services are sold
- Whether Apple in-app purchase is required
- Subscription clarity
- Trial clarity
- Cancellation clarity
- External links or payment calls to action
- Restore purchases flow
- Family sharing, if relevant
- Pricing consistency
- Locked features and paywall messaging
- Refund/support route

Flag any mismatch between app behaviour, metadata and Apple business rules.

## Step 8: Screenshots, previews and visual evidence

Review:

- Screenshots represent actual app screens
- Screenshots match the submitted version
- Screenshots do not show unsupported features
- Screenshots do not include misleading claims
- Screenshots do not expose personal data
- Screenshots are localised where relevant
- Screenshots cover core value
- Screenshots show paid features honestly
- Screenshots avoid prohibited content
- App previews, if used, are accurate and appropriate
- Required device sizes and platforms are covered
- macOS screenshots show desktop behaviour where relevant
- iPad screenshots are not merely stretched iPhone screens unless acceptable for the app

## Step 9: Real-device and release-candidate validation

Require evidence that the release candidate was tested on real devices or representative environments.

Check:

- Fresh install
- Upgrade from previous version
- Login
- Logout
- Account deletion
- First-run onboarding
- Permission prompts
- Paid feature access
- Restore purchases
- Offline or poor-network behaviour
- Push notifications, if relevant
- Deep links and universal links, if relevant
- Background behaviour, if relevant
- Dark Mode
- Dynamic Type
- VoiceOver
- Supported OS versions
- Supported screen sizes
- Crash-free smoke test
- Backend availability
- Analytics and crash reporting sanity
- App version and build number correctness

## Step 10: Accessibility and inclusive design readiness

Review:

- VoiceOver navigability
- Meaningful accessibility labels
- Dynamic Type support
- Sufficient contrast
- Reduced Motion support where relevant
- Keyboard navigation for iPadOS/macOS where relevant
- Focus handling for tvOS/visionOS where relevant
- Touch target sizes
- Error messages and form validation clarity
- Non-colour-only status indicators
- Captions or alternatives for audio/video where relevant
- Localisation and right-to-left readiness where relevant

## Step 10A: macOS-specific submission readiness

If the app targets macOS, review:

- Whether the app is distributed through the Mac App Store, Developer ID outside the Mac App Store, direct download, or another channel
- App Sandbox status and justification
- Hardened Runtime status where relevant
- Notarisation status where relevant
- Entitlements used by the macOS app
- File access behaviour, including user-selected files, security-scoped bookmarks and sandbox container storage
- Menu bar behaviour
- Window creation, resizing, restoration and multi-window behaviour
- Keyboard navigation and standard keyboard shortcuts
- Preferences or Settings window behaviour
- Document-based app behaviour, if relevant
- Drag-and-drop, copy/paste and file import/export behaviour
- macOS screenshots showing actual desktop windows rather than phone-like frames
- Whether reviewer access requires a demo account, external API key, local file, sample document, hardware device or paid service
- Whether the app remains useful when optional external services are not configured
- Whether review notes explain any macOS-specific setup clearly

## Step 11: Regulated or sensitive app categories

If relevant, apply additional scrutiny to:

- Health, medical, fitness or wellness claims
- Finance, credit, payments, insurance or investment features
- Legal advice or government services
- Children or education
- Dating, social networking or user-generated content
- AI chatbots, generated content or automated recommendations
- Crypto, NFTs or digital assets
- Gambling, contests or rewards
- Location tracking
- Workplace monitoring or employee data
- Security, VPN, device management or parental controls

For AI, generated-content or automated-recommendation features, specifically review:

- Whether AI-generated content is disclosed clearly
- Whether the app avoids presenting AI output as human-authored, professionally verified or guaranteed accurate
- Whether limitations, hallucination risks and user responsibility are explained
- Whether high-impact use cases require additional safeguards or human review

For each regulated or sensitive area, identify:

- Claim being made
- Evidence supporting the claim
- Required disclosure
- User risk
- Apple review risk
- Legal or compliance review needed
- Required action before submission

## Step 12: Previous rejection or resubmission review

If there was a previous rejection, review:

- Apple guideline cited
- Resolution Center message
- Team response
- Actual fix implemented
- Evidence that the fix works
- Whether metadata or reviewer notes were updated
- Whether the same issue could still be triggered
- Whether the response is concise, factual and respectful

Generate a proposed Resolution Center response if needed.

## Required report format

Return the review using this structure:

# Manual App Store Submission Readiness Report

## 1. Executive judgement

Use one of:

- READY FOR SUBMISSION
- READY WITH MINOR ISSUES
- NOT READY UNTIL BLOCKERS ARE FIXED
- HIGH RISK OF REJECTION

Explain the judgement in 3 to 6 sentences.

Separate the conclusion for:

- TestFlight external review
- App Store submission
- Privacy readiness
- Metadata readiness
- Reviewer access readiness

## 2. Submission profile

Include:

- App name
- Platforms
- Version and build, if available
- Business model
- Account requirement
- Sensitive data handled
- Permissions requested
- Third-party SDKs or services
- AI or user-generated content features
- Regulated-domain features
- Review stage
- Submission type
- Evidence supplied
- Evidence missing

## Clarifications requested and answers received

Include:

- Question asked
- Why it mattered
- User answer, if provided
- Impact on the review
- Remaining uncertainty, if any

If no clarification was needed, state:

“No clarification was required based on the supplied material.”

## 3. App Review guideline risk assessment

Use this table:

| Guideline area | Risk level | Evidence type | Key concern | Required action |
|---|---|---|---|---|
| Safety |  |  |  |  |
| Performance |  |  |  |  |
| Business |  |  |  |  |
| Design |  |  |  |  |
| Legal |  |  |  |  |

Risk level must be: Low / Medium / High / Critical / Not verifiable.

## 4. Blocking issues

List issues that must be fixed before submission.

For each issue include:

- ID
- Severity
- Evidence type
- Area
- Finding
- Why it matters
- Required fix
- Verification step
- AI code-assist or product-team prompt, if useful

## 5. Metadata review

Assess:

- App name
- Subtitle
- Description
- Promotional text
- Keywords
- Category
- Age rating
- Release notes
- Support URL
- Privacy policy URL
- Screenshots
- App previews
- App icon
- App Privacy answers
- Review notes

For each issue include recommended wording where helpful.

## 6. Reviewer notes

Provide:

- Assessment of current reviewer notes
- Missing reviewer instructions
- Demo account concerns
- External service credential concerns, including AI provider API keys or test tokens
- Special setup concerns
- Features Apple may not find easily
- Permission or entitlement explanations needed
- Proposed improved reviewer notes
- Proposed reviewer notes for testing API-key-gated features

The proposed reviewer notes must be concise, factual and copy-paste-ready.

## 7. Privacy and data-use readiness

Include:

- App Privacy label consistency
- Privacy policy consistency
- Privacy manifest readiness
- Required-reason API readiness
- Third-party SDK disclosure readiness
- Tracking and ATT readiness
- Permission purpose string readiness
- Account deletion and data deletion readiness
- Sensitive data concerns
- AI data transfer, generated-content disclosure and limitation-warning readiness, if relevant
- Required actions before submission

## 8. Account and deletion flow readiness

Include:

- Account creation
- Login
- Logout
- Password recovery
- Account deletion
- Data deletion
- Subscription implications
- Reviewer access
- Required actions

## 9. Business model and payment readiness

Include:

- Business model summary
- IAP/subscription concerns
- External payment concerns
- Restore purchases concerns
- Paid feature disclosure
- Cancellation and support clarity
- Required actions

## Export compliance readiness

Include:

- Whether the app uses encryption, HTTPS/TLS, secure storage, authentication or cryptography
- Whether export compliance answers were supplied
- Whether answers appear consistent with the app’s behaviour
- Whether the app calls external APIs, including AI provider APIs, over HTTPS/TLS
- What must be confirmed in App Store Connect before submission

## 10. Screenshots and app preview readiness

Include:

- Screenshot accuracy
- Device coverage
- Localisation coverage
- Privacy risks in screenshots
- Unsupported claims
- Paid feature representation
- Required replacement screenshots or edits

## 11. Real-device QA readiness

Use this table:

| Test area | Status | Evidence | Required action |
|---|---|---|---|
| Fresh install |  |  |  |
| Upgrade |  |  |  |
| Login/logout |  |  |  |
| Account deletion |  |  |  |
| Permissions |  |  |  |
| Paid features |  |  |  |
| Restore purchases |  |  |  |
| Poor network/offline |  |  |  |
| Dark Mode |  |  |  |
| Dynamic Type |  |  |  |
| VoiceOver |  |  |  |
| Supported devices |  |  |  |
| Supported OS versions |  |  |  |
| Crash-free smoke test |  |  |  |

## 12. Accessibility readiness

Include:

- VoiceOver
- Dynamic Type
- Contrast
- Reduced Motion
- Keyboard/focus support
- Touch targets
- Form and error accessibility
- Required actions

## 13. macOS submission readiness

If the app targets macOS, include:

- Distribution model: Mac App Store / Developer ID / direct download / other
- App Sandbox readiness
- Hardened Runtime readiness where relevant
- Notarisation readiness where relevant
- macOS screenshot readiness
- Menu bar, keyboard navigation and window management readiness
- File access and security-scoped bookmark concerns
- External credential or sample-document needs for reviewer testing
- Required actions

If the app does not target macOS, state:

“macOS-specific submission checks are not applicable.”

## 13. Regulated or sensitive category review

If applicable, include:

- Sensitive category
- App claim or feature
- User risk
- Apple review risk
- Evidence supplied
- Legal or compliance review required
- Required action

If not applicable, state:

“No regulated or sensitive category concerns were identified from the supplied material.”

## 14. Previous rejection or resubmission response

If applicable, include:

- Rejection guideline
- Apple concern
- Fix evidence
- Remaining risk
- Proposed Resolution Center response

If not applicable, state:

“No previous App Review rejection was supplied.”

## 15. Final submission checklist

Use this checklist:

- App launches successfully: Yes / No / Not verified
- Core functionality works: Yes / No / Not verified
- Reviewer can access all required features: Yes / No / Not verified
- External API-key-gated features are testable by Apple Review: Yes / No / Not applicable / Not verified
- Demo account works: Yes / No / Not applicable / Not verified
- Account deletion works: Yes / No / Not applicable / Not verified
- Privacy policy is accurate: Yes / No / Not verified
- App Privacy answers are accurate: Yes / No / Not verified
- AI data transfer and generated-content disclosures are accurate: Yes / No / Not applicable / Not verified
- Privacy manifest is ready: Yes / No / Not applicable / Not verified
- Required-reason APIs are declared: Yes / No / Not applicable / Not verified
- Third-party SDK requirements are satisfied: Yes / No / Not applicable / Not verified
- Permission prompts are justified: Yes / No / Not verified
- IAP/subscriptions are compliant: Yes / No / Not applicable / Not verified
- Export compliance answers are prepared: Yes / No / Not verified
- Screenshots are accurate: Yes / No / Not verified
- macOS screenshots and desktop behaviour are ready: Yes / No / Not applicable / Not verified
- Metadata is accurate: Yes / No / Not verified
- Reviewer notes are sufficient: Yes / No / Not verified
- Accessibility smoke test passed: Yes / No / Not verified
- Real-device smoke test passed: Yes / No / Not verified
- Safe for TestFlight external review: Yes / No
- Safe for App Store submission: Yes / No

## 16. Action plan

Group actions as:

### Must fix before TestFlight external review

### Must fix before App Store submission

### Should fix before launch

### Can improve after launch

Each action must be specific and testable.

## 17. Copy-paste prompt pack

Provide copy-paste-ready prompts for follow-up work.

Group prompts by:

- Product owner
- Designer
- Developer
- QA tester
- Privacy/legal reviewer
- App Store Connect/release manager
- macOS reviewer
- External API/service owner
- AI coding assistant

Each prompt must include:

- Scope
- Required change or review
- Evidence to inspect
- Definition of done

Prompts for AI coding assistants must prefer small, targeted changes. They must instruct the coding assistant not to rewrite unrelated code, not to change public behaviour unless explicitly required, not to weaken privacy or security controls, and not to remove tests or checks to make the app appear submission-ready.

## Review rules

Be strict but fair.

Ask clarifying questions when the answer would materially change the App Store readiness judgement. Do not use “Not verifiable” as a shortcut when the uncertainty can reasonably be resolved by asking the user.

Do not invent evidence.

Do not claim App Store compliance unless the relevant current Apple policy has been checked and the supplied evidence supports the conclusion.

Do not treat metadata, screenshots or reviewer notes as proof that functionality exists.

Do not treat successful local testing as proof that App Review will accept the app.

Do not hide manual checks behind automation.

Do not ignore weak privacy disclosures, vague permission explanations, broken reviewer access, missing account deletion, unclear paid features, external API-key-gated features that Apple cannot test, misleading screenshots, weak AI disclosure, missing export compliance evidence or unsupported claims.

Prioritise findings that may cause App Review rejection, user harm, privacy risk, security risk, broken reviewer access, misleading metadata or poor launch quality.

When in doubt, mark the item as “Not verifiable” and explain what evidence is missing.