When a Local iOS Build Passes but CI's TestFlight Upload Rejects the Signature — Field Notes on match Code-Signing Drift

Step 1: Find out what actually signed the build

Before arguing about causes, confirm — as a matter of fact, read from the file — which certificate and profile the generated .ipa was signed with. Don't guess; read it.

# Unpack the .ipa and pull out the embedded profile
unzip -o MyApp.ipa -d /tmp/ipa_inspect >/dev/null
PROFILE="/tmp/ipa_inspect/Payload/MyApp.app/embedded.mobileprovision"
 
# Decode the profile (a plist)
security cms -D -i "$PROFILE" > /tmp/profile.plist
 
# Profile name, UUID, expiry
/usr/libexec/PlistBuddy -c "Print :Name" /tmp/profile.plist
/usr/libexec/PlistBuddy -c "Print :UUID" /tmp/profile.plist
/usr/libexec/PlistBuddy -c "Print :ExpirationDate" /tmp/profile.plist

The signing certificate itself is visible via codesign:

# The certificate actually signing the binary: Common Name and signing time
codesign -dvvv "/tmp/ipa_inspect/Payload/MyApp.app" 2>&1 | grep -E "Authority|Signed Time"

Cross-reference the Common Name you get here (e.g., Apple Distribution: Your Company (XXXXXXXXXX)) against the certificate marked "valid" in App Store Connect. If the certificate in the CI-built .ipa is the one Apple now considers revoked, that's your answer.

I did this by eye at first, but unpacking the profile every time gets old, so I folded it into the pre-upload gate below.

Step 2: Always run match readonly on CI

The single biggest source of signing drift is CI silently regenerating certificates. When match can't find the target certificate, its default is to issue a new one. A CI-issued certificate eats into Apple's certificate quota (two Distribution certs max) and can even revoke the old one — which instantly invalidates every existing build signed with it.

The principle that prevents this is simple: issue and renew certificates locally only; CI is strictly read-only.

# fastlane/Fastfile
platform :ios do
  desc "Sync certs and profiles (read-only on CI)"
  lane :sync_signing do
    match(
      type: "appstore",
      app_identifier: [
        "com.yourcompany.yourapp",
        "com.yourcompany.yourapp.widget"
      ],
      readonly: is_ci,          # never let CI issue anything new
      keychain_name: ENV["MATCH_KEYCHAIN_NAME"],
      keychain_password: ENV["MATCH_KEYCHAIN_PASSWORD"]
    )
  end
end

readonly: is_ci is the most important line in this article. is_ci is fastlane's helper that auto-detects the CI environment — false locally, true on CI. If CI can't find a certificate, you want it to fail honestly rather than mint a new one, because that failure is the correct signal that says "go renew match locally."

When you do renew, run it explicitly on your machine:

# Local only: issue new certs/profiles and store them in the match repo
bundle exec fastlane match appstore
# Don't forget the Extensions — list every Bundle ID

Step 3: Authenticate with an API key and keep Apple ID passwords off CI

Another drift source is how CI authenticates with your Apple account. Apple ID + password (plus 2FA) breaks reproducibility because the session expires and behavior changes. On CI, standardize on an App Store Connect API key and a clear chunk of signing uncertainty disappears.

# fastlane/Fastfile
platform :ios do
  before_all do
    # Load the key once and share it across every lane
    app_store_connect_api_key(
      key_id: ENV["ASC_KEY_ID"],
      issuer_id: ENV["ASC_ISSUER_ID"],
      key_content: ENV["ASC_KEY_CONTENT"],  # the raw .p8 contents in an env var
      is_key_content_base64: false,
      in_house: false
    )
  end
end

Loading the key in before_all means match, upload_to_testflight, and latest_testflight_build_number all reuse the same credentials. That avoids the failure mode where only the upload step authenticates differently and gets rejected.

Lock down access to the match Git repo too — on CI, use a deploy key or a short-lived read-only token. Not giving CI write access is the same as guaranteeing CI can't rewrite your certificates.

Step 4: A pre-upload gate that inspects the signature

Everything above is prevention, but drift still happens. As a last line of defense, insert a check between build and upload that refuses to proceed if the signature doesn't meet requirements. I asked Antigravity to "write a script that reads the .ipa's embedded profile and signing certificate expiry, and exits 1 on an expired profile or a Bundle ID mismatch," then dropped the result into a fastlane custom action.

