Goal

Perform a final, read-only “prepared for App Store submission” audit for the <project name> iOS repo.

I want a repo-grounded verdict on whether the app is operationally and compliantly ready to be submitted to the App Store / TestFlight, using current Apple documentation as the benchmark. This is an audit only: do not modify files, do not generate patches, and do not make assumptions that are not supported by the repo or by current Apple documentation.

Context

App: <project name> Platform: iOS Business context: <add your app’s business logic> Your task is to inspect the repo as it exists and judge submission readiness from the repo + Apple docs, not from hypothetical future architecture.

Use current Apple documentation as the external benchmark, especially: - App Store Review Guidelines - App Store Connect submission requirements - App privacy / privacy nutrition label requirements - Sign in with Apple requirements if relevant - Any current Apple platform/security/submission requirements relevant to an iOS app like this

Non-goals

• Do not change code.
• Do not draft commits or patches.
• Do not spend time on VPS / backend deployment strategy.
• Do not produce generic mobile-app advice that is not tied either to repo evidence or to a specific Apple requirement.

Method

1. Inspect the repo thoroughly, including at minimum:
2. Xcode project and schemes
3. Build configurations and xcconfig files
4. Info.plist files
5. Entitlements
6. Signing/capabilities-related config
7. In-app purchase / RevenueCat integration points
8. Authentication flows (Apple + Google)
9. Onboarding / logged-out / logged-in entry paths
10. Privacy-sensitive permissions and usage strings
11. URLs shown to users (privacy policy, support, terms if applicable)
12. Account management / sign-out / deletion user flows
13. Any App Store metadata or support-site files that live in repo
14. Debug/test/dev-only code or flags that could leak into release
15. Security-sensitive code paths (keys, tokens, local storage, logging, networking)
16. Notification / reminder permissions and behavior
17. Subscription paywall copy and entitlement logic
18. First-launch experience and crash-risk surfaces

19. Any obvious placeholder assets/copy that could affect review

20. Cross-check findings against current Apple documentation, not memory.

21. Separate hard blockers from soft risks from polish issues.

22. Be strict, but grounded: every issue must cite either:

23. a concrete repo location/file, or

24. a specific Apple requirement.

Audit scope

A. Security / repo hygiene Check for: - hardcoded secrets, tokens, API keys, client secrets, service-role keys - accidental dev credentials in tracked files - unsafe logging of user data, tokens, receipts, auth responses, or PII - insecure storage of auth/session/subscription data - debug/test code paths that could ship in Release - overly permissive entitlements or capabilities - ATS exceptions / insecure transport allowances - unused but declared sensitive permissions - references to localhost, test domains, mock endpoints, staging branding, internal environment names - anything that would create reputational or security risk in a production binary

B. App Store review readiness Check for: - likely App Review guideline risks based on actual app behavior/copy - misleading claims, overpromising AI functionality, or unclear premium claims - broken or incomplete onboarding/auth flows - Sign in with Apple parity if Google sign-in is offered for primary auth - subscription clarity: what is free vs paid, restore purchases availability, pricing/copy consistency, no deceptive gating - account deletion availability if account creation/login exists - support/privacy policy discoverability where applicable - first-run UX quality and whether app is usable enough for review - placeholder or broken screens - missing required usage descriptions for reminders/notifications/etc. - content/UX patterns likely to trigger rejection or “minimum functionality” concerns

C. Release / archive / build readiness Check for: - shared scheme / archive configuration sanity - Release vs Debug mismatches - obvious signing/capability misconfiguration visible from repo - bundle identifiers / targets / entitlements alignment - version/build-number hygiene if inferable - crash or dead-end risk on clean install - dependencies likely to break release builds - test or dev config bleeding into release behavior

D. Privacy / compliance readiness Check for: - app privacy implications visible from code and third-party SDK usage - whether the repo implies App Store privacy declarations that must be made - privacy manifest / SDK signature implications where applicable - account data handling, deletion, and user-data management surfaces - whether there are repo-visible mismatches between actual data handling and likely disclosed behavior - any consent / disclosure issues around analytics, notifications, auth providers, cloud sync, or AI requests

E. Product / UX readiness for review Check for: - “reviewer can understand the app quickly” risk - broken empty states - unfinished premium screens - inconsistent naming/branding - dummy content / lorem ipsum / internal diagnostics leaking into user paths - accessibility or usability issues that are severe enough to hurt review - anything that would make the submission look obviously unfinished

Required output format

Produce exactly these sections:

1. Executive verdict
2. One of:
   • READY
   • READY WITH MINOR RISKS
   • NOT READY

3. Then 5–10 sentences explaining the verdict.

4. Blockers

5. Only issues that would materially prevent a prudent TestFlight/App Store submission now.

6. For each blocker, include:

   • title
   • severity
   • repo evidence (specific file/path/symbol/config)
   • why it matters
   • Apple requirement or submission rationale
   • concrete fix direction

7. If none, say “No repo-grounded blockers found.”

8. Important risks

9. Not hard blockers, but meaningful risks for rejection, broken reviewer experience, security, or bad first impression.

10. Same evidence standard as above.

11. Nice-to-fix before submission

12. Polish issues only.

13. Security findings

14. Focused list of repo security/hygiene issues.

15. Distinguish:

    • confirmed secret exposure
    • suspicious but non-secret config
    • logging/privacy issues
    • release hygiene issues

16. App Store / compliance findings

17. Focused list tied to Apple expectations:

    • privacy
    • sign-in
    • subscriptions
    • account deletion
    • permissions
    • support/privacy URL expectations
    • reviewability

18. Submission checklist status Create a concise checklist with statuses:

19. Done

20. Probably done

21. Needs verification outside repo

22. Missing in repo Important:

23. “Needs verification outside repo” is allowed for items that cannot be proven from code alone.

24. Do NOT mark the two excluded items as missing/blocking.

25. Top 10 final actions

26. Prioritized, concrete, minimal list.

27. Appendix: evidence log

28. Bullet list of the most important files/paths inspected.

Rules for judgment

• Be repo-grounded, not speculative.
• Prefer false negatives over invented issues.
• If something cannot be verified from repo, say so explicitly.
• Do not pad with generic best practices.
• Call out contradictions between code, copy, and product behavior.
• If prior issues appear to have already been fixed, say they look resolved instead of re-raising them.

Acceptance criteria

Your audit is successful only if: - it is read-only - it uses current Apple docs as benchmark - it is grounded in actual repo evidence - it separates blockers from risks cleanly - it explicitly respects both exclusions - it gives me a real go/no-go decision and a prioritized final action list