# Core EAS Patterns

> Build profiles, eas.json configuration, runtime versions, submit config, and monorepo setup. See [SKILL.md](../SKILL.md) for decisions and philosophy.

---

## Build Profiles

### Minimal eas.json

```json
{
  "cli": {
    "version": ">= 14.0.0"
  },
  "build": {
    "development": {
      "developmentClient": true,
      "distribution": "internal",
      "ios": {
        "simulator": true
      },
      "android": {
        "buildType": "apk"
      }
    },
    "preview": {
      "distribution": "internal",
      "channel": "preview"
    },
    "production": {
      "channel": "production"
    }
  },
  "submit": {
    "production": {
      "ios": {
        "appleId": "your@email.com",
        "ascAppId": "1234567890"
      },
      "android": {
        "serviceAccountKeyPath": "./google-services.json",
        "track": "internal"
      }
    }
  }
}
```

### Complete eas.json with Profile Inheritance

```json
{
  "cli": {
    "version": ">= 14.0.0",
    "appVersionSource": "remote"
  },
  "build": {
    "base": {
      "node": "20.17.0",
      "env": {
        "EXPO_PUBLIC_APP_ENV": "development"
      }
    },
    "development": {
      "extends": "base",
      "developmentClient": true,
      "distribution": "internal",
      "ios": {
        "simulator": true,
        "resourceClass": "m-medium"
      },
      "android": {
        "buildType": "apk"
      }
    },
    "development-device": {
      "extends": "development",
      "ios": {
        "simulator": false
      }
    },
    "preview": {
      "extends": "base",
      "distribution": "internal",
      "channel": "preview",
      "env": {
        "EXPO_PUBLIC_APP_ENV": "preview"
      }
    },
    "production": {
      "extends": "base",
      "autoIncrement": "buildNumber",
      "channel": "production",
      "env": {
        "EXPO_PUBLIC_APP_ENV": "production"
      },
      "ios": {
        "resourceClass": "m-medium"
      },
      "android": {
        "buildType": "app-bundle"
      }
    }
  },
  "submit": {
    "production": {
      "ios": {
        "appleId": "your@email.com",
        "ascAppId": "1234567890",
        "appleTeamId": "ABC123DEF"
      },
      "android": {
        "serviceAccountKeyPath": "./google-services.json",
        "track": "internal",
        "releaseStatus": "draft"
      }
    }
  }
}
```

**Why good:** `base` profile shares Node version and env config, `extends` eliminates duplication, `development-device` overrides only `simulator: false` from `development`, production uses `autoIncrement` and AAB

### Build Commands

```bash
# Development builds
eas build --profile development --platform ios        # iOS simulator
eas build --profile development --platform android    # Android APK
eas build --profile development-device --platform ios # iOS physical device

# Preview builds (internal distribution)
eas build --profile preview --platform all

# Production builds
eas build --profile production --platform all
eas build --profile production --platform all --auto-submit  # Build + submit

# Install on simulator/emulator after build completes
eas build:run --platform ios
eas build:run --platform android
```

---

## Runtime Versions

### Fingerprint Policy (Recommended for Most Projects)

```typescript
// app.config.ts
export default {
  runtimeVersion: {
    policy: "fingerprint",
  },
  updates: {
    url: `https://u.expo.dev/${process.env.EAS_PROJECT_ID}`,
  },
};
```

**How fingerprint works:** Hashes all native dependencies, config plugins, and native code modifications. When the hash changes (new native module added, SDK version bumped), the runtime version changes automatically. OTA updates only deploy to builds with a matching fingerprint.

### AppVersion Policy (Simpler Projects)

```typescript
// app.config.ts
const APP_VERSION = "1.2.0";

