Skip to main content
Estado: Propuesto · Refs: DEC-F2, DEC-F3, Q-28/Q-29
Traducción. Autoritativo: ../../adr/adr-020-mobile-whitelabel.md.

Contexto

La guideline 4.3 de Apple y su política de white-label empujan los binarios por tenant a la cuenta de desarrollador del PROPIO CLIENTE; los pipelines de build por tenant son operacionalmente caros.

Decisión

Primero: UNA app de member multi-tenant (“powered by Softcrum”) con theming en runtime (descubrimiento del tenant por deeplink, código o correo), arquitecturada para extenderse — la configuración por tenant (tema, metadata del bundle, flags de entitlement) vive FUERA del código desde el día 1, como perfiles de build de EAS más remote config, de modo que el tier premium (binario dedicado bajo la cuenta Apple/Google del cliente, add-on pago) es una adición al pipeline de build y no una reescritura. Capa intermedia: wallet passes (F2, con su propio ADR chico) — emitidos siempre bajo las cuentas propias de Softcrum, nunca las del cliente: un pass no tiene listing en la tienda, así que la guideline 4.3 no aplica y el branding viaja dentro del archivo del pass. Un tenant que quiere un canal completamente bajo su nombre compra el binario dedicado (corregido el 2026-08-17, FS-LOY-0014). Push por FCM/APNs; las Live Activities (F2) exigirán dev client de Expo y un módulo nativo (con su propio ADR).

Consecuencias

  • Un solo listing que mantener; el tier premium con precio que cubre su costo operativo real. − El tier de app única no puede usar el ícono ni el nombre del tenant (se vende explícitamente así).