01Getting Started
Set Up Your Shared GitHub Repo
Create a new private GitHub repo and have both collaborators clone it. The person who creates the Xcode project should push the initial commit — make sure to add a solid .gitignore for Xcode before anything else, or you'll spend your first hour cleaning up DerivedData.
In Xcode, go to File → New → Project, select SwiftUI App, and initialize git in the same folder as your repo. Push that first commit, then your partner pulls it down. From here on, you're both working from the same source of truth.
# Recommended .gitignore additions for Xcode
.DS_Store
*.xcuserstate
xcuserdata/
DerivedData/
*.hmap
*.ipa
*.dSYM.zip
💡Tip: Enable branch protection on main — neither of you should push directly to main. All work goes through pull requests.
02Claude Code Setup
Wire Up Claude Code on Both Machines
Both collaborators install Claude Code CLI and run it from inside the project directory. The key to keeping your AI pair-programmer in sync across two machines is a shared CLAUDE.md file at the root of the repo. This file tells Claude Code exactly what your project is, your conventions, and anything it should always remember.
Commit this file to git. Every time you learn something — a SwiftUI pattern that works, a convention you've agreed on, a known quirk in your codebase — update CLAUDE.md and push. Your partner pulls it down and now their Claude Code instance knows the same things.
# CLAUDE.md (commit this to git)
## Project
iOS app built with SwiftUI, targeting iOS 17+.
Deployment target: App Store via Xcode Cloud.
## Conventions
- Use @Observable macro over ObservableObject
- All views in /Views, models in /Models
- No force unwraps — use guard let or if let
- Run SwiftLint before every PR
## Known issues
- Avoid modifying ContentView.swift directly
(it's the root coordinator, treat as read-only)
💡Tip: Think of CLAUDE.md as the onboarding doc you wish existed on day one. Keep it honest and update it often.
03Collaboration
A Branching Workflow That Works With AI
Standard Git flow works great with Claude Code. One dev takes a feature, creates a branch, and works with Claude Code locally until it's ready for review. The other dev reviews the PR — and can ask their own Claude Code to explain changes or suggest improvements before merging.
The biggest win: neither of you are blocked waiting for the other. Claude Code keeps you both moving. One person might be building the onboarding flow while the other works on the data layer — no stepping on each other.
# Feature branch workflow
git checkout -b feat/onboarding-flow
# ... work with Claude Code locally ...
git add -p # stage thoughtfully, not git add .
git commit -m "Add onboarding carousel with UserDefaults persistence"
git push origin feat/onboarding-flow
# Open PR → partner reviews → merge to main
💡Tip: Use Claude Code's /review command on your partner's PR before you merge. It catches things human eyes miss.
04Collaboration
Staying in Sync Without Getting in Each Other's Way
The main risk with two devs and two AI assistants is both writing conflicting code at the same time. Avoid working in the same Swift file simultaneously. A quick Slack message — 'I\'m in ProfileView.swift for the next hour' — goes a long way.
Establish file ownership loosely: one person owns the data/networking layer, one owns the UI. Claude Code will generate better suggestions when it has clear context about what's yours to change. Add comments in CLAUDE.md about ownership if you keep running into conflicts.
# In CLAUDE.md — ownership section
## File ownership (soft rules)
Luke: /Views/**, /Components/**
Partner: /Models/**, /Services/**, /Networking/**
Shared: ContentView.swift (coordinate before touching)
💡Tip: If you both need to touch the same file, one person drafts the changes, the other reviews — don't both run Claude Code on it simultaneously.
05Deployment
Preparing for the App Store
Once your app is stable on TestFlight, App Store submission is mostly an Xcode + App Store Connect workflow. Claude Code can help you generate App Store metadata — the description, keyword list, and release notes — just give it context about what your app does and who it's for.
For signing and provisioning: one person should own the Apple Developer account and Certificates. Set up Xcode Cloud (it's free up to 25 hours/month) so every merge to main runs a build automatically. You'll catch issues before they become submission blockers.
# Prompt Claude Code for App Store copy
"Write an App Store description for our app.
It does [X]. Target audience is [Y].
Keep it under 4000 characters, lead with the
value proposition, no buzzwords."
💡Tip: Submit to TestFlight first and get 5–10 real users. App Store review goes smoother when you've already caught the edge cases.
06Tips
Lessons From Building This Way
Claude Code is a force multiplier, not an autopilot. Review every change it makes like you'd review a PR from a fast, knowledgeable junior dev — it's usually right, but it doesn't know your users the way you do.
The best prompts are specific to your codebase. 'Add a loading state to ProfileView using our existing LoadingView component in /Components/LoadingView.swift' gets you further than 'add a loading state.' Share good prompts with your partner in a prompts.md file — you'll build up a library of what works for your project.
# prompts.md — share what works
## Useful prompts for this project
Add new screen:
"Create a new SwiftUI view called [Name]View in /Views.
Follow the pattern in HomeView.swift. Add navigation
from the parent view. Use @Observable for state."
Debug a crash:
"This crash appears in [FileName]. Here's the stack trace:
[paste]. Explain the root cause and fix it without
changing the public interface of this type."
💡Tip: When Claude Code gets something wrong, correct it explicitly in the conversation and update CLAUDE.md so it doesn't repeat the mistake.