export default {
  version: APP_VERSION,
  runtimeVersion: {
    policy: "appVersion",
  },
  updates: {
    url: `https://u.expo.dev/${process.env.EAS_PROJECT_ID}`,
  },
};
```

**How appVersion works:** Uses the `version` field from app config as the runtime version. You must manually bump `version` when making native changes.

### Custom Runtime Version (Full Control)

```typescript
// app.config.ts
export default {
  runtimeVersion: "2.0.0",
  updates: {
    url: `https://u.expo.dev/${process.env.EAS_PROJECT_ID}`,
  },
};
```

**When to use:** When you need exact control and understand the consequences. You must manually update the string when native code changes.

---

## Submit Configuration

### iOS App Store

```json
{
  "submit": {
    "production": {
      "ios": {
        "appleId": "your@email.com",
        "ascAppId": "1234567890",
        "appleTeamId": "ABC123DEF"
      }
    }
  }
}
```

For CI (avoids 2FA prompts), use App Store Connect API keys:

```json
{
  "submit": {
    "production": {
      "ios": {
        "ascApiKeyPath": "./AuthKey_XXXXXXXXXX.p8",
        "ascApiKeyIssuerId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
        "ascApiKeyId": "XXXXXXXXXX"
      }
    }
  }
}
```

**Gotcha:** Store the `.p8` file path relative to `eas.json`. In CI, download the key from EAS Secrets or your secret manager before the submit step.

### Google Play

```json
{
  "submit": {
    "production": {
      "android": {
        "serviceAccountKeyPath": "./google-services.json",
        "track": "internal",
        "releaseStatus": "draft"
      }
    }
  }
}
```

**Track options:**

| Track        | Purpose               |
| ------------ | --------------------- |
| `internal`   | Internal testers only |
| `alpha`      | Closed testing        |
| `beta`       | Open testing          |
| `production` | Public release        |

**Tip:** Start with `"track": "internal"` and promote through Play Console. Set `"releaseStatus": "draft"` to review before publishing.

### Staged Rollouts (Android)

```json
{
  "submit": {
    "production": {
      "android": {
        "serviceAccountKeyPath": "./google-services.json",
        "track": "production",
        "releaseStatus": "inProgress",
        "rollout": 0.1
      }
    }
  }
}
```

**How it works:** `rollout: 0.1` releases to 10% of users. Increase through Play Console as confidence grows.

---

## Environment Variables in Builds

### Non-Sensitive Variables (eas.json)

```json
{
  "build": {
    "preview": {
      "env": {
        "EXPO_PUBLIC_API_URL": "https://staging.api.example.com",
        "EXPO_PUBLIC_APP_ENV": "preview"
      }
    },
    "production": {
      "env": {
        "EXPO_PUBLIC_API_URL": "https://api.example.com",
        "EXPO_PUBLIC_APP_ENV": "production"
      }
    }
  }
}
```

### Sensitive Variables (EAS Secrets)

```bash
# Create project-scoped secrets
eas secret:create --scope project --name MY_AUTH_TOKEN --value "tok_abc123"
eas secret:create --scope project --name MAPS_API_KEY --value "AIza..."

# Create account-scoped file secret (shared across projects)
eas secret:create --scope account --name GOOGLE_SERVICES_JSON --type file --value ./google-services.json
```

Secrets are automatically available as environment variables during builds -- no `eas.json` env configuration needed.

---

## Monorepo Setup

### Directory Structure

```
my-monorepo/
  apps/
    mobile/              <-- eas.json lives here
      eas.json
      app.config.ts
      package.json
    web/
  packages/
    shared/
    ui/
  package.json           <-- Monorepo root
  pnpm-workspace.yaml    <-- Or workspaces in package.json
```

### Running Builds

```bash
# ALWAYS run from the app directory
cd apps/mobile
eas build --profile preview --platform ios

