This week I spent a few hours debugging a fastlane CI pipeline that was failing on every single run with Apple provisioning errors. I paired with Claude the entire time. Here's what that actually looks like — not the polished "AI helped me code!" version, but the messy, real one.

The Setup

iOS build pipeline. Fastlane + match for code signing. The CI runner kept blowing up at exportArchive with:

error: exportArchive: requires a provisioning profile with the App Groups feature

Except — the profile absolutely contained the App Groups entitlement. I inspected the decrypted .mobileprovision manually. It was there. Xcodebuild was lying.

Where Claude Actually Helped

I dumped the failing lane, the temp plist gym was generating, and the error into the conversation. Claude caught something I'd missed: when you pass export_options: as a Hash in your Fastfile, gym writes that hash directly to a temp plist — but any plist: key inside the hash is treated as a literal value, not a file reference. The external plist file I was trying to load? Never actually loaded.

The fix was one line: pass export_options: as a path string instead of a hash. Gym then loads the file properly. The patch I'd been writing into the plist at runtime actually started landing.

# Before (broken) — Hash form ignores your plist: key
gym(
  export_options: {
    method: "app-store",
    plist: "RELEASE_exportOptionsPlist_Store.plist"
  }
)

# After (working) — path string makes gym actually load the file
gym(
  export_options: "RELEASE_exportOptionsPlist_Store.plist"
)

The Second Problem

Once that was fixed, the build still failed intermittently. Reason: when match renews a provisioning profile, Apple appends a serial number suffix to the name (e.g. match AppStore com.example.app 1777460891). My Fastfile, pbxproj, and export plist all hardcoded the old name. After any renewal, xcodebuild couldn't find it.

Claude suggested a pattern: after match runs, read the actual installed profile name from the sigh_* environment variable, then patch both pbxproj and the export plist at runtime before the build starts. The dynamic name becomes the single source of truth.

# Read the actual name after match sets it
profile_name = ENV["sigh_#{bundle_id}_appstore_profile-name"]

# Patch pbxproj
system("sed -i '' 's/match AppStore #{bundle_id}.*/#{profile_name}/g' path/to/project.pbxproj")

# Patch export plist
system("/usr/libexec/PlistBuddy -c 'Set :provisioningProfiles:#{bundle_id} #{profile_name}' ExportOptions.plist")

What Made This Work

Claude didn't just hand me code — it helped me build a mental model of what was actually happening. The difference between Hash vs path-string in gym's API is documented somewhere in fastlane's source, but it's not obvious. Same with match's environment variable naming convention.

The conversation was more like pair programming with someone who'd read the entire fastlane codebase than a Stack Overflow search. I'd describe what I was seeing, Claude would reason about what the tool chain was doing internally, and we'd narrow down the root cause.

The commits ended up cleaner too. Because I understood why the fix worked, the commit messages were precise. Co-authored lines show up in git blame: Co-Authored-By: Claude Opus 4.7.

The Honest Take

This isn't magic. It's a multiplier on existing knowledge. If you don't understand code signing at all, Claude's explanations will help but you'll still spend time learning the domain. If you do understand it — like I do — it collapses the debugging loop from hours to minutes.

The gnarly CI/CD problems that used to require tribal knowledge or a very specific Stack Overflow answer from 2019 are now tractable in a single session.

That's the real unlock.