Mobile CI/CD for Claude Code Projects: Fastlane, Signing and Automation

Agentic coding increases the number of changes a team produces. Without automation, release becomes the bottleneck: someone has to build, sign, upload and track every version by hand. This article describes a mobile CI/CD setup that fits Claude Code projects – what the pipeline looks like, how Fastlane and signing fit in, where a headless agent adds value and which guardrails are non-negotiable.

Pipeline architecture

iOS stages need a macOS runner; Android stages run on Linux. Hosted CI services offer both, and some mobile-specific services bundle signing management.

Fastlane lanes worth having

Fastlane remains the common glue for mobile release automation. A compact Fastfile per platform usually needs four lanes:

1. test – runs unit and UI tests (scan on iOS, gradle tasks on Android).
2. beta – increments the build number, builds with gym or Gradle, uploads with pilot (TestFlight) or supply to an internal track.
3. screenshots – snapshot and screengrab driven by UI tests.
4. release – uploads metadata and binary with deliver or supply, without auto-submitting unless you decide otherwise.

Claude Code writes Ruby lane code competently. Give it the exact lane names, the scheme or flavor, and the rule that all credentials come from environment variables. Ask it to add a README section describing each lane so humans can run them locally too.

Signing without leaking keys

iOS: Create an App Store Connect API key for automation instead of using a personal Apple ID with two-factor prompts. For certificates and profiles, fastlane match stores them encrypted in a private repository or cloud bucket and installs them on any runner; alternatively, use Xcode's cloud-managed signing if your setup supports it. The background is in iOS code signing explained.

Android: Use Play App Signing. Your pipeline only needs the upload keystore, base64-encoded in a secret and decoded at build time, plus a Google Cloud service account with Play Console access for uploads.

The rule for agents is simple: the agent may write code that reads secrets; it must never read the secrets. In practice:

• Keep keystores, .p8 keys and match passwords out of the repository and out of the agent's working directory.
• Use Claude Code permission settings to deny reading files such as *.jks, *.p8 or .env, and consider a hook that blocks commands printing environment variables.
• Scope CI secrets to the protected branches and environments that need them, so a pull request from an agent branch cannot exfiltrate them.

More on these risks in security risks of agentic coding.

Running Claude Code inside the pipeline

Claude Code has a headless mode (claude -p) and an official GitHub Actions integration, which makes it usable as a CI step. Useful, low-risk jobs:

• PR review: comment on diffs that add permissions, dependencies or network endpoints.
• Release notes: turn merged PR titles into user-facing "What's new" text for both stores, within the character limits.
• Failure triage: when a build fails, summarize the log and suggest a fix as a comment.
• Metadata checks: flag store texts that mention features missing from the build.

Keep CI agent jobs read-only or limited to comments and branches; give them no access to signing secrets or production deployment. Patterns for project memory and hooks are in Claude Code best practices.

A prompt for generating the pipeline

Asking for "a CI pipeline" produces generic output. A specific request gets you most of the way in one session:

Create a GitHub Actions workflow and Fastlane setup for this iOS and Android app. Lanes: test, beta, release, as described in docs/release.md. iOS runs on a macOS runner with a pinned Xcode version; Android on Ubuntu. Credentials come only from these secret names: ASC_KEY_ID, ASC_ISSUER_ID, ASC_KEY_P8, MATCH_PASSWORD, ANDROID_UPLOAD_KEYSTORE_B64, ANDROID_KEYSTORE_PASSWORD, PLAY_SERVICE_ACCOUNT_JSON. Use least-privilege workflow permissions. Beta runs on pushes to main; release only via manual dispatch. Explain every secret's purpose in docs/release.md. Do not invent secret values or create keys.

Then review the output line by line, run the beta lane once manually and only afterwards enable automatic triggers.

Common failure modes

• Build number collisions when two pipelines upload in parallel – derive the number from the CI run or query the store for the latest one.
• Expired certificates or profiles breaking the beta lane – run match in read-only mode on CI and renew deliberately.
• Outdated Xcode on the runner after Apple raises the minimum SDK – pin the Xcode version and update it consciously.
• Agent-generated workflow files with overly broad permissions – review permissions: blocks and secret usage like any security-relevant code.

Build it or have it built

Setting this up takes an experienced engineer a few days; doing it for the first time often takes weeks of trial and error. appsubmitter.io sets up CI/CD for your iOS and Android apps, handles signing and submission in your own developer accounts and supports you through rejections. If you want your team to understand and own the pipeline long term, the hands-on trainings at neooutput cover agentic coding workflows including automation. For a stack-agnostic view, see CI/CD for AI-generated mobile apps.