# NOT from the monorepo root
# cd my-monorepo && eas build  <-- WRONG
```

### Monorepo Considerations

- EAS auto-detects your package manager and runs install from the monorepo root
- Lock file must be at the repository root (EAS looks there, not in the app dir)
- For pnpm, ensure `pnpm-workspace.yaml` exists at the repo root
- If shared packages need building before the app, add a `postinstall` script:

```json
{
  "scripts": {
    "postinstall": "cd ../.. && pnpm run build --filter=@myorg/shared"
  }
}
```

---

## Version Management

### Remote Version Source

```json
{
  "cli": {
    "appVersionSource": "remote"
  }
}
```

**How it works:** EAS tracks version numbers server-side. No need to update `app.config.ts` version fields manually. Requires a paid EAS plan.

### Manual Version Sync

```typescript
// app.config.ts
const APP_VERSION = "1.2.0";
const BUILD_NUMBER = 42;

export default {
  version: APP_VERSION,
  ios: {
    buildNumber: String(BUILD_NUMBER), // MUST be string for iOS
  },
  android: {
    versionCode: BUILD_NUMBER, // MUST be integer for Android
  },
};
```

**Key rules:**

- iOS `buildNumber` is a **string** -- always use `String()`
- Android `versionCode` is an **integer** -- never stringify
- Android `versionCode` must **strictly increase** for each Play Store upload

# EAS Credentials Patterns

> iOS provisioning, Android keystores, local credentials, and code signing. See [SKILL.md](../SKILL.md) for decisions and philosophy.

---

## Automatic Credential Management (Recommended)

EAS manages all signing credentials by default. On first build, it generates and stores:

- **iOS:** Distribution Certificate + Provisioning Profile
- **Android:** Upload keystore + key

```bash
# First build -- EAS prompts to generate credentials
eas build --profile production --platform ios
# "Would you like to let EAS manage your credentials? (Y/n)"
# Select Y -- EAS creates and stores everything

# Subsequent builds reuse stored credentials
eas build --profile production --platform ios
# No prompts -- credentials are already managed
```

### Team Collaboration

After credentials are generated, teammates with EAS dashboard access can build without Apple Developer Portal access:

```bash
# Teammate runs build -- uses remote credentials
eas build --profile preview --platform ios
# No Apple Developer login needed
```

### Credential Inspection

```bash
# View current credentials
eas credentials --platform ios
eas credentials --platform android

# Options:
# - View existing certificates/profiles
# - Generate new ones
# - Remove old ones
# - Switch between managed and local
```

---

## iOS Provisioning

### Distribution Types

| Type       | Use Case                   | Build Profile Setting              |
| ---------- | -------------------------- | ---------------------------------- |
| App Store  | App Store submission       | `distribution: "store"` (default)  |
| Ad Hoc     | Internal testing (devices) | `distribution: "internal"`         |
| Enterprise | Company-wide distribution  | Enterprise Apple Developer account |

### Device Registration for Ad Hoc

Internal distribution (preview builds) requires registering test devices:

```bash
# Register a device -- generates a URL for the device owner to visit
eas device:create

# List registered devices
eas device:list

# After adding new devices, rebuild to include them in provisioning profile
eas build --profile preview --platform ios
```

**Gotcha:** iOS provisioning profiles expire after 12 months. This doesn't affect apps already installed, but the next build will need a new profile. Run `eas credentials --platform ios` to regenerate.

### App Store Connect API Keys (CI)

For CI pipelines, use API keys to avoid 2FA prompts:

1. Generate a key in [App Store Connect > Users and Access > Integrations > App Store Connect API](https://appstoreconnect.apple.com/access/integrations/api)
2. Download the `.p8` file
3. Store the key as an EAS Secret or in your CI's secret manager

```json
{
  "submit": {
    "production": {
      "ios": {
        "ascApiKeyPath": "./AuthKey_XXXXXXXXXX.p8",
        "ascApiKeyIssuerId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
        "ascApiKeyId": "XXXXXXXXXX"
      }
    }
  }
}
```

---

## Android Keystore

### Upload Keystore (Play App Signing)

Google Play App Signing is the recommended approach. Google manages the app signing key; you use an upload key:

```bash
# EAS generates upload keystore on first build
eas build --profile production --platform android

