La Raya · app (4): camino a Google Play — firma, versionado y el desvío de EAS

Llega el momento de sacar la app de mi máquina y subirla a pruebas cerradas en Google Play. Suena a trámite; trae sus propias piedras, sobre todo alrededor del versionado.

Lo que sí hacía falta

• Assets de tienda y firma: iconos, splash, y los scripts/keystore para firmar el AAB. La firma de subida (upload key) hay que tenerla bien guardada: si la pierdes o cambias, Play rechaza tus actualizaciones.
• Versionado coherente: cada AAB que subes necesita un versionCode mayor que el anterior, o Play lo rechaza sin contemplaciones. Y conviene mover el versionName (1.0.1, 1.0.2…) para distinguir de un vistazo qué build lleva cada tester.

El desvío de EAS (la herramienta que no necesitaba)

Aquí el clásico de "complicarse de más". Pensé: "para compilar en la nube uso EAS Build", y añadí un eas.json con perfiles, variables de entorno por perfil, etc. Estuve un rato montándolo… hasta que caí en la cuenta de que el proyecto ya compila en local con Gradle: tiene carpeta android/ nativa y la firma configurada en ~/.gradle/gradle.properties. No necesitaba EAS para nada.

Así que hice revert del eas.json y me quedé con el flujo que ya funcionaba. Un commit limpio: "Revert build: remove eas.json — el proyecto compila en local con Gradle".

La lección, que se repite en todo el proyecto: antes de añadir una herramienta nueva, mira cómo se hacían ya las cosas en el repo. La fontanería que "ya iba bien" suele ser la respuesta.

La trampa del doble versionCode

Un detalle que casi me la juega: en un proyecto Expo con carpeta android/ nativa, el versionCode vive en dos sitios — en app.json (que usa Expo al regenerar el nativo con prebuild) y en android/app/build.gradle (el que usa de verdad un build de Gradle directo). Si solo subes uno, compilas con el número viejo y Play te rechaza el AAB por duplicado, volviéndote loco.

Para no volver a tropezar, escribí un script bump_version.sh que incrementa versionCode y versionName en ambos a la vez. Tonto y eficaz: un comando, y los dos sitios sincronizados.

El otro susto: ¿a qué API apunta el build?

Relacionado con la entrada anterior: la URL del backend se hornea en tiempo de build. Si compilas sin la variable correcta (o, peor, con un .env que no se sube a un build en la nube), el binario acaba apuntando a localhost y los testers no conectan con nada. Por eso, compilar en local (donde el .env está presente) tenía la ventaja extra de que la URL de producción se incrustaba sin sorpresas.

Lo que me llevo

• No metas una herramienta de build "porque sí". EAS es estupendo, pero si ya compilas en local con Gradle, añadirlo es complejidad gratis. Revertir a tiempo es una victoria.
• El versionado en Expo+nativo tiene doble fondo. app.json y build.gradle deben ir sincronizados; automatízalo o lo olvidarás justo el día del release.
• Sube siempre el versionCode. Play no perdona; un script que lo bumpea por ti evita el "¿por qué me lo rechaza?" de turno.
• Sé consciente de a qué backend apunta cada build. La configuración del entorno es parte del entregable, no un detalle.

Con la app firmable, versionada y subible, solo quedaba acompañar al backend en sus últimas funciones: enseñar la gastronomía nueva, dar un canal de contacto y mostrar en el perfil qué versión llevas. Eso cierra la serie en la próxima entrada.