De quién es la cuenta de la App Store: suya o de quien desarrolla la app
Pedro CunhaPublicado el actualizado el 9 min de lectura
En resumen
La cuenta de desarrollador es el registro público de quién es dueño de una app — y quien controla la cuenta controla el producto. Lo que importa no es en qué cuenta nace la app, sino en qué cuenta termina, si la suya empezó a abrirse el primer día y si la migración es un paso previsto en el contrato. Ya recorrimos ese ciclo completo: la transferencia conserva las valoraciones y la base instalada, y rompe cosas específicas que hay que mapear antes.
La pregunta que casi nadie hace antes de firmar#
Cuando una empresa contrata el desarrollo de una aplicación, la negociación gira en torno al alcance, el plazo y el precio. Casi nunca alguien pregunta en qué cuenta de desarrollador se va a publicar la app — y esa es la pregunta que decide quién se queda con el producto al final.
La cuenta de desarrollador no es un detalle operativo. Es el registro público de quién es dueño de esa app, y es donde se guardan las cosas que después no se pueden recrear: la ficha en la tienda, las valoraciones acumuladas, el historial de versiones, los certificados de firma de la aplicación y los datos fiscales que reciben el dinero, cuando lo hay.
La respuesta corta es: la cuenta tiene que terminar a nombre de su empresa. La respuesta útil es más interesante, porque el camino hasta allí casi nunca es directo.
Qué guarda realmente la cuenta de desarrollador#
Vale entender qué está en juego antes de decidir dónde vive la app.
| Lo que queda en la cuenta | Por qué importa |
|---|---|
| La ficha de la app en la tienda | es la dirección pública del producto, con URL propia |
| Valoraciones y reseñas | es reputación acumulada, y no hay forma de trasladarla a mano |
| Historial de versiones | es el registro de que el producto se mantiene |
| Certificados de firma | sin ellos nadie publica una actualización |
| Datos fiscales y bancarios | es quien recibe, cuando la app vende |
| Identificadores y credenciales | Bundle ID, claves de notificación, secretos de suscripción |
Ninguno de estos ítems se recrea desde cero sin costo. Una ficha nueva significa empezar de cero en valoraciones — y la valoración es uno de los pocos activos de una app que no se compra ni se acelera.
Los dos caminos posibles#
Existen dos arreglos honestos, y la diferencia entre ellos no es ideológica: es de cronograma.
| Esperar a que su cuenta esté lista | Publicar por la cuenta de quien desarrolla y migrar | |
|---|---|---|
| Al inicio | el lanzamiento queda rehén del registro de la empresa | las dos vías corren en paralelo |
| Durante el proyecto | usted es titular desde el primer día | quien desarrolla opera sin intermediarios |
| Al final | no hay nada que hacer | hay una migración, con disparador y fecha |
| Riesgo real | semanas paradas esperando el trámite | quedarse sin la migración, si no está en el contrato |
El tercer arreglo — publicar en la cuenta de quien desarrolla y dejarla ahí — no está en la tabla porque no es un camino, es una dependencia. Es ese el que crea la conversación incómoda tres años después.
Cómo lo hacemos: dos vías en paralelo#
En Epicora el proceso es este, y existe porque el trámite y el lanzamiento tienen relojes distintos.
La cuenta del cliente empieza a abrirse el primer día. Eso incluye el número D-U-N-S, la cuenta Apple y la cuenta Google, todas a nombre de su empresa. Esa vía es lenta y no depende del código: es registro, verificación de identidad y validación de persona jurídica, y cada una de esas etapas tiene su propio tiempo de respuesta.
La publicación no espera a que esa vía termine. La app se publica primero por la cuenta de Epicora, que ya está verificada y operativa — y así el primer envío, la revisión de la tienda y las correcciones de revisión ocurren sin quedar rehenes de un trámite externo.
Cuando la app se estabiliza, se hace la migración a las cuentas del cliente, que a esa altura ya existen y ya están verificadas.
Ya recorrimos ese ciclo completo. La app de ProHire nació publicada por la cuenta de Epicora y fue transferida a la cuenta de la empresa — hoy, si abre su ficha en la App Store, el desarrollador que aparece es la razón social de ProHire, no la nuestra. Y lo que más interesa es lo que no pasó en la transferencia: nadie tuvo que reinstalar nada, las valoraciones siguieron ahí y la app continuó recibiendo actualizaciones por el mismo camino.
El punto que le interesa a quien está contratando no es el arreglo en sí — es el criterio que revela. Si el proveedor no empezó a abrir su cuenta el primer día, su cronograma ya está mal, aunque la app salga en la fecha acordada. La pregunta que hay que hacer en una reunión de kickoff es literal: ¿mi cuenta de desarrollador ya se está abriendo?
Cómo funciona la migración de verdad#
Aquí está lo que decide si "migrar después" es un plan o una promesa. Las dos tiendas documentan el procedimiento, y es razonablemente generoso con lo que importa.
Qué sobrevive. Apple documenta que la app transferida conserva sus valoraciones y reseñas, mantiene el mismo Bundle ID — que no se puede cambiar — y que los usuarios siguen recibiendo actualizaciones con normalidad. Google Play documenta que usuarios, estadísticas, datos, comentarios, valoraciones y suscripciones acompañan a la app. En la práctica, quien ya la instaló no hace nada y no nota nada.
Qué queda atrás o hay que rehacer. Es una lista corta, específica, y es donde está el trabajo:
| Ítem | Qué exige la migración |
|---|---|
| TestFlight (Apple) | hay que apagarlo antes de la transferencia |
| Suscripciones con renovación automática | generar un nuevo shared secret en la cuenta de destino |
| Sign in with Apple | desagrupar y generar un identificador de transferencia |
| Apple Pay | crear un nuevo Merchant ID en la cuenta de destino |
| App Groups | borrarlos en el origen y registrarlos en el destino |
| Informes de ventas anteriores | permanecen con quien transfirió |
| Grupos de prueba (Google) | hay que recrearlos |
Lo que ya vimos en la práctica. En la transferencia de la app de ProHire, lo que promete la documentación se confirmó: la base instalada no lo sintió, las valoraciones quedaron y las actualizaciones siguieron saliendo con normalidad. El trabajo real fue el de la columna derecha de la tabla anterior — la lista de credenciales e identificadores a rehacer.
El procedimiento. En Apple, el titular de la cuenta de origen inicia la transferencia y el titular de la cuenta de destino la acepta — siempre que la app cumpla los criterios de transferencia publicados por la empresa. En Google Play es una solicitud que exige el ID de transacción del registro de las dos cuentas y pasa por aprobación, con respuesta del soporte en hasta dos días hábiles.
Nada de esto es impedimento. Pero note lo que significa la lista: la migración es planificable y no es gratuita. Una app con suscripción recurrente e inicio de sesión social da más trabajo de migrar que una app institucional simple — y eso es argumento para decidir temprano, no para postergar.
Qué hace quien desarrolla sin ser dueño de nada#
El contraargumento más común para dejar la app en la cuenta del proveedor es operativo: "pero así no pueden trabajar". No se sostiene.
Las dos tiendas tienen roles diseñados exactamente para esto. En App Store Connect el proveedor entra como Admin; en la Google Play Console, como Release Manager. Con esos roles compila y sube builds, envía a revisión, responde pedidos de la tienda, gestiona la ficha y publica versiones — todo, excepto ser dueño. Cuando el contrato termina, usted quita el acceso y la aplicación no siente nada.
Titularidad y operación son capas separadas. Confundir las dos es lo que produce el arreglo malo.
Los atajos que no sirven#
Dos caminos parecen ahorro y no lo son.
TestFlight no es canal de producción. Es la herramienta de pruebas de Apple, y es excelente en eso. Pero un build distribuido por TestFlight caduca en 90 días — cuando caduca, la app simplemente deja de abrirse para quien la instaló por ahí. Distribuir la aplicación de producción de la empresa por TestFlight significa acordar un día, cada trimestre, en que todo se detiene.
El Apple Developer Enterprise Program no es una forma de saltarse la tienda. Exige que la empresa que publica tenga 100 o más empleados propios y restringe la distribución a colaboradores internos de esa misma empresa. Usarlo para distribuir una app a clientes o a terceros es uso indebido — y la consecuencia documentada es la revocación del certificado, que tumba de una vez todas las apps firmadas con él. Cuando un proveedor concentra varios clientes en un certificado así, el problema de uno se vuelve el problema de todos.
Qué poner en el contrato#
Cuatro cláusulas resuelven el asunto entero, y todas caben en lenguaje de comprador:
- La titularidad final es de la contratante. Las cuentas Apple y Google del producto se registran a nombre de su empresa, y es ahí donde termina la app.
- La apertura de las cuentas empieza al inicio del proyecto. Con responsable nombrado de los dos lados, porque el D-U-N-S y la verificación de empresa no dependen del código y no se aceleran al final.
- Si hay publicación inicial por la cuenta del proveedor, hay migración — con disparador y plazo. "Cuando la app esté estable" es un disparador aceptable siempre que estable esté definido; "cuando se pueda" no lo es.
- Entrega de accesos y artefactos al cierre. Certificados, claves, identificadores y la lista de capacidades especiales que exige la migración — porque la propia documentación de Apple pone esa transferencia de información como responsabilidad de quien entrega.
El criterio, en una frase#
No pregunte de quién es la cuenta hoy. Pregunte en qué cuenta va a terminar la app, cuándo empezó a abrirse la suya y qué dispara la migración — y pida las tres respuestas por escrito.
El resto es detalle de ejecución. Esto es propiedad.