Emparejamiento y Mob en Mobile
Un recetario para compartir simuladores, etiqueta en laboratorio de dispositivos y normas de revisión en equipos con Expo SDK 57 - el emparejamiento móvil falla cuando solo una persona ve la pantalla.
Busca en todas las páginas de la documentación
Un recetario para compartir simuladores, etiqueta en laboratorio de dispositivos y normas de revisión en equipos con Expo SDK 57 - el emparejamiento móvil falla cuando solo una persona ve la pantalla.
Tarjeta de referencia rápida - pega en la invitación del calendario.
## Sesión de emparejamiento - <feature>
- Conductor: <name> (teclado)
- Navegante: <name> (lee en voz alta, observa sim)
- Dispositivo: iPhone 16 sim + Pixel 8 API 35 emu
- Rama: feature/<ticket>
- Rota: 25 min
- Listo cuando: PR abierto con screenshot + salida de pruebas# Verificación compartida antes de terminar la sesión
npm run lint && npm run typecheck && npm test
npx expo start --dev-client # si hay módulos nativosCuándo usarlo:
| Herramienta | Usarla para | Consejo móvil |
|---|---|---|
| Zoom / Meet | Espejo de sim, cámara frontal | Comparte ventana no pantalla completa - oculta notificaciones |
| VS Code Live Share | Mismo buffer, terminal compartida | El conductor ejecuta Metro; el navegante observa sim en stream |
| QuickTime (macOS) | Video de sim de iOS nítido | Archivo → Nueva grabación de película → elige ventana del Simulador |
| scrcpy | Espejo de dispositivo Android | scrcpy --stay-awake para sesiones de dispositivo físico |
# Conductor - inicio estándar
npx expo start --clear
# Navegante - verifica en segunda plataforma sin detener Metro
# presiona a / i en terminal compartida con consentimiento del conductorNormas:
expo start causa confusión de puerto## Antes de la sesión
- [ ] Mismo Node 20 + `npm ci` completado en ambas máquinas
- [ ] Misma rama git verificada
- [ ] Simuladores con nombre: iPhone 16, Pixel_8_API_35
- [ ] Valores .env.local confirmados (staging API)
## Durante la sesión
- [ ] Redbox reproducido en iOS y Android una vez para errores de UI
- [ ] Escala de fuente 100% por defecto; prueba XL si es ticket de a11y
- [ ] Modo oscuro activado si está relacionado con tema
## Después de la sesión
- [ ] Descripción de PR incluye screenshots de ambas plataformas
- [ ] No hay experimentos `app.config.ts` sin commit en máquina del conductorLos nombres de dispositivos estándar se vinculan a Conceptos básicos de incorporación - los scripts de equipo npm run ios:16 reducen fricción de emparejamiento.
Los dispositivos físicos superan a los simuladores para cámara, push, biometría y rendimiento.
## Estante del laboratorio de dispositivos - normas de equipo
### Verificación
- Firma el dispositivo en #device-lab o hoja: nombre, fecha, ticket
- Nota la versión del SO en la etiqueta de la cuna (iOS 18.2, Android 15)
### Higiene
- Cierra sesión en cuentas personales de Apple/Google antes de devolver
- Limpia datos de app para compilaciones de staging al probar flujos de autenticación
- Carga al 80%+ antes de devolución; el cable se queda con la cuna
### Cuentas de staging compartidas
- Usa credenciales de vault de equipo - nunca cuentas personales solo 2FA
- Rota contraseñas trimestralmente; documenta en vault de 1Password
### Dispositivos rotos / inestables
- Etiqueta roja "no usar" + post en Slack - el hardware inestable desperdicia horas de mob# Instalación de compilación interna de iOS - colega verifica UDID registrado
eas device:create
eas build --profile preview --platform ios
# Carga lateral de APK de Android
eas build --profile preview --platform android
# QR del panel de EAS - ambos observan éxito de instalaciónRelacionado: Conceptos básicos de EAS Build - distribución interna | Distribución interna
Los roles rotan cada corte:
Conductor - escribe
Navegante - estrategia, lee tickets
Investigador - docs, Sentry, foros de Expo
Op dispositivo - dispositivo físico + screenshots (quinto opcional)Cortes de 25 minutos:
## Reglas de mob (mobile)
- Sin Metro paralelo en diferentes ramas a mitad de sesión
- Credenciales de EAS de producción: solo senior, grupo observa
- Merge solo después de que todos vieron pruebas verdes en streamRequiere evidencia más allá de CI verde:
| Tipo de cambio | El revisor espera |
|---|---|
| Diseño / espaciado | Screenshots de iOS + Android; nota clase de dispositivo |
| Gestos / sheets | Grabación de pantalla o pasos para reproducción emparejados |
| Navegación | Ruta de enlace profundo o comportamiento de back-stack descrito |
| Permisos | Screenshot de diálogos permitir/denegar |
| Adyacente a nativo | build_id de vista previa o versión de dev client anotada |
| Rendimiento | Antes/después si se tocó lista o animación |
Plantillas de comentario de revisión:
<!-- Solicita evidencia de dispositivo -->
Gracias - por favor agrega screenshot de Android; el área segura de iOS se ve correcta.
<!-- Solicita compilación de vista previa -->
Esto agrega un plugin de configuración - por favor activa `needs-preview` y pega enlace de EAS.
<!-- Aprueba con nota de dispositivo -->
Verificado en iPhone 16 sim + Pixel 8 emu - LGTM.Normas de SLA:
app/_layout.tsx, app.config.ts o eas.jsonNunca en solitario en el primer toque de credencial de producción - mob la lista de verificación.
## Lista de verificación de lanzamiento emparejado (45m)
- [ ] Confirma `build_id` de RC coincide con hoja de aprobación de QA
- [ ] Conductor comparte panel de EAS solo lectura; navegante lee pasos en voz alta
- [ ] `eas submit` solo después de que humo de Maestro esté verde
- [ ] Doc de reversión abierto: enlaces de reversión OTA + pausa de rollout escalonado
- [ ] Publica enlaces de envío en hilo #releasesRelacionado: Conceptos básicos de CI/CD móvil - carriles de lanzamiento vs PR
| Escenario | Emparejar | Asincrónico OK |
|---|---|---|
| Capstone de incorporación de primera semana | ✓ | |
| Redbox de Hermes solo en dispositivo | ✓ | |
| Cambio de copia en Texto estático | ✓ | |
| Nuevo plugin de configuración de Expo | ✓ | |
| Typo en accesorio de prueba | ✓ | |
| Maestro inestable en CI | ✓ | |
| Corrección de tipo de API | ✓ |
| Anti-patrón | Solución |
|---|---|
| "Déjame compartir después" screenshots | Bloquea merge hasta que haya evidencia en PR |
| Conductor acapara teclado 2h | Rota duro 25m |
| Revisión solo sim para ticket de cámara | Verificación obligatoria de laboratorio de dispositivos |
Dos personas ejecutan expo start diferente | Un Metro; el conductor es dueño de la terminal |
| Mob de 6 en typo diminuto | Divide - emparejar para código, asincrónico para revisión |
| Tamaño de equipo | Cadencia de emparejamiento |
|---|---|
| 3-4 ingenieros | 2-3 sesiones emparejadas / semana |
| 5-8 | Mob semanal en lanzamiento + pares ad-hoc |
| 9+ | Vainas de emparejamiento de área de características; mob cross-pod mensual |
Los capstones de incorporación y los errores nativos se emparejan más rápido que tres rondas de revisión asincrónica. Rastrea tiempo para merge de tickets emparejados vs solo durante un sprint.
Mínimo: un dispositivo Android de equipo + uno iOS pasado entre escuadras. Los simuladores cubren 80%; el emparejamiento en hardware compartido cubre el 20%.
Espejo de sim QuickTime + scrcpy + plantilla de PR de screenshot estricta. Trimestral en persona o semana de envío de dispositivo para QA táctil.
Mob produce código fusionado o una grabación de reproducción. Standup sincroniza estado - no hagas mob de todo el backlog en bloque de standup.
Versiones de pila: Esta página fue escrita para React 19.2.3, React Native 0.86.0 y Expo SDK 57 (
expo~57.0.4).
Revisado por Chris St. John·Última actualización: 16 jul 2026