# If you need to view or reset:
eas credentials --platform android
```

**Key distinction:**

- **App signing key:** Google manages this. Used to sign the APK/AAB delivered to users.
- **Upload key:** You (EAS) manage this. Used to sign uploads to Play Console. Can be reset if compromised.

### Keystore Backup

```bash
# Download your keystore from EAS (for backup)
eas credentials --platform android
# Select: "Download credentials from EAS servers"
```

**Store securely** -- if you lose the upload keystore and don't use Play App Signing, you cannot update your app on the Play Store.

---

## Local Credential Management

For enterprises or teams that must manage their own signing credentials:

### credentials.json

Create `credentials.json` at the app root (same level as `eas.json`):

```json
{
  "ios": {
    "provisioningProfilePath": "./certs/profile.mobileprovision",
    "distributionCertificate": {
      "path": "./certs/dist-cert.p12",
      "password": "DIST_CERT_PASSWORD"
    }
  },
  "android": {
    "keystore": {
      "keystorePath": "./certs/upload-keystore.jks",
      "keystorePassword": "KEYSTORE_PASSWORD",
      "keyAlias": "upload-key",
      "keyPassword": "KEY_PASSWORD"
    }
  }
}
```

### Enable Local Credentials in Build Profile

```json
{
  "build": {
    "production": {
      "credentialsSource": "local"
    }
  }
}
```

**Security rules:**

- Add `credentials.json` to `.gitignore`
- Store actual credential files outside of version control
- Use environment variables for passwords (reference via `$VARIABLE_NAME` syntax)
- In CI, download credentials from a secret manager before the build step

### Generating Local Credentials Manually

```bash
# iOS: Export from Apple Developer Portal or Keychain Access
# - Distribution Certificate (.p12)
# - Provisioning Profile (.mobileprovision)

# Android: Generate keystore
keytool -genkeypair -v \
  -storetype JKS \
  -keyalg RSA \
  -keysize 2048 \
  -validity 10000 \
  -storepass YOUR_STORE_PASSWORD \
  -keypass YOUR_KEY_PASSWORD \
  -alias upload-key \
  -keystore upload-keystore.jks \
  -dname "CN=Your Name, OU=Your Org, O=Your Company, L=City, S=State, C=US"
```

---

## EXPO_TOKEN for CI Authentication

Authenticate EAS CLI in CI without interactive login:

```bash
# Generate token at https://expo.dev/accounts/[account]/settings/access-tokens
# Store as CI secret (GitHub Actions, CircleCI, etc.)

# CI pipeline uses token automatically
EXPO_TOKEN=your-token eas build --profile production --platform all --non-interactive
```

### GitHub Actions Example

```yaml
- name: Setup EAS
  uses: expo/expo-github-action@v8
  with:
    eas-version: latest
    token: ${{ secrets.EXPO_TOKEN }}

- name: Build
  run: eas build --profile production --platform all --non-interactive
```

The `EXPO_TOKEN` environment variable is read automatically by EAS CLI -- no `eas login` needed.

# EAS Update Patterns

> OTA update workflows, client-side update hooks, and channel strategies. See [SKILL.md](../SKILL.md) for decisions and philosophy.

---

## Publishing Updates

### SDK 55+ (--environment flag required)

```bash
# Publish to preview environment
eas update --environment preview --message "Fix login crash"

# Publish to production environment
eas update --environment production --message "Version 1.2.1 hotfix"

# List published updates
eas update:list

# Rollback a bad update
eas update:rollback --channel production
```

### SDK 54 and Earlier (--channel flag)

```bash
eas update --channel preview --message "Fix login crash"
eas update --channel production --message "Version 1.2.1 hotfix"
```

**Migration note:** If upgrading from SDK 54 to 55, replace all `--channel` flags with `--environment` in your scripts and CI pipelines.

---

## Channel-Branch-Update Model

```
Channel: "production"  ──points to──>  Branch: "production"
                                          |
                                          +-- Update 3 (latest - ACTIVE)
                                          +-- Update 2
                                          +-- Update 1

