Rork × Fastlane × EAS Release Automation Guide — Ship Screenshots, Metadata, and TestFlight/Play Console Builds With One Command

Fastfile design — split lanes by intent, not action

I've found that splitting lanes by intent (what you want to accomplish) rather than by action (what commands you want to run) scales much better. My current Fastfile has six lanes:

• screenshots_ios / screenshots_android: generate screenshots and commit them
• metadata_pull: pull the latest store metadata down into the repo
• metadata_push: push local metadata + screenshots back to the stores
• ios_beta: EAS build → TestFlight upload → metadata sync
• android_beta: EAS build → Internal Testing upload → metadata sync
• release_all: run both beta lanes in parallel, then notify Slack / Discord

Here's the core of my production Fastfile:

# fastlane/Fastfile
default_platform(:ios)
 
fastlane_require 'dotenv'
before_all do
  Dotenv.load '.env.default'
  Dotenv.load '.env.secret' if File.exist?('.env.secret')
  ensure_git_status_clean unless ENV['SKIP_GIT_CHECK']
end
 
desc "iOS TestFlight delivery: EAS build → pilot upload → metadata sync"
lane :ios_beta do
  # 1) EAS Build (--non-interactive keeps behavior identical to CI)
  #    Use the store-distribution profile (`beta` in eas.json). Leaving this on
  #    `preview` produces an Ad-hoc signed build that TestFlight will reject (pitfall 2)
  sh("cd .. && eas build --platform ios --profile beta --non-interactive --wait")
 
  # 2) Grab the latest build artifact URL
  build_json = sh("cd .. && eas build:list --platform ios --limit 1 --json --non-interactive")
  build = JSON.parse(build_json).first
  UI.user_error!("Build history is empty — did `eas build` finish?") if build.nil?
  artifact_url = build.dig("artifacts", "buildUrl")
  UI.user_error!("Build URL not found (status: #{build["status"]})") if artifact_url.to_s.empty?
 
  # 3) Download locally, then upload to TestFlight via pilot
  ipa_path = "/tmp/rork-#{Time.now.to_i}.ipa"
  sh("curl -L -o #{ipa_path} #{artifact_url}")
 
  pilot(
    api_key_path: ENV['APP_STORE_CONNECT_API_KEY_PATH'],
    ipa: ipa_path,
    skip_waiting_for_build_processing: true,
    distribute_external: false,
    changelog: File.read("metadata/ios/en-US/release_notes.txt")
  )
 
  # 4) Sync metadata + screenshots
  deliver(
    api_key_path: ENV['APP_STORE_CONNECT_API_KEY_PATH'],
    submit_for_review: false,
    automatic_release: false,
    skip_binary_upload: true,
    skip_screenshots: false,
    overwrite_screenshots: true,
    force: true
  )
ensure
  File.delete(ipa_path) if ipa_path && File.exist?(ipa_path)
end

The ensure block that deletes the temporary .ipa is intentional. CI runners are throwaway, but I've had my local disk fill up more than once when a run failed mid-way without cleanup.

The dig call is deliberate too. When the most recent build failed, or is still queued, eas build:list returns that build with artifacts set to null. Chaining square brackets crashes with NoMethodError: undefined method for nil at exactly that point, so the friendly UI.user_error! you wrote one line below never runs. Switching to dig and printing status alongside the failure means one glance at the CI log tells you whether the build is still running or whether it died — a distinction worth having at 1 a.m.

Why pilot and deliver are separate

You might wonder why I call pilot and then deliver separately, given that pilot (upload_to_testflight) has some metadata features. The reason is that screenshot replacement only exists on the deliver (upload_to_app_store) side. On top of that, pilot and deliver each manage their own auth token lifetime, so if one fails the other can still progress. Separating them also makes retries idempotent, which matters more than it sounds once you're running this five times a week.

Automated screenshots — the minimal snapshot + UITest setup

The single most painful part of manual releases is "iPhone 6.9-inch / 6.5-inch / 5.5-inch × JA+EN × 5 shots" — thirty screenshots, every release. No amount of willpower makes this fast by hand.

Fastlane's snapshot drives iOS UITests to take screenshots automatically. For Rork + Expo, you'll need to prebuild the iOS project and add a UITest target in Xcode:

# Expo prebuild (once)
npx expo prebuild --platform ios --clean
 
