菜单
Everything that happens after v1 ships. Crash reporting setup, TestFlight feedback processing, version management, the update cycle, and how to maintain an app without breaking what already works. Use this skill after your first App Store submission and for all subsequent updates.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | post-launch |
| description | Everything that happens after v1 ships. Crash reporting setup, TestFlight feedback processing, version management, the update cycle, and how to maintain an app without breaking what already works. Use this skill after your first App Store submission and for all subsequent updates. |
Your app is live. Now keep it alive. This skill covers the ongoing lifecycle.
You need to know when your app crashes in the wild. Set this up before TestFlight distribution.
Tell Claude Code:
Add Firebase Crashlytics to the project using Swift Package Manager.
Configure it in the App struct's init. Follow the Firebase iOS
setup guide. Do NOT modify the .xcodeproj file for build phases.
I'll add the build phase script in Xcode manually.
Important: Firebase requires a GoogleService-Info.plist file and a build phase script. Claude Code should create the Swift integration code, but you add the plist and build phase in Xcode manually (.pbxproj safety rule).
App Store Connect > Your App > Analytics > Crashes. No setup required, but reports are delayed (24-48 hours) and less detailed. Good enough for v1 if you don't want to add Firebase.
TestFlight has built-in feedback: testers take a screenshot, it prompts them to send feedback with the screenshot attached. This arrives in App Store Connect > TestFlight > Feedback.
Tell your testers (your wife, friends):
After collecting feedback, sit down with Claude:
Here's the feedback from TestFlight this week:
- [Tester] said the project list loads slowly with 20+ items
- [Tester] said the delete confirmation doesn't appear sometimes
- [Tester] said dark mode makes the progress ring hard to see
Turn these into specific, actionable tasks I can give to
Claude Code. Prioritize by severity (crashes > broken features
> visual issues > nice-to-haves).
Claude helps you triage. You take the prioritized list into Conductor.
1. Collect TestFlight feedback (ongoing)
2. Triage with Claude chat (weekly or per batch)
3. Prioritize: crashes > bugs > polish > features
4. Create Conductor workspaces for each fix
5. Build, test, merge
6. Bump version, archive, upload to TestFlight
7. Notify testers of new build
8. Repeat
Major.Minor.Patch (e.g., 1.2.3)
Major: Breaking changes or major redesign (2.0.0)
Minor: New features (1.1.0, 1.2.0)
Patch: Bug fixes (1.0.1, 1.0.2)
Build numbers increment with every TestFlight upload. They don't need to be meaningful:
Tell Claude Code:
Bump the version to [X.Y.Z] and increment the build number
in the Xcode project settings. Update the "What's New" text
in APP_SPEC.md with a brief changelog.
1. Identify the bug (crash report, TestFlight feedback, your own testing)
2. Open one Conductor workspace
3. Describe the bug and expected behavior
4. Claude Code fixes, writes a test to prevent regression
5. Build and test via XcodeBuildMCP
6. Manual verification on device
7. Bump patch version (1.0.0 → 1.0.1)
8. Archive and upload to TestFlight
9. After tester verification: release to App Store
1. Design the feature (Figma or description)
2. Update APP_SPEC.md with the new screen/flow
3. Update CLAUDE.md if new conventions are needed
4. Use the screen-by-screen build process (same as v1)
5. Add tests for new logic
6. Regression test: run full test suite, manual check of existing features
7. Bump minor version (1.0.1 → 1.1.0)
8. Archive, TestFlight, verify, release
Every change can break something that already works. As your app grows:
Automated regression prevention:
Manual regression prevention:
Same process as initial submission but faster:
Updates typically review faster than initial submissions (12-24 hours vs 24-48 hours). But plan for the worst case.
If you shipped a critical bug and need the fix live urgently, Apple offers expedited review requests. Use sparingly: one per year as a guideline.
If users need data to sync across devices:
Tell Claude Code:
Set up CloudKit sync for SwiftData. Enable the CloudKit
capability in the project. Use the automatic sync provided
by SwiftData + CloudKit. Test by installing on two devices
with the same Apple ID.
Caveats:
This is a feature addition, not a v1 requirement. Add it when users ask for it.
For understanding how people use your app:
Free, built-in. Shows: downloads, sessions, retention, crash rate, device breakdown. No code required.
Tell Claude Code:
Add [Firebase Analytics / TelemetryDeck] via SPM. Log these events:
- app_open
- project_created
- project_completed
- stitch_count_milestone (every 100 stitches)
- feature_used (with feature name parameter)
TelemetryDeck is privacy-friendly and lightweight. Good for indie apps.
Post-launch, your phone becomes more important:
Morning (phone, Dispatch): "Check for new TestFlight feedback and crash reports. Summarize anything urgent."
During the day (phone, Claude Chat): Plan the next update. Describe new features. Draft the changelog.
Evening (Mac, Conductor): Build the fixes and features planned during the day.
Before bed (phone, Remote Control): Monitor builds, approve merges, send to TestFlight.
Manage Claude Code context windows, resume work across sessions, and maintain continuity when your Mac restarts or sessions expire. Use this skill when starting a new session on an existing project, when context feels stale, or when Claude Code starts making mistakes it shouldn't. Prevents the "Claude forgot everything" problem.
Safe patterns for Claude Code interacting with Xcode projects. Covers .pbxproj protection (critical), XcodeBuildMCP build/test patterns, the RenderPreview visual feedback loop, and when to use terminal Claude Code vs Xcode's built-in Claude Agent. Use this skill throughout the entire build process. The .pbxproj rule alone prevents hours of wasted debugging.
Git conventions for parallel Claude Code workstreams in Conductor. Covers branching strategy, merge order, conflict prevention, shared file protection, and the checkpoint pattern. Use this skill throughout the build phase, especially when running multiple Conductor workspaces. Prevents the merge conflicts and corrupted state that kill momentum.
Test every screen in BOTH light and dark mode every iteration. The most common iOS legibility bugs only show in one mode, including a specific class of vibrancy-on-pastel-tint failures that produce illegible labels on glass buttons. Use this skill alongside polish-and-refinement during the polish phase, and as a checklist any time you change colors, tints, or glass surfaces.
How strokes, anti-aliasing, and pixel boundaries actually behave in SwiftUI Canvas and Shape rendering. Covers stroke centering, inset-vs-outset, anti-alias-induced flicker on animating strokes, and 1pt vs 0.5pt strokes on retina displays. Use this skill for any app that draws on a grid or canvas — pattern designers, illustration tools, charting, finger-paint, whiteboards, image editors, gauge / dial UIs.
How to actually prove a UI change works before claiming it does. Covers AX-coordinate snapshots over screenshots, tap-by-label over coordinates, simulator state resets between iterations, and the build → screenshot → AX → math-check loop. Use this skill alongside testing-strategy whenever you're verifying a UI fix on simulator. Required reading before claiming any visual fix is "done."