La respuesta corta
Transferir una app a otra cuenta de desarrollador se puede hacer, y sin perder la ficha. En Apple se conservan las valoraciones, las reseñas y el bundle ID, la app sigue disponible durante y después del traspaso, y los usuarios siguen recibiendo actualizaciones. En Google Play se conservan usuarios, estadísticas, valoraciones, reseñas y suscripciones.
Lo que no es indoloro es todo lo demás. Hay una lista larga de cosas que hay que preparar antes de pulsar el botón, y unas cuantas que se rompen sí o sí y que el usuario final nota. La peor de todas: en iOS, el acceso al keychain compartido deja de funcionar al actualizar, así que tus usuarios tendrán que volver a iniciar sesión una vez. Si eso te pilla por sorpresa el día del traspaso, tienes un pico de soporte y una caída de reseñas.
Esta guía es la lista, en orden.
Apple: lo que hay que hacer antes de pulsar transferir
Suscripciones auto-renovables
Necesitan un secreto compartido específico de la app. Quien transfiere lo genera y lo entrega antes; quien recibe lo tiene que tener antes de aceptar la transferencia y actualizar sus servidores con él. Después, quien recibe genera uno nuevo.
Si esto se salta, la validación de recibos deja de funcionar en el servidor del nuevo propietario. Es decir: suscriptores de pago que dejan de tener acceso.
TestFlight y Xcode Cloud: hay que vaciarlos
- TestFlight: apagar las pruebas beta, eliminar todas las compilaciones, todos los testers y vaciar los campos de información de prueba en todas las localizaciones. Los datos de TestFlight y los testers no se transfieren.
- Xcode Cloud: eliminar todos sus datos desde Settings → pestaña Xcode Cloud en App Store Connect.
Son requisitos, no recomendaciones: sin esto la transferencia no procede.
Sign in with Apple: el que hay que preparar con más antelación
Si la app usa Sign in with Apple, hay que desagrupar las apps antes de iniciar la transferencia. Y lo importante: hay que generar identificadores de transferencia para cada usuario de tu base de datos, contra el endpoint REST que Apple publica para eso.
Traducido: es un trabajo de migración de datos, con su script y su ventana de ejecución. Si no se hace, el identificador que Apple le da a cada usuario cambia de espacio y no puedes reconocer a tus propios usuarios después del traspaso.
Si no quieres transferir el Service ID asociado, hay que quitar la asociación antes — si no, se va con la app.
Apple Pay y Wallet: no viajan
- Apple Pay: el merchant ID no se transfiere. Las transacciones siguen funcionando con los certificados originales hasta que caduquen, pero quien recibe tiene que crear un merchant ID nuevo antes de enviar cualquier actualización.
- Wallet: los pases que necesiten actualizarse hay que reemitirlos con identificadores nuevos, para que se firmen con los certificados del nuevo propietario. Los pases ya emitidos quedan inactivos y hay que avisar a los usuarios de que se descarguen los nuevos.
Si tu producto es una tarjeta de fidelización o un billete, esto no es un detalle técnico: es una campaña de comunicación.
iCloud y CloudKit: cuidado con el contenedor compartido
Los contenedores de iCloud, los identificadores KVS y los datos de usuario sí se transfieren. El problema aparece si ese contenedor de CloudKit lo comparten otras apps de la cuenta de origen: esas otras apps pierden el acceso. No podrán volver a leer ni escribir en él.
Es el caso clásico de una empresa con varias apps que comparten datos. Antes de transferir una, hay que saber quién más está usando ese contenedor.
Keychain compartido: aquí es donde lo nota el usuario
El acceso al keychain solo funciona hasta que la app se actualiza. Al enviar la actualización hay que reconstruirlo: en proyectos de Xcode, sustituir el grupo de keychain definido por Xcode por el del nuevo propietario, con su Team ID.
Consecuencia directa, y conviene escribirla en el plan de comunicación: el usuario tendrá que iniciar sesión otra vez, porque la app ya no puede recuperar su token de autenticación.
Push, Game Center y lo demás
- APNs: los certificados siguen valiendo hasta que caducan; después, el nuevo propietario genera los suyos. Las claves se pueden reutilizar o regenerar, pero hay que actualizar los servidores con la que se elija.
- Game Center: la app sale de la matriz de compatibilidad multijugador y de los grupos. Los leaderboards revierten a su estado original —los de grupo conservan el prefijo
grp., los fusionados lo pierden y vuelven a sus IDs originales— y el nuevo propietario tiene que publicar una actualización con los IDs nuevos. La configuración de matchmaking no se transfiere: se rehace. - Mac Catalyst: la app de iPad y la de Mac se transfieren por separado y en ese orden, primero iPad. Si no se transfiere la de Mac, quien recibe no podrá generar una nueva desde la de iPad.
- App Bundles: después del traspaso no se puede consultar el histórico del bundle. Documentarlo antes.
- Nominations: no se transfieren. Se pasan a mano.
Google Play: más simple, con dos trampas
El proceso es más corto, pero tiene requisitos que sorprenden.
Lo que necesitas antes de empezar:
- Las dos cuentas registradas y activas.
- El transaction ID de registro de ambas cuentas. Se busca en el correo de la cuota de registro de desarrollador o en Google Payments. Tiene formatos como
01234567890123456789.token.0123456789012345oRegistration-1234ab56-…, y al enviarlo hay que quitar la primera parte (el0.G.o los dígitos previos altoken). - Perfil de pagos activo en la cuenta destino si hay apps de pago o compras integradas.
- Permisos actualizados en los servicios integrados —Firebase, Google Analytics, AdMob— antes del traspaso.
El equipo de soporte de Google revisa y responde las solicitudes en dos días hábiles.
Qué se transfiere: usuarios, estadísticas, valoraciones, reseñas, suscripciones, clasificación de contenido y la ficha de la tienda.
Qué no: los informes de exportación masiva, de pagos y de ingresos; las promociones (aunque los códigos ya emitidos siguen valiendo); los grupos de prueba, que hay que recrear; los permisos y vinculaciones de servicios integrados; y los pedidos anteriores al traspaso, que se quedan en la cuenta original.
Las dos trampas:
- Una app privada creada con el iframe de managed Google Play no se puede transferir. Nunca. Es lo que ya avisábamos en la guía de apps privadas: si se publicó bajo la cuenta equivocada, se vuelve a publicar y se vuelve a desplegar.
- Los proyectos de traducción hay que terminarlos antes, y las integraciones de SDK de anuncios exigen actualizar el APK después.
Quién se queda con los datos
Este reparto conviene pactarlo por escrito antes, porque después no se negocia:
| Quien transfiere | Quien recibe | |
|---|---|---|
| Ventas y pagos | Solo lo anterior al traspaso | Solo lo posterior |
| App Analytics | Pierde todo el acceso | Histórico desde el 1 de abril de 2015 o desde la primera publicación |
| Códigos promocionales | No se pueden generar nuevos tras el traspaso, sea quien sea el propietario | Los ya emitidos valen 4 semanas |
Que quien transfiere pierda todo el acceso a App Analytics es el punto que suele generar el conflicto. Si necesitáis ese histórico, se exporta antes.
El orden correcto
- Inventario: capacidades, servicios, contenedores compartidos, quién más usa qué.
- Exportar analítica, informes y todo lo que no viaja.
- Generar el secreto compartido de suscripciones y entregarlo.
- Migrar los identificadores de Sign in with Apple usuario por usuario.
- Vaciar TestFlight y Xcode Cloud.
- Preparar el plan de comunicación: re-login, pases reemitidos.
- Reunir los transaction IDs de Google y arreglar permisos de Firebase/AdMob/Analytics.
- Transferir. Primero iPad, luego Mac si hay Catalyst.
- Publicar la actualización: keychain reconstruido, merchant ID nuevo, IDs de Game Center nuevos.
La lección, que llega tarde
Todo lo de arriba existe porque alguien publicó la app bajo la cuenta equivocada. Normalmente, la de la agencia.
La cuenta de desarrollador —de Apple y de Google— debe estar a nombre del cliente desde el primer día, con la agencia invitada como miembro del equipo. Cuesta cero al empezar. Cuando el proyecto ya está en producción y hay suscripciones, Sign in with Apple y keychain de por medio, cuesta un proyecto pequeño y un pico de soporte.
Es exactamente lo que revisamos en una auditoría técnica de app móvil: antes que el código, quién es el dueño de las llaves.
Fuentes primarias, consultadas el 14 de agosto de 2026: Overview of app transfer en la ayuda de App Store Connect, y Transfer apps to another developer account en la ayuda de Google Play.