# Open Xcode and add the UITest target
open ios/YourApp.xcworkspace

In Xcode, go File > New > Target... > UI Testing Bundle, then drop the following into ios/YourAppUITests/YourAppUITests.swift:

// ios/YourAppUITests/YourAppUITests.swift
import XCTest
 
class YourAppUITests: XCTestCase {
    override func setUp() {
        continueAfterFailure = false
        let app = XCUIApplication()
        setupSnapshot(app)   // Defined in Fastlane's SnapshotHelper.swift
        app.launchArguments += ["-UITest", "YES"]
        app.launch()
    }
 
    func testTakeScreenshots() {
        let app = XCUIApplication()
 
        // Wait for React Native to finish rendering
        let homeTitle = app.staticTexts["home-title"]
        XCTAssertTrue(homeTitle.waitForExistence(timeout: 8.0))
 
        snapshot("01_Home")
 
        app.buttons["tab-explore"].tap()
        snapshot("02_Explore")
 
        app.buttons["tab-profile"].tap()
        snapshot("03_Profile")
    }
}

The waitForExistence(timeout:) call is load-bearing. React Native takes a moment to load its JS bundle, and if you check .exists on its own, you'll hit a window where the view is rendered but not yet registered in the accessibility tree. The result: a batch of blank white screenshots that you don't notice until you open App Store Connect. I lost a full day to exactly this failure mode the first time.

On the app side, make sure testID values match what UITest looks up:

// app/index.tsx (based on a typical Rork-generated tree)
import { View, Text } from 'react-native';
 
export default function Home() {
  return (
    <View>
      <Text testID="home-title">Welcome back</Text>
      {/* ... */}
    </View>
  );
}

Finally, declare devices and locales in Snapfile:

# fastlane/Snapfile
devices([
  "iPhone 16 Pro Max",       # 6.9 inch
  "iPhone 15 Plus",          # 6.7 inch
  "iPhone 8 Plus"            # 5.5 inch (only if you still support legacy)
])
languages(["ja", "en-US"])
scheme("YourApp")
output_directory("./fastlane/screenshots/ios")
clear_previous_screenshots(true)
stop_after_first_error(true)
concurrent_simulators(true)

concurrent_simulators(true) is 2–3× faster, but below 16 GB of RAM Simulator tends to crash. On Apple Silicon GitHub runners (macos-15 and newer) I keep it on. On local Intel Macs I keep it off.

Metadata sync — deliver lets you version-control your listings

Storing App Store Connect descriptions, keywords, and release notes in Git is a huge quality-of-life upgrade. fastlane deliver init generates a tree like:

• metadata/ios/en-US/name.txt — app name (≤ 30 chars)
• metadata/ios/en-US/subtitle.txt — subtitle (≤ 30 chars)
• metadata/ios/en-US/description.txt — description (≤ 4,000 chars)
• metadata/ios/en-US/keywords.txt — keywords (≤ 100 chars, comma-separated)
• metadata/ios/en-US/release_notes.txt — release notes (≤ 4,000 chars)
• metadata/ios/en-US/promotional_text.txt — promotional text (≤ 170 chars)

Commit these files, and fastlane metadata_push pushes the current versions to App Store Connect. Here's the lane I use:

desc "Push metadata + screenshots to App Store Connect"
lane :metadata_push do
  # Pre-validate: catch character-count overruns before the upload
  validate_metadata_lengths
 
  deliver(
    api_key_path: ENV['APP_STORE_CONNECT_API_KEY_PATH'],
    submit_for_review: false,
    automatic_release: false,
    skip_binary_upload: true,
    skip_metadata: false,
    skip_screenshots: false,
    overwrite_screenshots: true,
    force: true,
    precheck_include_in_app_purchases: false
  )
end
 
def validate_metadata_lengths
  limits = {
    "name.txt" => 30,
    "subtitle.txt" => 30,
    "promotional_text.txt" => 170,
    "keywords.txt" => 100,
    "description.txt" => 4000,
    "release_notes.txt" => 4000
  }
 
  %w[ja en-US].each do |locale|
    limits.each do |file, limit|
      path = "metadata/ios/#{locale}/#{file}"
      next unless File.exist?(path)
      length = File.read(path).strip.length
      if length > limit
        UI.user_error!("#{path}: #{length} chars (limit #{limit})")
      end
    end
  end