Channel: "preview"     ──points to──>  Branch: "preview"
                                          |
                                          +-- Update 2 (latest - ACTIVE)
                                          +-- Update 1
```

**Key concepts:**

- A **channel** is assigned to a build profile (in `eas.json`)
- A **branch** contains a list of updates (most recent is active)
- By default, a channel points to a branch with the same name
- You can remap: `eas channel:edit production --branch hotfix-v2`

### Remapping for Hotfixes

```bash
# Normal state: production channel -> production branch
# Hotfix scenario:
eas update --branch hotfix-v2 --message "Critical security fix"
eas channel:edit production --branch hotfix-v2

# After hotfix is merged into main:
eas update --environment production --message "Includes hotfix"
eas channel:edit production --branch production  # Reset
```

---

## Client-Side Update Hook

Check for and apply updates in the app. Skip checks in development mode.

```typescript
// hooks/use-ota-updates.ts
import * as Updates from "expo-updates";
import { useEffect, useState } from "react";
import { Alert } from "react-native";

const UPDATE_CHECK_INTERVAL_MS = 30_000;

interface UpdateState {
  isChecking: boolean;
  isAvailable: boolean;
  isDownloading: boolean;
}

export function useOTAUpdates() {
  const [state, setState] = useState<UpdateState>({
    isChecking: false,
    isAvailable: false,
    isDownloading: false,
  });

  const checkForUpdates = async () => {
    if (__DEV__) return; // Skip in development builds

    try {
      setState((prev) => ({ ...prev, isChecking: true }));
      const update = await Updates.checkForUpdateAsync();

      if (update.isAvailable) {
        setState((prev) => ({
          ...prev,
          isAvailable: true,
          isDownloading: true,
        }));
        await Updates.fetchUpdateAsync();
        setState((prev) => ({ ...prev, isDownloading: false }));

        Alert.alert(
          "Update Ready",
          "A new version has been downloaded. Restart to apply.",
          [
            { text: "Later", style: "cancel" },
            { text: "Restart", onPress: () => Updates.reloadAsync() },
          ],
        );
      }
    } catch (error) {
      // Fail silently -- app continues with current version
      console.error("Error checking for updates:", error);
    } finally {
      setState((prev) => ({ ...prev, isChecking: false }));
    }
  };

  useEffect(() => {
    checkForUpdates();

    const interval = setInterval(checkForUpdates, UPDATE_CHECK_INTERVAL_MS);
    return () => clearInterval(interval);
  }, []);

  return {
    ...state,
    checkForUpdates,
  };
}
```

**Usage in root layout:**

```typescript
// app/_layout.tsx
import { useOTAUpdates } from "../hooks/use-ota-updates";

export default function RootLayout() {
  useOTAUpdates(); // Checks on mount and periodically

  return <Stack />;
}
```

**Why good:** Named constant for interval, graceful error handling (app continues on failure), skip in dev mode, cleanup on unmount

---

## Immediate Update Strategy

Force the update before the user interacts with the app. Use `fallbackToCacheTimeout` in app config.

```typescript
// app.config.ts
export default {
  updates: {
    url: `https://u.expo.dev/${process.env.EAS_PROJECT_ID}`,
    fallbackToCacheTimeout: 5000, // Wait up to 5s for update on launch
  },
  runtimeVersion: {
    policy: "fingerprint",
  },
};
```

**How it works:** On app launch, `expo-updates` checks for a new update. If one is found and downloaded within 5 seconds, it runs immediately. Otherwise, the cached version runs and the update downloads in the background for the next launch.

**Trade-off:** Setting a high timeout delays app startup. Setting `0` (default) always uses the cached version and downloads updates in the background.

---

## Channel Strategy

```
Environment     Channel        Build Profile    Use Case
-----------     -------        -------------    --------
Development     development    development      Local dev testing
Preview/QA      preview        preview          Internal testing
Production      production     production       App store users

