Cómo transferir una app a la cuenta del cliente
Sin republicar, sin perder las reseñas y sin que los usuarios tengan que instalar nada de nuevo. Actualizada a 2026.
De qué hablamos
Pasa seguido: la app de un negocio está publicada en la cuenta de desarrollador del programador que la construyó. Mientras la relación funciona, nadie lo mira. Cuando termina, el cliente descubre que su app —la que pagó— vive en una cuenta ajena.
La buena noticia es que ambas tiendas tienen un trámite oficial para esto. Se llama transferencia de app y mueve la app de una cuenta de desarrollador a otra conservando la ficha, las reseñas y los usuarios instalados. No hay que republicar nada ni pedirle a nadie que vuelva a descargar.
La mala es que el trámite tiene requisitos concretos y varios motivos por los que se traba. Esta guía cubre los dos procesos, qué se conserva, qué se pierde y qué mirar antes de arrancar. Si todavía estás decidiendo a nombre de quién abrir las cuentas, empezá por acá.
Transferir no es entregar el código
Son dos cosas distintas y conviene no mezclarlas. Transferir la app mueve la publicación entre cuentas de las tiendas. Entregar el proyecto es pasar el código fuente, los certificados de firma y los accesos a la infraestructura.
Podés hacer una sin la otra, pero si el objetivo es que el cliente quede autónomo necesita las dos: sin el código no puede publicar una actualización, y sin la cuenta no puede publicar nada.
Qué se conserva y qué se pierde
| Qué | Google Play | App Store |
|---|---|---|
| Reseñas y calificaciones | Se conservan | Se conservan |
| Usuarios instalados | Se conservan; reciben actualizaciones normalmente | Se conservan; reciben actualizaciones normalmente |
| Ficha de la tienda | Se conserva (textos, capturas, categoría) | Se conserva |
| Identificador de la app | Se conserva | El Bundle ID se conserva y ya no se puede cambiar |
| Suscripciones | Los datos se transfieren | Se transfieren, pero hay que pasar el shared secret |
| Informes de ventas y ganancias | No se transfieren; quedan en la cuenta original | El historial anterior queda en la cuenta original |
| Analíticas | Las estadísticas de usuarios se transfieren | Quien transfiere pierde el acceso a App Analytics |
| Grupos de prueba y códigos promocionales | No se transfieren: hay que rehacerlos | TestFlight hay que vaciarlo antes de transferir |
Cuándo NO vas a poder transferirla
Esto es lo primero que conviene chequear, porque cualquiera de estos puntos frena el trámite antes de empezar. En App Store:
- La app nunca se publicó. Necesita al menos una versión lanzada en la tienda.
- Está en revisión o esperando publicación. Si el estado es Waiting for Review, In Review, Accepted, Pending Developer Release o Pending Apple Release, hay que esperar a que termine.
- Tiene un pre-orden activo en cualquier país.
- Hay compras integradas con el mismo identificador que las de otra app de la cuenta que la va a recibir. Los IDs no se pueden duplicar.
- Es una app de Apple Arcade: no son transferibles.
- Es una app de Mac que comparte contenedor de App Group con otras apps de Mac de la misma cuenta.
- Alguna de las dos cuentas tiene acuerdos sin aceptar o está en un cambio de titularidad pendiente.
Y en Google Play
- Es una app privada creada con el iFrame de Google Play gestionado: esas no se pueden mover a otra cuenta.
- La cuenta que recibe no tiene perfil de pagos activo y la app es de pago o tiene compras integradas.
- Alguna de las dos cuentas tiene incumplimientos de política sin resolver.
Paso a paso
El trámite lo inicia la cuenta que tiene la app hoy y lo aprueba la que la va a recibir. Las dos tienen que estar activas.
Descargá lo que quieras conservar
Informes de ventas, de ganancias y exportaciones masivas de reseñas. Después de la transferencia quedan en la cuenta original, pero conviene tenerlos a mano igual.
Este paso no es obligatorio para el trámite. Es el único momento cómodo para hacerlo.
Conseguí el ID de transacción de las dos cuentas
Es el identificador del pago de los USD 25 de registro de desarrollador. Se busca en el correo del pago o en la actividad de Google Payments, poniendo «developer registration fee».
Acá se traba mucha gente: hay que recortarle el principio al identificador. Si empieza con algo como «0.G.», o si tiene dígitos antes de las palabras «token» o «Registration», esa primera parte se descarta y se pega solo el resto.Resolvé los servicios conectados
Si la app usa Firebase, Google Analytics o AdMob, actualizá los permisos y las vinculaciones antes de transferir: esas configuraciones no viajan con la app.
Si es una app de pago o con compras integradas, verificá que la cuenta que la recibe ya tenga el perfil de pagos activo. Sin eso el trámite no avanza.Enviá la solicitud
Desde la cuenta que tiene la app, se completa el formulario de transferencia en Play Console con los datos de las dos cuentas y los identificadores de transacción.
Que la cuenta destino la apruebe
El titular de la cuenta que recibe tiene que revisar y aceptar la solicitud. Sin ese paso no pasa nada.
Esperá la revisión de Google
El equipo de soporte revisa y responde las solicitudes de transferencia dentro de los 2 días hábiles.
Paso a paso
En Apple el trámite lo inicia y lo acepta el Account Holder de cada equipo: ningún otro rol puede hacerlo, ni siquiera un administrador.
Vaciá TestFlight
Apagá el beta testing, eliminá los builds y los testers, y limpiá los campos de información de prueba.
Si la app usa Xcode Cloud, también hay que borrar esos datos antes de transferir, desde la pestaña correspondiente en los ajustes de la app.Guardá lo que no viaja
La app desaparece de tu cuenta al completarse la transferencia. Anotá la información de los bundles y descargá lo que necesites del historial.
El historial de ventas anterior a la transferencia te queda accesible, pero App Analytics lo perdés por completo: pasa a la cuenta que recibe.Si hay suscripciones, pasá el shared secret
Generá el shared secret específico de la app y compartilo con quien la recibe antes de iniciar el trámite. Sin eso, la validación de las suscripciones se rompe del lado del servidor.
Una vez completada la transferencia, conviene que el receptor genere uno nuevo y actualice sus servidores.
Si usás Sign in with Apple, generá los identificadores de transferencia
Hay que generar un transfer identifier por cada usuario de la base antes de mover la app. Si no se hace, esas cuentas dejan de poder iniciar sesión.
Esto no tiene vuelta atrás cómoda: es el punto que más problemas causa en apps con login social de Apple.Iniciá la transferencia
El Account Holder de la cuenta que tiene la app inicia el traspaso desde App Store Connect e indica a qué equipo va.
Que el Account Holder receptor la acepte
Del otro lado, el titular de la cuenta que recibe acepta la transferencia. La app sigue disponible en la tienda durante todo el proceso.
Rehacé lo que quedó atado a la cuenta vieja
Ya del lado del receptor: generar nuevas credenciales de notificaciones push (APNs) y actualizar los servidores, y crear un Merchant ID nuevo si la app usa Apple Pay.
El Merchant ID de Apple Pay no se transfiere. Las transacciones siguen funcionando con los certificados originales, pero hay que crear uno nuevo antes de subir la próxima actualización.
Cuánto tarda
| Etapa | Google Play | App Store |
|---|---|---|
| Preparación (limpiar, juntar datos) | 1–2 horas | 2–4 horas si hay suscripciones o login de Apple |
| Aprobación de la otra cuenta | Depende de ustedes | Depende de ustedes |
| Revisión de la tienda | Hasta 2 días hábiles | Suele completarse el mismo día |
| Rehacer credenciales y servicios | 1 hora | 2–3 horas |
Checklist antes de apretar el botón
- La cuenta que recibe ya existe, está pagada y verificada. No se abre en el momento.
- La app no está en revisión ni con una versión a medio publicar.
- Descargaste los informes que quieras conservar.
- Si hay suscripciones, el shared secret está compartido.
- Si hay Sign in with Apple, los identificadores de transferencia están generados.
- TestFlight está vacío y Xcode Cloud, limpio.
- Tenés a mano los dos identificadores de transacción de Google, ya recortados.
- Acordaste con la otra parte quién entrega el código fuente y cuándo, que es la otra mitad del asunto.
¿Y si no se puede transferir?
Queda el camino largo: publicar la app de nuevo desde la cuenta del cliente y dar de baja la vieja. Funciona, pero se pierden las reseñas, las calificaciones y el historial de descargas, y los usuarios existentes no reciben la actualización: tienen que instalar la app nueva a mano.
Es un costo real, sobre todo si la app tenía reputación acumulada. Por eso conviene revisar los bloqueos temprano: casi todos —una revisión pendiente, un pre-orden activo, un identificador de compra duplicado— se resuelven esperando o cambiando algo, no son definitivos.
Escribimos esta guía porque creemos que cada herramienta digital que construimos debe quedar bajo el control del cliente desde el primer día. Si querés el razonamiento completo, está en esta nota.