end

The custom validate_metadata_lengths exists because deliver doesn't report length errors until upload time, which means you find out from a slow CI run instead of a one-second local check. A lightweight pre-check is worth it.

Why skip_binary_upload: true stays on

You might think "just let deliver upload the IPA too and skip the separate pilot call." In practice, the binary already went up through pilot (TestFlight), so letting deliver re-upload creates a double upload and occasionally crashes on build-number collisions. Always set skip_binary_upload: true explicitly.

Android side — supply puts Play Console under Git control

Android has an equivalent workflow. fastlane supply init --json_key /path/to/service-account.json pulls existing listings into metadata/android/en-US/ and similar directories.

desc "Ship to Android Internal Testing + sync metadata"
lane :android_beta do
  sh("cd .. && eas build --platform android --profile beta --non-interactive --wait")
 
  build_json = sh("cd .. && eas build:list --platform android --limit 1 --json --non-interactive")
  build = JSON.parse(build_json).first
  artifact_url = build&.dig("artifacts", "buildUrl")
  UI.user_error!("Could not resolve the AAB URL") if artifact_url.to_s.empty?
 
  aab_path = "/tmp/rork-#{Time.now.to_i}.aab"
  sh("curl -L -o #{aab_path} #{artifact_url}")
 
  supply(
    json_key: ENV['GOOGLE_PLAY_JSON_KEY_PATH'],
    package_name: ENV['ANDROID_PACKAGE_NAME'],
    aab: aab_path,
    track: "internal",
    release_status: "completed",
    skip_upload_metadata: false,
    skip_upload_images: false,
    skip_upload_screenshots: false,
    validate_only: false
  )
ensure
  File.delete(aab_path) if aab_path && File.exist?(aab_path)
end

The worst Android trap is the first-time track registration. If the internal track has never received a build, supply throws Track is empty and quits. You have to upload the very first AAB manually through the Play Console web UI to "prime" the track. This is a Google API constraint, not a Fastlane one — I spent half a day trying to work around it before realizing there's no workaround at all.

Once that first upload is in place, supply handles every subsequent release automatically.

GitHub Actions — getting secrets in and out safely

The biggest decision when you move to CI is how to handle the App Store Connect API key and the Google Play service account JSON. These are sensitive credentials and must never hit disk persistently.

App Store Connect API Key

Generate the AuthKey_XXXXXX.p8 from App Store Connect → Users and Access → Keys. Base64-encode it, store it as a GitHub Actions secret, and decode on the fly at job start:

# .github/workflows/release.yml
name: Release
 
on:
  workflow_dispatch:
    inputs:
      platform:
        type: choice
        options: [ios, android, both]
        default: both
 
jobs:
  ios:
    if: inputs.platform == 'ios' || inputs.platform == 'both'
    runs-on: macos-15          # Apple Silicon by default. Never macos-latest (pitfall 5)
    steps:
      - uses: actions/checkout@v4
 
      - uses: ruby/setup-ruby@v1
        with:
          ruby-version: '3.3.0'
          bundler-cache: true
 
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
 
      - name: Install dependencies
        run: npm ci
 
      - name: Install EAS CLI
        run: npm i -g eas-cli
 
      - name: Restore App Store Connect API Key
        env:
          ASC_API_KEY_BASE64: ${{ secrets.ASC_API_KEY_BASE64 }}
        run: |
          mkdir -p ~/.appstoreconnect/private_keys
          echo "$ASC_API_KEY_BASE64" | base64 -d > ~/.appstoreconnect/private_keys/AuthKey_${{ secrets.ASC_API_KEY_ID }}.p8
          cat > /tmp/asc_api_key.json <<EOF
          {
            "key_id": "${{ secrets.ASC_API_KEY_ID }}",
            "issuer_id": "${{ secrets.ASC_ISSUER_ID }}",
            "key": "$(cat ~/.appstoreconnect/private_keys/AuthKey_${{ secrets.ASC_API_KEY_ID }}.p8 | base64 -w 0)",
            "in_house": false,
            "is_key_content_base64": true
          }
          EOF
          echo "APP_STORE_CONNECT_API_KEY_PATH=/tmp/asc_api_key.json" >> $GITHUB_ENV
 
      - name: EAS Login
        env:
          EXPO_TOKEN: ${{ secrets.EXPO_TOKEN }}
        run: eas whoami
 
      - name: Fastlane ios_beta
        env:
          FASTLANE_HIDE_CHANGELOG: 1
          FASTLANE_SKIP_UPDATE_CHECK: 1
        run: bundle exec fastlane ios_beta
 
      - name: Cleanup secrets
        if: always()
        run: |
          rm -f /tmp/asc_api_key.json
          rm -rf ~/.appstoreconnect/private_keys

