¿Quién es el dueño del código fuente de una app?

Respuesta corta

Quién es el dueño del código fuente de una app depende del contrato, no es automático. Sin una cláusula de cesión de derechos, el proveedor puede conservar los derechos sobre el código que escribió. Debes asegurarte de que tu empresa sea dueña del código, de la cuenta de Apple y del repositorio, por escrito, antes de empezar. Es tu mejor protección frente a una agencia que retenga tu código como rehén. Esto es información general, no asesoría legal. Si además buscas un buen proveedor, mira nuestra guía sobre cuánto cuesta crear una app.

Quién es el dueño del código por defecto

Lo primero que sorprende a muchos fundadores es que pagar por la creación de una app no siempre significa poseer su código. La intuición dice que si pagas, el código es tuyo, pero la ley suele funcionar de otro modo: los derechos de autor sobre el código pertenecen por defecto a quien lo escribió, salvo que el contrato te los transfiera de forma explícita.

Esto significa que, sin la cláusula adecuada, puedes acabar en una situación extraña: pagaste la app, pero el proveedor conserva los derechos sobre el código y tú solo tienes derecho a usarlo. No es teórico, es el origen de muchos problemas que sufren empresas que no cuidaron este detalle. La buena noticia es que la solución es sencilla: el contrato debe indicar con claridad que, tras el pago, la propiedad del código pasa a tu empresa. Es una sola cláusula, pero una de las más importantes de todo el proyecto, y hay que dejarla resuelta antes de que empiece nada, no descubrir que falta más tarde. Organismos como la OMPI recuerdan que la propiedad intelectual se gestiona mediante el contrato.

Por qué debes ser el dueño del código

Poseer el código fuente no es una formalidad ni un tecnicismo legal; es el control de tu propia app y de tu futuro. Cuando eres dueño del código, puedes hacer con la app lo que quieras: hacerla crecer, cambiar de proveedor, contratar a otro para mantenerla, o simplemente saber que tu producto es de verdad tuyo.

Cuando no eres el dueño, cada una de esas cosas depende de otra persona. ¿Quieres cambiar algo? Tienes que volver a ese único proveedor. ¿Quieres cambiar de proveedor porque la relación no funciona? Puedes descubrir que no puedes llevarte tu propia app. Ese vuelco de poder es justo lo que hay que evitar, porque convierte a un socio en la única salida y te deja sin opciones. Poseer el código, desarrollado de forma nativa en Swift, significa que la app es un activo de tu empresa, no algo prestado por un proveedor que puede cambiar de idea. Para cualquiera que se tome en serio su app, ese control es invaluable, porque es lo que decide si tu producto es de verdad tuyo o solo algo que usas bajo las condiciones de otro.

Qué incluye ser dueño de tu app

Elemento	Por qué lo necesitas
El código fuente	Es la app en sí; sin él no tienes nada
El repositorio	Donde vive el código; debes tener acceso
La cuenta de Apple Developer	Tu presencia en la App Store y la app
Credenciales y accesos	Todo se conecta a través de ellos

La propiedad es más que el código solo, y la tabla muestra el cuadro completo. El código fuente por sí solo, sin acceso al repositorio donde vive, te deja aún dependiente. Del mismo modo, la cuenta Apple Developer Program debe estar a tu nombre, porque es la que tiene tu app en la App Store; si pertenece al proveedor, él controla tu presencia en la tienda. La regla es sencilla: debes poseer y controlar todo el proyecto, el código, el repositorio, la cuenta de Apple y todos los accesos. Solo entonces tienes control total, y ningún proveedor puede cortarte de tu propia app ni bloquearla para imponerte algo.

El problema del código secuestrado

Este es el escenario concreto que lleva a tantos fundadores a esta pregunta, y que ocurre más de lo que debería. Una empresa paga a una agencia por construir una app, pero el código vive en el repositorio de la agencia y la cuenta de Apple pertenece a la agencia. Todo va bien hasta que se tuerce: una discusión por las tarifas de mantenimiento, las ganas de cambiar de proveedor, o simplemente una relación que se deteriora. Y de pronto la empresa descubre que no puede llevarse su app, porque en realidad no la controla.