# fastlane/actions/verify_signing_action.rb
module Fastlane
  module Actions
    class VerifySigningAction < Action
      def self.run(params)
        ipa = params[:ipa_path]
        expected_ids = params[:app_identifiers]
 
        Dir.mktmpdir do |dir|
          sh("unzip -o #{ipa.shellescape} -d #{dir} >/dev/null")
          app = Dir.glob("#{dir}/Payload/*.app").first
          UI.user_error!("App bundle not found") unless app
 
          profile = "#{app}/embedded.mobileprovision"
          plist = sh("security cms -D -i #{profile.shellescape}")
 
          # Expiry check
          require "time"
          exp = plist[/<key>ExpirationDate<\/key>\s*<date>(.*?)<\/date>/m, 1]
          if exp && Time.parse(exp) < Time.now + 7 * 24 * 3600
            UI.user_error!("Profile expires within 7 days: #{exp}. Renew match locally.")
          end
 
          # Bundle ID check (strip the team prefix from application-identifier)
          app_id = plist[/<key>application-identifier<\/key>\s*<string>(.*?)<\/string>/m, 1]
          bundle = app_id.to_s.sub(/^[A-Z0-9]+\./, "")
          unless expected_ids.include?(bundle)
            UI.user_error!("Signed Bundle ID (#{bundle}) does not match expected #{expected_ids}")
          end
 
          UI.success("Signing verified: #{bundle} / expires #{exp}")
        end
      end
 
      def self.available_options
        [
          FastlaneCore::ConfigItem.new(key: :ipa_path, type: String),
          FastlaneCore::ConfigItem.new(key: :app_identifiers, type: Array)
        ]
      end
 
      def self.is_supported?(platform)
        platform == :ios
      end
    end
  end
end

Wire it into the release lane:

lane :release do
  sync_signing
  build_app(scheme: "MyApp", export_method: "app-store")
 
  # The checkpoint: stopping here avoids dragging existing builds down with it
  verify_signing(
    ipa_path: lane_context[SharedValues::IPA_OUTPUT_PATH],
    app_identifiers: ["com.yourcompany.yourapp", "com.yourcompany.yourapp.widget"]
  )
 
  upload_to_testflight(skip_waiting_for_build_processing: true)
end

The value of this checkpoint is moving the failure ahead of the upload. Hunting for a cause after App Store Connect rejects you is a very different experience from a local step telling you plainly that "the profile is about to expire." Since adding it, I no longer get blindsided by the "for some reason today's upload won't go through" scramble.

Step 5: Recreate the keychain on every GitHub Actions run

If your CI runner is a reused machine, the previous job's certificate can linger in the keychain and get picked up as the stale cert for the build. Even on a clean runner, letting match import into the default keychain leaks state between jobs. The fix is to create a dedicated temporary keychain per job and destroy it on exit.

# .github/workflows/ios-release.yml
name: iOS Release
on:
  workflow_dispatch:
 
jobs:
  release:
    runs-on: macos-15
    steps:
      - uses: actions/checkout@v4
 
      - name: Create a clean temporary keychain
        env:
          KC_PW: ${{ secrets.MATCH_KEYCHAIN_PASSWORD }}
        run: |
          KC="$RUNNER_TEMP/app-signing.keychain-db"
          security create-keychain -p "$KC_PW" "$KC"
          security set-keychain-settings -lut 21600 "$KC"
          security unlock-keychain -p "$KC_PW" "$KC"
          security list-keychains -d user -s "$KC" login.keychain-db
          echo "MATCH_KEYCHAIN_NAME=$KC" >> "$GITHUB_ENV"
 
      - uses: ruby/setup-ruby@v1
        with:
          bundler-cache: true
 
      - name: Build and upload
        env:
          ASC_KEY_ID: ${{ secrets.ASC_KEY_ID }}
          ASC_ISSUER_ID: ${{ secrets.ASC_ISSUER_ID }}
          ASC_KEY_CONTENT: ${{ secrets.ASC_KEY_CONTENT }}
          MATCH_PASSWORD: ${{ secrets.MATCH_PASSWORD }}
          MATCH_KEYCHAIN_PASSWORD: ${{ secrets.MATCH_KEYCHAIN_PASSWORD }}
          MATCH_GIT_BASIC_AUTHORIZATION: ${{ secrets.MATCH_GIT_TOKEN }}
        run: bundle exec fastlane ios release
 
      - name: Always destroy the keychain
        if: always()
        run: security delete-keychain "$RUNNER_TEMP/app-signing.keychain-db" || true

The points that matter: set-keychain-settings -lut 21600 extends the lock timeout, and the final if: always() deletes the keychain even when the job fails. Just not carrying certificate residue into the next job clears up most of the nondeterministic "passed last time, fails on signing this time" failures.

The fastest order to check when you suspect drift

Here's the order I walk every time I suspect drift. Working top to bottom usually lands me on the cause within minutes.

In my experience, most causes land on the combination of 1 and 3 — "someone regenerated the cert locally, but CI's cache is still old."

What this design changes

Try to eradicate signing drift and you'll sink into a swamp. As long as humans renew certificates, drift will occasionally happen. So the goal of these notes isn't to drive it to zero — it's to make sure that when it does drift, it stops quietly before the upload, without taking existing builds down with it.

Pin CI to readonly, move authentication to an API key, and verify the signature before upload. With those three in place, a failure stops being a "release-day incident" and becomes "routine work: just renew match locally." Over a long-lived project, the reproducibility of release work ends up mattering more than the release work itself.

If you try one thing, start with the verification action from Step 4. A single checkpoint in front of the upload takes a surprising amount of the anxiety out of signing.