The if: always() on the cleanup step matters — if the job fails, the cleanup still runs, which prevents keys from lingering in artifacts or runner caches. Treat this as non-optional.

Google Service Account JSON

The Play Console service account JSON is the whole credential — base64-encode the file, store it as a secret, decode into /tmp:

  android:
    if: inputs.platform == 'android' || inputs.platform == 'both'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: ruby/setup-ruby@v1
        with:
          ruby-version: '3.3.0'
          bundler-cache: true
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm i -g eas-cli
 
      - name: Restore Google Play JSON key
        env:
          PLAY_KEY_BASE64: ${{ secrets.GOOGLE_PLAY_JSON_KEY_BASE64 }}
        run: |
          echo "$PLAY_KEY_BASE64" | base64 -d > /tmp/google-play-key.json
          echo "GOOGLE_PLAY_JSON_KEY_PATH=/tmp/google-play-key.json" >> $GITHUB_ENV
 
      - name: Fastlane android_beta
        env:
          ANDROID_PACKAGE_NAME: ${{ secrets.ANDROID_PACKAGE_NAME }}
          EXPO_TOKEN: ${{ secrets.EXPO_TOKEN }}
        run: bundle exec fastlane android_beta
 
      - name: Cleanup secrets
        if: always()
        run: rm -f /tmp/google-play-key.json

The service account only needs the "Release Manager" role. Do not grant "Admin" — it would let the key touch other apps in your Play Console account, and that is the kind of accident you do not want to clean up.

Pitfalls — seven landmines I actually stepped on

Here are the issues that cost me hours or days, so you can skip straight past them.

1. Assuming Invalid token means the API key expired

The first time CI started failing with Invalid token, my opening hypothesis was that the App Store Connect API key had expired. That hypothesis cost me half a day, because it is wrong.

The .p8 private key itself has no expiry. What expires is the JWT signed with that key, and Apple caps its lifetime at 20 minutes. Fastlane mints a fresh token during the lane, so this is almost never something you touch directly.

So when Invalid token shows up, work through these three in order instead:

• Mismatched key_id / issuer_id. If you belong to more than one team, it is easy to paste another team's issuer_id into Secrets.
• Someone revoked the key. Common after a credential audit, or when a collaborator cleans house.
• Runner clock drift. If the JWT's iat lands in the future, Apple rejects it immediately. I hit this on a self-hosted runner whose NTP sync had quietly stopped.

Passing a raw PEM while is_key_content_base64: true is set produces the same error, incidentally. Running bundle exec fastlane run app_store_connect_api_key ... once on your own machine before wiring it into CI keeps key problems and CI problems in separate boxes, which is most of the debugging battle.

2. --profile preview is rejected by TestFlight / Play

The preview EAS profile often uses ad-hoc certificates, which TestFlight and Play Console refuse. Create a separate beta profile in eas.json with distribution: "store" and use that for release lanes. Name profiles by intent, not by "which one I copied first."

3. Screenshot dimensions just outside the spec

iPhone 16 Pro Max's native resolution is 1320 × 2868 (3x), but App Store Connect sometimes still expects 1290 × 2796 (the 14 Pro Max / 15 Pro Max baseline). Taking snapshots with the newest simulator produces technically-correct but store-rejected images. Either resize via a Fastlane action (I run one in after_all) or select a device whose native size matches the slot.

4. App Review rejects because no test account was registered

deliver will happily upload demo credentials, but only if you fill in metadata/ios/review_information/demo_user.txt and demo_password.txt. If you push automatic_release: true without these, Review bounces you the same day. Check in placeholder files as part of onboarding so this never happens again.

5. Pinning a runner label that then gets retired

macos-latest eventually bumps Xcode under you, and the day it does, your snapshot tests break. That much is well known.

