Conceptos básicos de Tech Lead en Mobile

Equilibrando velocidad de envío con riesgo de revisión de tienda en equipos de Expo SDK 57. Los tech leads de mobile son dueños del mapa de reloj de lanzamiento - cuándo OTA es suficiente, cuándo una compilación de tienda es obligatoria, y cuándo las fechas del producto deben ceder a la política de Apple o Google.

Receta

Tarjeta de referencia rápida de lead - pega en la planificación de sprint o retrospectiva de lanzamiento.

Clasificación de cambios (cada ticket):
  [ ] Solo JS, misma runtimeVersion     → candidato para OTA
  [ ] Módulo nativo / plugin / permiso → eas build requerido
  [ ] Política de tienda (pagos, UGC, salud) → legal + buffer de revisión
  [ ] Cambio de contrato de backend            → coordina Clock C primero
 
Reglas de velocidad:
  - PRs < 400 líneas cuando sea posible - revisa el mismo día
  - PRs de UI incluyen screenshot o grabación de iOS + Android
  - Sin envío de tienda viernes sin propietario de reversión lunes
  - Un carril de hotfix de incidente documentado en CONTRIBUTING.md

# Antes de prometer "enviar mañana"
npx expo-doctor
eas build:list --limit 3          # edad del binario anterior + runtimeVersion
eas channel:list                  # canal de producción ↔ runtimeVersion
git diff main -- package.json app.config.ts eas.json

Cuándo usar esto:

• Eres el responsable de la decisión predeterminada en la ruta de lanzamiento (OTA vs tienda) y el throughput de revisión.
• El producto pide una fecha antes de que la ingeniería clasifique el impacto nativo.
• La tasa de crash o tasa de rechazo de tienda está subiendo mientras que la velocidad de PR se mantiene alta.
• Estás incorporando un nuevo squad lead a una aplicación de EAS + Expo Router existente.

Ejemplo funcional

Planificación de sprint - clasifica el backlog

Documenta la tabla en el ticket de sprint o notas de lanzamiento - "lo haremos con OTA" sin clasificación es cómo los equipos envían emparejamientos de runtimeVersion rotos.

Árbol de decisiones de lanzamiento

¿Necesitas enviar una corrección?
  │
  ├─ ¿Toca ios/, android/, app.config plugins, native deps?
  │    └─ SÍ → eas build + submit (Clock A). OTA no puede ayudar.
  │
  ├─ ¿Solo JS/TS/assets Y runtimeVersion sin cambios en binario en vivo?
  │    └─ SÍ → eas update en canal (Clock B). Reversión en minutos.
  │
  └─ ¿Cambio de política de tienda (login, pagos, reclamaciones médicas)?
       └─ SÍ → lista de verificación de revisión + buffer de revisión humana antes de enviar.

// eas.json - perfiles separados para que la velocidad no omita credenciales de producción
{
  "build": {
    "preview": {
      "distribution": "internal",
      "channel": "preview"
    },
    "production": {
      "channel": "production",
      "autoIncrement": true
    }
  }
}

Throughput de revisión sin omitir compuertas

# .github/workflows/pr.yml - retroalimentación rápida, mismas compuertas que main
name: PR checks
on: pull_request
jobs:
  quality:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: "20", cache: "npm" }
      - run: npm ci
      - run: npx expo-doctor
      - run: npm run lint && npm run typecheck && npm test

• PRs pequeños se fusionan más rápido que maratones de revisión heroicos - separa la configuración nativa de la UI cuando sea posible.
• Revisores nombrados para app.config.ts, eas.json, y plugins/ - no aprobación al pasar.
• Etiqueta Preview activa compilación EAS preview - ver Preview Builds on PRs.

Presupuesto de riesgo de revisión de tienda

## Ledger de riesgo de lanzamiento - sprint 24
 
| Riesgo gastado | Elemento | Resultado |
| --- | --- | --- |
| 1 unidad | Cambio de copia de IAP | Aprobado día 2 |
| 1 unidad | Nueva carga de foto (UGC) | Rechazado - falta ADR de moderación |
| 0 (OTA) | Color de botón | Enviado el mismo día |
 
Presupuesto: 2 envíos de tienda / sprint. Presupuesto excedido → deferir al siguiente tren o semana solo OTA.

Los leads rastrean rechazos como deuda de proceso - cada rechazo cuesta más tiempo de calendario que un día extra de QA. Empareja con Release Train Calendar para el modelo de tres relojes.

Cuándo ralentizar la velocidad

Errores comunes

• "Vamos a hacer hotfix con OTA" después de agregar un paquete nativo - OTA no envía bytecode Hermes para linkage nuevo .so / framework. Solución: Reconstruye el binario; comunica el retraso temprano.

• Expo Go verde, dev client rojo - Los junior demuestran en Go; la producción usa módulos nativos personalizados. Solución: Compilación de vista previa en Definition of Done para trabajo que impacta nativo.

• Velocidad = omitir typecheck - any fusionado y rutas rotas se componen en refactores de semana de revisión. Solución: Mismo CI en PR y main; sin bypass administrativo.

• Aprobador único en metadatos de tienda - Etiqueta de nutrición de privacidad incorrecta desencadena rechazo sin relación con la calidad del código. Solución: Fila de lista de verificación para campos de App Store Connect / Play Console.

• Backend deploy después de mobile - Campo JSON requerido nuevo rompe versiones de aplicación antiguas. Solución: Lectores tolerantes primero; ver matriz de dependencias de tren de lanzamiento.

Alternativas

FAQs

Related

• Release Train Calendar - tres relojes y matriz de dependencias
• Architecture Decision Records - plantilla ADR OTA vs tienda
• Code Review Standards for RN - perf, a11y, lista de verificación nativa
• Mobile Architecture Basics - límites que mantienen PRs pequeños
• Onboarding Basics - configuración del primer día antes de la presión de velocidad
• App Store Review Guidelines - prevención de rechazo
• OTA Updates Basics - restricciones de Clock B

Versiones de stack: Esta página fue escrita para React 19.2.3, React Native 0.86.0, y Expo SDK 57 (expo ~57.0.4).