Qué significa en la práctica
Una base de código, muchas apps publicadas. Cada marca tiene su propia ficha en la tienda, su nombre de app, su icono, su paleta y su contenido, y todas se construyen a partir del mismo código fuente. La economía es el objetivo: la vigésima app cuesta una fracción de la primera, porque la primera pagó la plataforma.
Los compradores tienen siempre la misma forma. Agencias que revenden apps a sus propios clientes. Redes de franquicias donde cada región necesita su presencia en la tienda. Operadores multimarca con una cartera que atender. Plataformas de cursos y comunidades que publican una app por creador. La frase común es «necesito diez, o cincuenta, y no puedo financiar diez proyectos de desarrollo».
Cuatro palabras que la gente usa como sinónimos
| Qué varía por cliente | Bases de código que mantener | |
|---|---|---|
| Reskin | Logo, colores, nombre de la app | Una, pero las apps son el mismo producto |
| Fork | Cualquier cosa | Una por cliente, divergiendo desde el primer día |
| Multiinquilino | Datos y contenido, un solo despliegue | Una, una app |
| Marca blanca | Identidad en tiempo de compilación, contenido y funciones en tiempo de ejecución | Una, muchas apps |
Un fork es la respuesta honesta para dos clientes con productos realmente distintos. La multi-tenancy es lo que hace un SaaS cuando todos comparten una app y solo cambian los datos. La marca blanca es el caso en que cada cliente necesita su propia app en su propia ficha de tienda, y esa ficha es justo donde la cosa se complica.
Qué la separa de un reskin
La directriz 4.2.6 de revisión de la App Store existe para retirar apps generadas a partir de una plantilla, y un conjunto de apps que muestran las mismas pantallas con los mismos datos bajo logos distintos es precisamente lo que describe. Los rechazos aquí no son suaves: apps retiradas tras meses publicadas, flotas enteras retenidas en revisión, cuentas de desarrollador marcadas.
La lección que la mayoría saca de eso es la equivocada: que no puedes publicar muchas apps desde una base de código. Sí puedes. El problema nunca es la base de código compartida; son apps que son el mismo producto con sombreros distintos.
Hay dos capas de diferenciación, y casi todo el mundo hace solo la primera.
El theming visual da a cada app sus colores, su tipografía, su logo, su splash, su nombre, su identificador de paquete y su icono. Esto es necesario y es lo mínimo. Por sí solo es exactamente lo que rechaza la 4.2.6.
La capa cliente-servidor es lo que diferencia de verdad. Cada app se autentica contra el backend como su propio tenant y se descarga su propio mundo: su contenido, su catálogo, sus datos, su conjunto de funciones tras flags por tenant y su configuración remota. Dos apps construidas desde el mismo plano binario se convierten en productos genuinamente distintos en cuanto arrancan y hablan con el servidor.
El theming hace que una app parezca distinta. La capa de servidor hace que sea distinta, y un revisor que abra dos de ellas ve dos productos en lugar de una misma app dos veces.
Qué preguntarle a un proveedor
- ¿Qué varía en tiempo de ejecución y no solo en tiempo de compilación? Si la respuesta es solo el tema y el nombre de la app, estás comprando un reskin y la 4.2.6 va a por él.
- ¿Bajo qué cuentas de desarrollador se publican las apps? Las marcas a menudo necesitan publicar bajo su propia cuenta de editor y no bajo la tuya.
- ¿Cuánto cuesta la app número veinte? Si se parece a la número uno, no hay ninguna plataforma debajo: solo un script de compilación.
- ¿Cómo se crea una marca? Un formulario en un panel de administración significa que escala. Un ingeniero editando la configuración de compilación por cliente significa que no.
Cuándo es la respuesta equivocada
Cuando tienes dos clientes y no veinte. El trabajo de plataforma —el modelo de tenants, el pipeline de compilación, la configuración por tenant— es una inversión que solo se amortiza sobre una flota, y dos forks habrían salido antes y costado menos.
También es equivocada cuando cada cliente quiere funciones que los demás no van a usar jamás. Una base de código compartida que absorbe productos realmente divergentes se convierte en un montón de condicionales que nadie puede tocar con seguridad, y en ese punto el fork que evitaste es el fork que necesitas.
Ahora bien, si la flota es real, la palanca es poco común: una marca nueva pasa de un formulario enviado a un binario firmado en la cuenta de tienda correcta sin que haya un ingeniero por medio.
La versión larga —la arquitectura, el pipeline de compilación y la estrategia de envío— está en cómo publicamos más de 20 apps de marca desde una base de código Flutter, y la página de servicio es desarrollo de apps de marca blanca.