Los modelos: pago único, consumibles, no consumibles y suscripciones

Existe una confusión persistente en los equipos que monetizan por primera vez: creen que elegir entre consumible y suscripción es una decisión de negocio que el equipo técnico simplemente implementa. Es exactamente al revés. Cada tipo de producto de la App Store define un contrato distinto con propiedades formales muy concretas —si el derecho caduca, si sobrevive a una reinstalación, si Apple lo restaura, si se comparte en familia, si genera renovaciones automáticas que hay que observar— y esas propiedades se propagan hacia arriba hasta la última capa de la app. Un consumible mal elegido produce un flujo de soporte que no cierra nunca; una suscripción sin valor recurrente produce un rechazo en revisión; un no consumible que debía ser suscripción produce una base instalada que exige mantenimiento perpetuo con ingresos que ya no llegan. El modelo no es la envoltura del producto: es el producto.

Cinco contratos, no cinco etiquetas

La App Store ofrece cinco maneras de cobrar y conviene enunciarlas por su contrato antes que por su nombre comercial. La app de pago cobra una vez en el momento de la descarga: el derecho es la app misma, va asociado a la cuenta de Apple y se restaura descargando de nuevo, sin que el desarrollador tenga que programar nada. El no consumible cobra una vez dentro de la app y otorga un derecho permanente sobre una funcionalidad o un contenido; Apple garantiza que ese derecho es recuperable en cualquier dispositivo del comprador, para siempre, y esa garantía es la que impone la obligación de implementar la restauración. El consumible cobra una vez y otorga un derecho que se agota con el uso: monedas, créditos, vidas. Apple no lo restaura ni lo recuerda, de modo que la responsabilidad de conservar el saldo es íntegramente del desarrollador o de su servidor.

Quedan los dos modelos temporales. La suscripción auto renovable cobra periódicamente hasta que alguien la cancela, se gestiona desde los ajustes del sistema y genera un flujo de eventos que la app debe observar. La suscripción no renovable cobra una vez y concede acceso durante un plazo fijo que no se prorroga solo; es la forma correcta de vender un pase de temporada o una matrícula de curso, y su rareza en el catálogo no se debe a que sea mala sino a que casi nadie sabe que existe.

Hay una sexta forma de ingreso que conviene mencionar aunque quede fuera del alcance de StoreKit: la venta de bienes y servicios físicos, que no pasa por la compra dentro de la app y se cobra con una pasarela externa. La frontera entre ambos mundos es la que más disputas de revisión genera, y el criterio es razonablemente estable: si lo que se entrega se consume dentro de la app, va por la tienda; si es un objeto que llega a un domicilio o un servicio que se presta fuera del software, va por fuera. Los casos difíciles viven en el medio —clases particulares, entradas, servicios profesionales— y merecen consultarse antes de construir, no después de un rechazo.

La diferencia operativa más importante entre estas categorías no es el precio ni la periodicidad, sino quién recuerda el derecho. En los no consumibles y en las suscripciones lo recuerda Apple, y por eso Transaction.currentEntitlements puede reconstruir el estado completo de un usuario en un dispositivo recién estrenado. En los consumibles no lo recuerda nadie salvo tú: la transacción existe en el histórico, pero el saldo que representa es una interpretación tuya, y en cuanto el usuario cambie de teléfono descubrirás si tu diseño tenía servidor o tenía suerte.

El encaje con la forma de la app

Elegir modelo se reduce a una pregunta que casi nadie formula con la suficiente crudeza: cuándo se consume el valor que vendes. Si el valor se entrega íntegro en un solo acto y permanece —desbloquear la exportación en alta resolución, quitar la publicidad, abrir un capítulo de contenido— el modelo natural es el no consumible. Si el valor se agota al usarse y el usuario querrá más —créditos de generación, fichas de juego, envíos— es un consumible. Si el valor se produce continuamente porque tú sigues trabajando —contenido nuevo cada semana, sincronización, cómputo en servidor, actualizaciones sustanciales— es una suscripción, y solo entonces.

flowchart TD
a[El valor se entrega una sola vez y permanece] -->|si| b[No consumible o app de pago]
a -->|no| c[El valor se agota con cada uso]
c -->|si| d[Consumible con saldo en servidor]
c -->|no| e[Tu sigues produciendo valor cada mes]
e -->|si| f[Suscripcion auto renovable]
e -->|no| g[Suscripcion no renovable por plazo fijo]