The sharper edge is that the label you pinned can disappear before you're ready. GitHub's macOS 14 images — including macos-14 and macos-14-xlarge — entered phased deprecation on July 6, 2026 and become fully unsupported on November 2, 2026. During the wind-down, jobs on those labels are deliberately failed at intervals to make the change impossible to miss. This guide originally recommended macos-14-xlarge; if you're building the pipeline today, pin macos-15 instead (Apple Silicon by default), or macos-26 if you want to track the newer image.

Pinning is not a decision you make once. Put a twice-yearly reminder on your calendar to check the actions/runner-images announcements and re-pin. That single habit is what separates "our CI is stable" from "our CI was stable until one Tuesday morning."

6. ensure_git_status_clean fights with Git LFS-tracked screenshots

If your screenshots/ directory uses Git LFS, ensure_git_status_clean can see differences between pointers and actual blobs and fail every run. Either set ENV['SKIP_GIT_CHECK'] = '1' in your Snapfile, or drop LFS for screenshots and use plain Git (a few hundred KB per image is fine).

7. supply CLI args vs Fastfile args are subtly different

--skip-upload-metadata on the command line maps to skip_upload_metadata in the Fastfile — but it's easy to paste a CLI example into a lane and get a mysterious error. Running bundle exec fastlane action supply to check parameter names takes ten seconds and saves the tenth-time-this-week debugging session.

Rollback strategy — safe ways to undo a bad release

The more you automate, the faster a mistake reaches the store. This is boring to plan and terrible to not plan.

Split your CI into two distinct job sets: beta (ios_beta / android_beta) pushing to TestFlight and Internal Testing, and production (ios_release / android_release) that submits to App Review or promotes to Play Production. Let betas bake for 24 hours, and only promote what you've tested. That single discipline covers about 80% of preventable release bugs.

On iOS, when something slips through, the real rollback lives in App Store Connect itself. If the build is still in review, use "Remove from Review"; if it's out and broken, use "Pause Phased Release" or resubmit the previous version. Fastlane doesn't have a native rollback command, but you can build a helper lane that restores previous metadata from Git:

desc "iOS: remove from review and restore previous metadata"
lane :ios_rollback do
  UI.message("⚠️  Manually click 'Remove from Review' in App Store Connect first.")
  UI.message("  Re-run this lane afterward to restore the previous metadata.")
 
  sh("git checkout HEAD~1 -- fastlane/metadata/ios/")
  deliver(
    api_key_path: ENV['APP_STORE_CONNECT_API_KEY_PATH'],
    submit_for_review: false,
    skip_binary_upload: true,
    skip_screenshots: true,
    force: true
  )
  sh("git checkout HEAD -- fastlane/metadata/ios/")  # reset working tree
end

On Android, Play Console's "staged rollout percentage" is the rollback mechanism: set it to 0% via supply and new installs of the broken version stop. Always start your staged rollout at 5% or 10%. A Play release you pushed to 100% cannot really be "undone" — all you can do is ship a fix faster than users notice.

Bind the right backend per profile

One final, unglamorous habit: wire your backend URL through eas.json per profile. beta gets EXPO_PUBLIC_API_URL=https://staging.example.com; only production gets the real URL. I shipped a beta that pointed at production once, wrote bad data into the live DB, and spent the next evening on cleanup. Reviewing the env section in eas.json during release prep is enough to eliminate this failure class entirely.

Secrets hygiene beyond the basics

A pattern that took me a few incidents to adopt: never let the secret hit your terminal or scrollback. echo $ASC_API_KEY_BASE64 | base64 -d at the CI prompt is tempting for debugging, but any action that logs stdout (even indirectly) can surface the content. GitHub Actions masks known secrets in logs, but derived strings — the JSON I assemble inline, for example — are not automatically masked. Two small habits that help:

• Write secrets directly to files in a single shell step and never cat them for debugging. If you must check a secret was loaded, check its length or a SHA256 fingerprint instead.
• Set the file mode to 600 right after writing: chmod 600 /tmp/asc_api_key.json. Runner users are isolated, but this also protects against accidentally copying the file into a build artifact.

I also rotate the EXPO_TOKEN and Google service account every six months. It's overkill for my scale, but it forces me to keep the decryption flow working — a credential you never rotate tends to grow undocumented dependencies.

CI ownership — the hidden cost of automation