Git Branch      Deployment Target
----------      -----------------
feature/*       development channel (or none)
staging         preview channel
main            production channel
```

### Aligning eas.json with Channels

```json
{
  "build": {
    "development": {
      "developmentClient": true,
      "distribution": "internal",
      "channel": "development"
    },
    "preview": {
      "distribution": "internal",
      "channel": "preview"
    },
    "production": {
      "channel": "production"
    }
  }
}
```

**Key rule:** Each build profile's `channel` determines which updates it receives. A production build with `"channel": "production"` will never receive updates published to the `preview` channel.

---

## Update Size Considerations

- EAS Update has a **~50MB limit** per update bundle
- Large assets (images, videos, fonts) should be hosted on a CDN, not bundled
- SDK 55 introduces **Hermes bytecode diffing** (opt-in via `enableBsdiffPatchSupport` in `expo-build-properties`) for up to 75% smaller OTA downloads
- Only JavaScript and asset changes are included in updates -- native code changes require a new build

---

## Code Signing (End-to-End)

For apps requiring cryptographic verification of updates (enterprise, regulated industries):

```bash
# Generate signing key pair (one-time)
npx expo-updates codesigning:generate \
  --key-output-directory keys \
  --certificate-output-directory certs \
  --certificate-common-name "My App"

# Configure in app.config.ts
export default {
  updates: {
    codeSigningCertificate: "./certs/certificate.pem",
    codeSigningMetadata: {
      keyid: "main-key",
      alg: "rsa-v1_5-sha256",
    },
  },
};

# Publish signed update
eas update --environment production \
  --private-key-path ./keys/private-key.pem \
  --message "Signed update v1.2.1"
```

**Key rules:**

- Private key never leaves your machine (or CI secret store)
- Public key is embedded in the app via config
- Requires EAS Production or Enterprise plan
- Updates without valid signatures are rejected by the client

# EAS Workflows Patterns

> CI/CD automation with EAS Workflows YAML, custom build steps, and GitHub integration. See [SKILL.md](../SKILL.md) for decisions and philosophy.

---

## Workflow Basics

EAS Workflows are defined in `.eas/workflows/*.yaml` files. They orchestrate builds, tests, submissions, and notifications in a single pipeline.

### Directory Structure

```
my-app/
  .eas/
    workflows/
      deploy-production.yaml
      preview-build.yaml
      nightly.yaml
  eas.json
  app.config.ts
```

---

## Complete Production Deployment Workflow

```yaml
# .eas/workflows/deploy-production.yaml
name: Deploy Production

on:
  push:
    branches: [main]

jobs:
  build_ios:
    type: build
    params:
      platform: ios
      profile: production

  build_android:
    type: build
    params:
      platform: android
      profile: production

  submit_ios:
    needs: [build_ios]
    type: submit
    params:
      platform: ios

  submit_android:
    needs: [build_android]
    type: submit
    params:
      platform: android

  notify:
    needs: [submit_ios, submit_android]
    if: ${{ success() }}
    type: slack
    params:
      webhook_url: ${{ env.SLACK_HOOK_URL }}
      message: "Production build submitted for review"
```

**Why good:** `needs` enforces ordering (submit only after build succeeds), `if: ${{ success() }}` prevents notification on failure, both platforms build in parallel

---

## Preview Build on Pull Request

```yaml
# .eas/workflows/preview-build.yaml
name: Preview Build

on:
  pull_request:
    branches: [main]
    types: [opened, synchronize]

jobs:
  build_preview:
    type: build
    params:
      platform: all
      profile: preview
```

**Tip:** Add `[eas skip]` to a commit message to skip triggered workflow runs.

---

## Workflow with Custom Steps

Pre-packaged jobs use `type`. Custom jobs use `steps` with shell commands and built-in functions.

```yaml
# .eas/workflows/test-and-build.yaml
name: Test and Build

on:
  push:
    branches: [main]

defaults:
  tools:
    node: "20"
    pnpm: "9"

jobs:
  test:
    steps:
      - uses: eas/checkout
      - uses: eas/install_node_modules
      - name: Run type check
        run: pnpm tsc --noEmit
      - name: Run tests
        run: pnpm test

  build:
    needs: [test]
    type: build
    params:
      platform: all
      profile: production
```

**Key built-in functions:**

| Function                   | Purpose                                     |
| -------------------------- | ------------------------------------------- |
| `eas/checkout`             | Clone repository source                     |
| `eas/install_node_modules` | Install deps (auto-detects package manager) |
| `eas/prebuild`             | Run `expo prebuild`                         |
| `eas/download_build`       | Retrieve build artifacts                    |
| `eas/restore_cache`        | Restore cached files                        |
| `eas/save_cache`           | Save files to cache                         |
| `eas/use_npm_token`        | Configure private npm access                |
| `eas/send_slack_message`   | Post to Slack webhook                       |

---

## Sharing Data Between Jobs

Use `set-output` and `set-env` shell functions to pass data between steps and jobs.

```yaml
jobs:
  version:
    outputs:
      app_version: ${{ steps.get_version.outputs.value }}
    steps:
      - uses: eas/checkout
      - id: get_version
        name: Extract version
        run: |
          VERSION=$(node -p "require('./package.json').version")
          set-output value "$VERSION"

  build:
    needs: [version]
    type: build
    env:
      APP_VERSION: ${{ needs.version.outputs.app_version }}
    params:
      platform: all
      profile: production
```

**`set-output`** shares across steps and jobs (via `outputs`). **`set-env`** shares within the same job only.

---

## Scheduled Workflows

```yaml
# .eas/workflows/nightly.yaml
name: Nightly Build

on:
  schedule:
    - cron: "0 2 * * 1-5" # 2 AM UTC, Monday-Friday

jobs:
  build:
    type: build
    params:
      platform: all
      profile: preview
```

---

## Manual Trigger with Inputs

```yaml
# .eas/workflows/manual-deploy.yaml
name: Manual Deploy

on:
  workflow_dispatch:
    inputs:
      platform:
        type: choice
        options: [ios, android, all]
      profile:
        type: choice
        options: [preview, production]

jobs:
  build:
    type: build
    params:
      platform: ${{ inputs.platform }}
      profile: ${{ inputs.profile }}
```

---

## Concurrency Control

Prevent multiple workflow runs from overlapping:

```yaml
name: Deploy
on:
  push:
    branches: [main]

concurrency:
  group: deploy-${{ github.ref }}
  cancel-in-progress: true # Cancel previous run if new push arrives

jobs:
  build:
    type: build
    params:
      platform: all
      profile: production
```

---

## GitHub Actions Alternative

If you prefer GitHub Actions over EAS Workflows:

```yaml
# .github/workflows/eas-build.yml
name: EAS Build

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: "20"
          cache: "npm"

      - name: Install dependencies
        run: npm ci

      - name: Setup EAS
        uses: expo/expo-github-action@v8
        with:
          eas-version: latest
          token: ${{ secrets.EXPO_TOKEN }}

      - name: Build Preview
        if: github.event_name == 'pull_request'
        run: eas build --profile preview --platform all --non-interactive

      - name: Build and Submit Production
        if: github.ref == 'refs/heads/main'
        run: eas build --profile production --platform all --auto-submit --non-interactive
```

**Trade-offs:**

- **EAS Workflows:** Tightly integrated with EAS services, pre-packaged job types, less boilerplate
- **GitHub Actions:** More ecosystem tooling, familiar to most teams, works with non-EAS steps

Both approaches use `EXPO_TOKEN` for authentication and `--non-interactive` to prevent CI hangs.