Ese diagrama resuelve la mayoría de los casos, pero conviene desconfiar de la rama que todo el mundo quiere tomar. La suscripción se ha convertido en el modelo por defecto porque produce ingreso recurrente, y el ingreso recurrente es lo que valora el mercado de capitales; el problema es que la pregunta relevante no es si al desarrollador le conviene cobrar todos los meses, sino si el usuario recibe algo todos los meses. Una app de utilidad que resuelve una tarea puntual y no cambia entre versiones no tiene una historia de valor continuo que contar, y tanto la revisión de la App Store como las valoraciones de la ficha castigan esa disonancia con precisión notable.

Existe además un contraste que ayuda a decidir cuando la intuición falla: comparar el modelo con la frecuencia de uso. Un producto que se usa a diario tolera bien la suscripción porque el usuario recuerda cada mes por qué paga; uno que se usa tres veces al año la tolera pésimamente, porque el recibo llega cuando la app lleva semanas sin abrirse y el recuerdo del valor ya se ha desvanecido. Esa correlación entre frecuencia de uso y tolerancia al cobro recurrente explica por qué las mismas cifras de conversión resultan excelentes en una categoría y desastrosas en otra, y por qué copiar el modelo de una app admirada de otro sector es una de las decisiones más caras que se pueden tomar.

El caso híbrido merece atención aparte porque es el que mejor funciona en la práctica y el peor documentado. Nada impide vender un no consumible que desbloquee las funciones esenciales y, además, una suscripción para los servicios que cuestan dinero cada mes —almacenamiento, modelos remotos, sincronización—. Esa separación tiene la virtud de ser honesta: se paga una vez por el software y se paga periódicamente por la infraestructura. Su coste es que la interfaz de compra se complica y que tu capa de derechos deja de ser un booleano para convertirse en una estructura con varias dimensiones, lo que conviene modelar explícitamente desde el primer día en lugar de descubrirlo con tres condicionales dispersos.

Hay dos parámetros más que se deciden aquí y no después. El primero es compartir en familia, que se activa por producto en App Store Connect y que, una vez concedido, no se puede revocar sin retirar el producto: multiplica el alcance y divide el ingreso por usuario, y es una decisión de posicionamiento, no un interruptor técnico. El segundo es el grupo de suscripción, que agrupa los niveles entre los que un usuario puede subir o bajar sin cancelar; poner cada suscripción en su propio grupo, error frecuente, imposibilita los cambios de plan limpios y obliga a coreografías de cancelación que el usuario no perdona.

Conviene además anticipar el caso de la app gratuita con funciones limitadas, que no es un modelo aparte sino la envoltura de cualquiera de los anteriores y que plantea su propia pregunta difícil: dónde se traza la línea. Trazarla demasiado arriba produce una app que nadie prueba lo suficiente como para querer pagarla; trazarla demasiado abajo produce una app que todos usan gratis para siempre. El criterio que mejor funciona no es cuantitativo sino cualitativo: lo gratuito debe permitir completar la tarea principal al menos una vez, porque solo quien ha experimentado el valor entero puede decidir si lo quiere de forma repetida o sin fricción.

El precio no es una etiqueta

La configuración del precio parece administrativa y sin embargo condiciona el código, porque determina qué puede cambiar sin publicar una versión nueva. Los precios se eligen entre los puntos que ofrece la plataforma y se propagan a todas las regiones con conversiones automáticas y ajustes fiscales; la app nunca los conoce de antemano, los recibe. Esa asimetría es la razón técnica de la regla que la lección siguiente convierte en código: la interfaz de compra se construye a partir de los datos del catálogo remoto, no de constantes locales, y por tanto un cambio de precio o una promoción no deberían exigir nunca una entrega nueva.

// El precio mensual equivalente de un plan anual: calculo con Decimal,
// presentacion con el formato que la propia tienda expone
func precioMensualEquivalente(de anual: Product) -> String? {
    guard let periodo = anual.subscription?.subscriptionPeriod,
          periodo.unit == .year else { return nil }
    let meses = Decimal(12 * periodo.value)
    let porMes = anual.price / meses
    return porMes.formatted(anual.priceFormatStyle)
}

