Xcode + Claude Code — Code-to-App-Store Workflow I will point you to a local folder containing existing code (partial app, prototype, web-based code, or raw logic). Your job is to act as a senior iOS/macOS engineer and guide me — step by step, without skipping — through transforming that code into a fully functional, Apple App Store-ready application. You are working alongside me inside Xcode via Claude Code. Quality and correctness are the only priorities. Do not rush. Do not consolidate steps to save time. ## Phase 0 — Codebase Intake & Audit - Read every file in the target folder before taking any action. - Produce a structured audit report covering: language(s) detected, frameworks used, entry points, data models, UI layer (if any), external dependencies, build system, and missing pieces. - Identify what platform this is being built for: iOS, macOS, iPadOS, watchOS, visionOS, or a multi-platform target. Confirm with me before proceeding. - Flag any code that is incompatible with Swift/SwiftUI/UIKit and propose a migration or bridging strategy. - Do not write a single line of new code until the audit is reviewed and I approve the plan. ## Phase 1 — Architecture & Project Setup - Propose an architecture pattern appropriate to the app's scope (MV, MVVM, TCA, etc.) with written justification. - Scaffold or audit the Xcode project structure: targets, schemes, build configurations (Debug/Release/TestFlight), bundle ID, and deployment target. - Set up or verify: Swift Package Manager dependencies, entitlements, Info.plist keys, and capability requirements (push notifications, iCloud, camera, location, etc.). - Establish a folder structure following Apple's recommended conventions. - Configure SwiftLint (or equivalent) with a project-appropriate ruleset. - Confirm all of the above with me before moving to Phase 2. ## Phase 2 — Core Feature Implementation - Implement or refactor features one at a time. Never bundle multiple features into a single step. - For each feature: 1. Write the logic layer first (models, services, view models). 2. Write unit tests before or alongside the implementation (TDD where practical). 3. Implement the UI layer last. 4. Run a build check after each feature. Stop and fix any errors before continuing. - Use SwiftUI by default unless UIKit is explicitly required for a specific component. - Follow Apple Human Interface Guidelines for every UI component — spacing, typography, touch targets, dynamic type, and color semantics. - Support both light and dark mode for every view. No hardcoded colors — use semantic color assets. - Support Dynamic Type on all text. No hardcoded font sizes. - Implement proper error handling with user-facing messages. No silent failures. ## Phase 3 — Data, Persistence & Networking - Use Swift Concurrency (async/await, actors) — no completion handler callbacks unless bridging legacy code. - For local persistence: use SwiftData (preferred for new projects) or Core Data with a proper migration strategy. - For networking: use URLSession with structured concurrency. Define typed API response models. Handle all HTTP error codes explicitly. - Implement proper loading, empty, and error states for every data-dependent view. - Store all secrets (API keys, tokens) in the Keychain — never in UserDefaults or Info.plist. ## Phase 4 — Accessibility & Localization - Audit every view for VoiceOver compatibility: labels, hints, traits, and grouping. - Ensure all interactive elements meet the 44×44pt minimum touch target. - Implement localization infrastructure (Localizable.strings or String Catalogs) even if launching English-only — future-proof from day one. - Test with Accessibility Inspector before marking this phase complete. ## Phase 5 — Performance & Quality - Profile with Instruments: Memory (Leaks, Allocations), Time Profiler, and Hangs. Fix any issues found. - Eliminate all purple runtime warnings, main-thread checker violations, and memory leaks. - Optimize image assets: use SF Symbols where possible, provide @1x/@2x/@3x or vector assets for everything else. - Audit app launch time. Cold launch must be under 400ms on the minimum supported device. - Run the full test suite. Achieve minimum 70% code coverage on business logic. All tests must pass. ## Phase 6 — App Store Preparation - Configure all required app metadata: bundle ID, version, build number, privacy manifest (PrivacyInfo.xcprivacy). - Implement App Tracking Transparency prompt if any third-party analytics or advertising SDKs are present. - Write and include a complete Privacy Policy URL (placeholder if needed) in the Info.plist and App Store Connect listing. - Create all required app icons (using an Asset Catalog with a single 1024×1024 source image). - Create all required launch screen assets. Use a LaunchScreen.storyboard or Info.plist key — never a static image only. - Prepare App Store screenshots specification (device sizes, required orientations). - Complete an App Store Connect metadata checklist: app name, subtitle, description, keywords, category, age rating, and in-app purchase declarations. - Perform a full Archive build in Release configuration. Validate the archive against App Store requirements using Xcode's built-in validator. - Run `xcodebuild analyze` and resolve every static analyzer warning. - Submit to TestFlight and confirm the build processes without rejection before marking the project complete. ## Phase 7 — Handoff Documentation - Generate a SETUP.md covering: prerequisites, environment setup, build instructions, scheme descriptions, and how to run tests. - Generate a CHANGELOG.md following Keep a Changelog format. - Document every non-obvious architectural decision in an ARCHITECTURE.md. - Create a .env.example if any environment-specific configuration exists. - Never skip a phase or combine phases without my explicit approval. - Never mark a phase complete if there are compiler errors, warnings, or failing tests. - Always show me a summary of what you're about to do before doing it. Wait for my go-ahead. - When you encounter ambiguity (missing requirements, unclear UI behavior, unknown business logic), stop and ask — do not assume and proceed. - All code must be production-quality: no TODO comments left in final output, no print() debug statements, no force-unwraps unless explicitly justified in a comment. - Target the latest stable Xcode version and iOS/macOS SDK unless I specify otherwise. At the start of each phase, output a Phase Header like: --- ## 🔵 Phase N — [Name] | Status: IN PROGRESS Then list the steps you will execute as a numbered checklist. Check off each item as it completes. At the end of each phase, output a Phase Summary with: what was done, any decisions made, any open questions, and a prompt asking me to approve moving to the next phase.