t1k:rn:performance:deployment

Field	Value
Module	`performance`
Version	`1.11.0`
Effort	`high`
Tools	—

Keywords: app store, CodePush, deployment, EAS build, OTA, react native

How to invoke

/t1k:rn:performance:deployment

RN Performance Deployment

EAS Build Profiles

{
  "cli": { "version": ">= 10.0.0" },
  "build": {
    "development": {
      "developmentClient": true,
      "distribution": "internal",
      "ios": { "simulator": true }
    },
    "preview": {
      "distribution": "internal",
      "android": { "buildType": "apk" }
    },
    "production": {
      "autoIncrement": true
    }
  },
  "submit": {
    "production": {
      "ios": { "appleId": "$(APPLE_ID)", "ascAppId": "$(ASC_APP_ID)" },
      "android": { "serviceAccountKeyPath": "./service-account.json" }
    }
  }
}

Executed by

Only the mechanical monitoring surface of this skill is cheap-tier work. The decision to ship, and the OTA push / store submission itself, are irreversible outward-facing actions and must never be routed to a cheap agent (routing SSOT: rules/orchestration-rules.md § “Task-Type → Agent Routing”):

Step	Agent
Poll an in-flight `eas build` or `eas submit` until terminal and report per-check status	`t1k-ci-watcher`
The store submission itself (`eas submit`) and an OTA push (`eas update`)	never delegated — the decision to ship and the submission stay with a human / reasoning tier
Configure version metadata (`app.json` buildNumber / versionCode increment, `autoIncrement: true`) per the stated rules	`t1k-fact-fetcher` (reads current values) + human confirmation before write

A build poll answers “is it done / did it pass”; pushing an update or submitting a build to the stores changes what users can run. The vote to ship is not a mechanical step and no cheap agent executes it.

Build Commands

# Development build (replaces Expo Go for native modules)
eas build --profile development --platform ios
eas build --profile development --platform android

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

# Production
eas build --profile production --platform all

# Submit to stores
eas submit --platform ios
eas submit --platform android

OTA Updates (expo-updates)

import * as Updates from 'expo-updates';

// Check and apply update
async function checkForUpdate() {
  try {
    const update = await Updates.checkForUpdateAsync();
    if (update.isAvailable) {
      await Updates.fetchUpdateAsync();
      await Updates.reloadAsync(); // restart app
    }
  } catch (e) {
    console.error('Update check failed:', e);
  }
}

# Publish OTA update (no store review needed for JS changes)
eas update --branch production --message "Fix crash on login"

App Version Management

// app.json — auto-increment via EAS
{
  "expo": {
    "version": "1.2.0",
    "ios": { "buildNumber": "42" },
    "android": { "versionCode": 42 }
  }
}

Key Rules

development profile requires dev client — build once, iterate with OTA
OTA updates only cover JS bundle — native code changes require full store build
Always set autoIncrement: true in production profile — prevents version conflicts
Use eas secret:create for API keys — never hardcode in eas.json

Gotchas

Updates.reloadAsync() restarts immediately — save any pending state before calling
OTA update channels must match: branch production → app built with production profile
App Store review takes 1-3 days — plan OTA strategy for hotfixes
eas build --local requires Docker — use for debugging build issues

Security

Store signing credentials in EAS — never commit keystores or provisioning profiles to git
Use eas secret for all CI/CD secrets (API keys, tokens)
Enable certificate pinning for production API calls