Sobre la aritmética del reparto conviene tener las cifras presentes porque cambian las conclusiones de cualquier modelo financiero. La comisión estándar de la plataforma es del treinta por ciento, baja al quince para quienes se acogen al programa de pequeños negocios por debajo de un umbral anual de ingresos, y baja también al quince para las suscripciones a partir del segundo año de un mismo suscriptor. Esa última regla tiene una implicación que casi nadie explota: la retención no solo aumenta los ingresos, también aumenta el margen, porque el segundo año de un suscriptor vale bastante más que el primero incluso al mismo precio.

Queda una asimetría legal que afecta al diseño del producto. Subir el precio de una suscripción existente no es una operación libre: según la magnitud y la frecuencia del incremento, la plataforma exige el consentimiento explícito del suscriptor y, si no lo obtiene, la suscripción no se renueva. Eso convierte cualquier subida en un evento de riesgo que hay que planificar con comunicación previa, y explica por qué es tan sensato fijar el precio inicial con margen en lugar de entrar barato con la esperanza de corregirlo después.

Errores de modelado que cuestan caro

El primero y más común es vender como no consumible algo cuyo coste marginal es recurrente. Un desbloqueo de por vida por diez euros que incluye almacenamiento en tu servidor es un préstamo a interés desconocido: cada usuario que compró en el primer año seguirá consumiendo infraestructura durante una década sin aportar un céntimo más, y el único modo de salir de ahí es traicionar la promesa. Si el coste de servir a un usuario no tiende a cero, el derecho perpetuo es un pasivo disfrazado de ingreso.

Ese error tiene una versión atenuada que también conviene nombrar, porque es la que cometen los equipos prudentes: vender un derecho perpetuo cuyo coste marginal sí tiende a cero pero cuyo coste de mantenimiento no. Ninguna app sobrevive sin adaptarse a los cambios anuales del sistema operativo, y ese trabajo se paga con ingresos del presente, no del pasado. Un producto perpetuo es sostenible solo si existe un flujo de compradores nuevos que financie el mantenimiento de los antiguos, lo cual es exactamente la estructura de un negocio que depende del crecimiento perpetuo para no colapsar.

El segundo es el inverso: convertir en suscripción lo que era un no consumible legítimo, con el argumento de que así se financia el desarrollo. Puede ser cierto y aun así ser un error de encaje, porque el usuario evalúa el valor recibido por período y no el esfuerzo del desarrollador. La versión sensata de esa transición es la que muchos equipos han acabado adoptando: suscripción que da acceso a todo lo nuevo, y una salida honesta si se deja de pagar en la que lo ya obtenido permanece funcional.

El tercero es tratar el consumible como si fuera contabilidad trivial. Un saldo es una cuenta y una cuenta necesita idempotencia: si la misma transacción se procesa dos veces, el usuario recibe el doble; si se pierde, el usuario ha pagado por nada y escribirá al soporte con razón. Ese problema no lo resuelve StoreKit, lo resuelve el diseño de tu servidor con un identificador de transacción como clave de deduplicación y una llamada a finish que ocurre solo después de haber acreditado el saldo de forma duradera.

El cuarto es más sutil y solo se manifiesta con el tiempo: fragmentar el catálogo en demasiados productos. Cada identificador que existe es un identificador que habrá que mantener, traducir, probar, mostrar y honrar durante años, incluso mucho después de haberlo retirado de la venta, porque quien lo compró conserva su derecho. Un catálogo de tres productos bien elegidos se explica en una pantalla y se prueba en una tarde; uno de veinte exige una matriz de compatibilidad que nadie mantiene y produce, indefectiblemente, un usuario con una combinación de derechos que el código no contemplaba.

El quinto es olvidar que los productos que se retiran no desaparecen. Dejar de vender algo es una operación de catálogo, no de código: Transaction.currentEntitlements seguirá devolviendo ese identificador para quienes lo compraron, y la app debe seguir sabiendo qué significa. La consecuencia práctica es que la tabla que traduce identificadores a capacidades solo crece, nunca se poda, y conviene tratarla como lo que es: un registro histórico con la misma dignidad que una migración de base de datos.