One honest caveat: CI is not free, not in money and not in attention. My macOS runner minutes on GitHub Actions cost a few cents per iOS release, so across a year it's a meaningful but not scary line item. What costs more is ownership: when the pipeline breaks, the time debugging is yours, and the cognitive load of "is the pipeline healthy right now?" is a new background task you didn't have before.

Mitigations I've found useful:

• Post release outcomes to a dedicated Slack / Discord channel. Even as a solo developer, having the pipeline announce "iOS beta shipped, build 412" gives me a light touchpoint without requiring me to open GitHub Actions.
• Run a synthetic release once a month. On a quiet Saturday, I run fastlane metadata_push against a dummy app just to verify the tokens are still valid and the pipeline shape still works. This catches ASC API key expiry before it blocks a real release.
• Keep a one-page runbook in the repo. docs/RELEASE.md with "how to run the pipeline", "how to roll back", "where to rotate keys". Future-me is not a good enough reader of present-me's Fastfile without this.

Team collaboration — even if "the team" is just you

"I'm a solo developer, I don't need team collaboration" — I used to think this too. Then I started a second app, then a third, then tried to onboard a contractor for one sprint, and suddenly the lack of explicit team conventions bit hard. A few things are worth setting up now even if you're alone today:

• Store all secrets in a password manager with shareable items. 1Password's "Secure Notes" with fields for key, issuer ID, JSON content, and rotation date keep the ceremony self-documenting. When you do bring in a second pair of hands, you hand them a vault entry instead of a confusing DM thread.
• Use GitHub Environments for Release approval. GitHub Actions' Environments feature lets you require a manual approval before the production submit lane runs. I set this up even as a solo dev — the approval prompt on my phone is the only thing keeping me from accidentally shipping at 3am.
• Document "who owns what" explicitly. If you eventually have anyone help, write down which apps they can touch, which lanes they can run, and what the expected review cadence is. Fastlane's lane-level permissions combined with GitHub's branch protections make enforcement trivial.

I also keep a habit of writing Fastfile comments that a second person could understand on first read. It's 5% more typing and 100% higher chance that future-me thanks past-me.

Real-world cadence — a Tuesday release in practice

To close, here's what my actual weekly release looks like:

• Monday evening (10 min): Run fastlane metadata_pull to sync any web-UI edits (keyword tweaks, etc.) back into Git.
• Tuesday morning (2 min): Write release notes in metadata/ios/ja/release_notes.txt and metadata/android/ja-JP/changelogs/default.txt, machine-translate, edit lightly. Bump the version and push.
• Tuesday midday (8 min of CI wait): Fire the Release workflow with workflow_dispatch. iOS and Android run in parallel; TestFlight and Internal Testing receive builds in around 8 minutes.
• Tuesday afternoon (2 min): In TestFlight and Play Console, promote the beta to a review / production submission.

Total hands-on time: 12–15 minutes. When shipping stops feeling like a chore, you stop delaying features to avoid the chore — which, for an indie developer, is the real win.

Further reading while you build

If you want to tighten your CI/CD loop further, Running OTA updates with EAS Update and Building an EAS Build CI/CD pipeline with GitHub Actions pair naturally with the release pipeline here. Together they give you an end-to-end automation layer from code change to store delivery.

Wrapping up — one small step to take next

You don't need to adopt the whole pipeline at once. Pick any one of the following and try it this weekend:

• Automate screenshots only. Set up fastlane snapshot + a UITest for one device and two locales. You'll cut release prep time roughly in half immediately.
• Move metadata into Git only. Run fastlane deliver init, commit the text files, and start reviewing listing changes in PRs — even against your own past self three months ago, it's surprisingly useful.
• Automate just the upload step. Wire eas build + fastlane pilot (or supply) together so binary uploads become a single command.

Once shipping feels like an implementation detail rather than a ceremony, the gap between "Rork lets me build fast" and "I can actually get it live fast" finally closes. I hope this setup gives you a head start on that transition.

One last piece of advice: when you hit an unexpected issue — and you will, because app store tooling has edge cases that only reveal themselves in the wild — resist the urge to add more automation on top as the first response. Sometimes the right move is to keep the failing step manual for a week while you observe the pattern, then automate once the shape of the problem is clear. Automation built on guesses is the fastest way to turn a 10-minute release into a 40-minute one. Ask me how I know.