Eso es el código secuestrado, y es un riesgo real del que circulan historias. Una agencia que retiene tu código y tu cuenta tiene una palanca sobre ti: puedes sentirte obligado a pagar más de lo justo, o a quedarte con un proveedor del que te irías, porque la alternativa es perder la app. La protección no es confiar en que nunca pase, sino evitar esa posibilidad misma poseyendo el código, el repositorio y la cuenta desde el principio. Cuando el dueño eres tú, nadie puede secuestrar tu app, porque simplemente es tuya, sin importar cómo acabe la relación.

Cómo garantizar tu propiedad, y las señales de alarma

La protección frente a todo esto es sencilla, siempre que te ocupes de ella por adelantado, antes de empezar. Bastan unos pasos: dejar la cesión de derechos en el contrato, guardar el código en un repositorio que controles, abrir la cuenta de Apple a tu nombre y reunir todos los accesos.

Señal de alarma	Qué significa
Reticencia a escribir la cesión de derechos	Puede querer conservar el control de tu código
Código solo en el repositorio del proveedor	No tienes acceso pleno a tu propia app
Cuenta de Apple a nombre de la agencia	Controla tu presencia en la tienda
Respuestas evasivas sobre la propiedad	Evita un tema que debería estar claro
Código condicionado a pagos futuros	El anuncio clásico del código secuestrado

El hilo conductor es el mismo: garantizas el control fijándolo por escrito antes de que empiece el trabajo. Un socio serio lo acepta sin problema, porque para él es normal, y deja gustoso la propiedad en el contrato. Cómo reacciona un proveedor ante la pregunta de la propiedad ya dice mucho, y es una pregunta que conviene hacer pronto, antes incluso de cerrar el precio. La evasión, la vaguedad o la presión para firmar rápido sin aclarar la propiedad son en sí mismas la respuesta, y no es la que quieres.

Propiedad y mantenimiento no son lo mismo

Conviene aclarar una confusión frecuente: poseer el código y quién mantiene la app son dos cosas distintas, y una no excluye a la otra. Puedes ser dueño pleno del código y, por elección propia, encargar su mantenimiento a la misma agencia que lo construyó, porque es quien mejor lo conoce. La propiedad no significa perder a tu socio; significa quedarte con él porque quieres, no porque estés obligado.

Ahí está toda la diferencia entre una relación sana y una insana. En la sana, la agencia mantiene tu app porque lo hace bien, y tú sigues siendo dueño del código y podrías irte si algo se torciera. En la insana, la agencia mantiene tu app porque retiene el código y no tienes adónde ir. El mismo servicio, una relación de poder muy distinta. Cuando eres dueño del código, las tarifas de mantenimiento pasan a ser un intercambio justo que juzgas por su valor, no un rescate que pagas por obligación, lo que de hecho mejora la colaboración en lugar de empeorarla.

Cuándo la cosa es más compleja

Ten presente que esto es información general, no asesoría legal, y que en algunos casos la propiedad es más compleja. Las apps suelen usar componentes probados y bibliotecas de código abierto; no eres dueño de ellos, sino que los usas bajo su licencia, lo cual es normal. Un socio serio te dirá qué es tu código exclusivo y qué proviene de esos componentes, para que entiendas con precisión qué posees. En un proyecto grande o complejo, conviene que un abogado revise el contrato, porque los detalles de los derechos de autor y de la cesión pueden ser sutiles y varían según la jurisdicción.

Para la mayoría de las apps, sin embargo, la regla es sencilla y alcanzable: debes ser dueño del código escrito para ti, además de la cuenta y el repositorio, y un socio serio te lo garantizará gustoso por escrito. Un equipo que diseña y construye bajo un mismo techo, como nosotros, transfiere la propiedad completa del código que escribimos y mantiene tu acceso al repositorio y a la cuenta Apple Developer Program en todo momento, porque tu app debe ser tuya. Mira ejemplos en nuestro trabajo y cuéntanos sobre tu proyecto, y sobre la propiedad del código, en una llamada corta.