Una base, muchas pantallas: compartir código con criterio

La promesa de escribir una vez y ejecutar en todas partes es tan antigua como seductora, y en la familia de plataformas de Apple ha llegado más cerca de cumplirse que en ningún otro sitio: un mismo lenguaje, una misma biblioteca de interfaz, un mismo sistema de paquetes. Precisamente por eso el error que domina esta etapa no es compartir poco sino compartir demasiado. Una base común bien trazada multiplica el trabajo de un equipo pequeño; una base común extendida un paso más allá de donde debía producir un código lleno de condicionales, con una vista que intenta ser cinco vistas y satisface a ninguna, y con un coste de cambio que crece con cada plataforma añadida en lugar de repartirse entre ellas. La pregunta profesional no es cuánto se puede compartir, sino dónde deja de convenir.

Lo que se comparte sin discusión

Hay una capa cuya pertenencia al tronco común no admite debate razonable, y conviene nombrarla con precisión para que la discusión se concentre después en la frontera. Son los tipos del dominio, las reglas de negocio, la validación, el acceso a red y su decodificación, la persistencia y su esquema, la sincronización, la criptografía, el formateo de valores y todo el vocabulario con el que la app habla de su problema. Una tarea vencida es una tarea vencida en el teléfono, en el reloj y en el visor; que la regla se duplique es un defecto en cualquier plataforma, porque garantiza que algún día divergirá.

// Paquete Nucleo: sin dependencias de interfaz ni de plataforma
public struct Tarea: Identifiable, Codable, Sendable {
    public let id: UUID
    public var titulo: String
    public var vence: Date?
    public var completada: Bool

    public var estaVencida: Bool {
        guard let vence, !completada else { return false }
        return vence < .now                       // una regla, un lugar
    }
}

La disciplina que sostiene esa capa es negativa y muy simple: el paquete del núcleo no importa ninguna biblioteca de interfaz. Si un tipo del dominio necesita un color, un icono o un tamaño, ese tipo ha dejado de pertenecer al dominio. La prueba mecánica es que el núcleo debe compilar para todas las plataformas de la familia sin un solo condicional, y esa prueba se puede automatizar y ejecutar en integración continua, que es donde las buenas intenciones dejan de bastar.

Dónde deja de convenir

La frontera se traza con una pregunta que funciona sorprendentemente bien: esto que voy a compartir, ¿es una afirmación sobre el problema o una decisión sobre la experiencia? Las afirmaciones sobre el problema se comparten siempre. Las decisiones sobre la experiencia son propiedad de cada plataforma, porque nacen de expectativas distintas, de presupuestos de atención distintos y de dispositivos de entrada distintos.

El caso de la navegación merece un párrafo propio porque es donde más equipos se equivocan. Es tentador compartir el estado de navegación, ya que parece pertenecer al modelo: hay una selección, hay una ruta, hay un modal abierto. Pero la navegación es exactamente donde las plataformas divergen más —una pila en el teléfono, columnas en la tableta, ventanas en el Mac, una pantalla plana en el reloj, un espacio en el visor— y forzar una representación común obliga a que cada plataforma traduzca desde un vocabulario que no es el suyo. Lo que sí comparte bien es la identidad de lo que se está mirando: un identificador de tarea es común, y que ese identificador se convierta en una pantalla apilada, en una columna o en una ventana es asunto de cada plataforma.

flowchart TB
a[Paquete Nucleo: dominio y datos] --> b[App iOS: pila y gestos]
a --> c[App iPadOS: columnas y teclado]
a --> d[App macOS: ventanas y menus]
a --> e[App watchOS: complicacion y corona]
a --> f[App visionOS: ventana y volumen]
a --> g[Pruebas rapidas sin interfaz]
b --> h[Cada plataforma decide su experiencia]
c --> h
d --> h
e --> h
f --> h

El coste real de compartir de más

Conviene cuantificar el daño en lugar de invocarlo, porque a favor de compartir siempre hay un argumento visible —menos líneas— y en contra solo argumentos que se manifiestan meses después. El primer coste es combinatorio: cada condicional de plataforma dentro de una vista multiplica los caminos que hay que razonar y probar, y tres condicionales en el mismo archivo producen ocho comportamientos posibles de los que nadie ha visto más de dos.

// Sintoma inconfundible de frontera mal trazada
var body: some View {
    #if os(watchOS)
    ListaCompacta()
    #elseif os(macOS)
    TablaConMenus()
    #else
    ListaEstandar()
    #endif
}

El segundo coste es de acoplamiento temporal: cuando cinco plataformas comparten una vista, cualquier mejora en una obliga a validar las otras cuatro, de modo que el ritmo de todas queda determinado por el equipo más lento y por la plataforma más restrictiva. Esto convierte cada mejora en una negociación, y las negociaciones caras se posponen. El tercer coste es el más insidioso y el que rara vez se atribuye a su causa: la interfaz compartida tiende al mínimo común denominador, porque lo que no existe en el reloj no puede usarse y lo que solo existe en el Mac queda fuera. El resultado es un conjunto de apps sin defectos evidentes y sin ninguna virtud propia, que es exactamente el fracaso que este nivel entero intenta evitar.

Una arquitectura que hace barato lo correcto

La frontera no se sostiene con disciplina sino con estructura, porque la disciplina se agota los viernes por la tarde. La forma que mejor funciona consiste en un paquete local con el núcleo, uno o varios paquetes de características que dependen de él, y un objetivo de aplicación por plataforma cuya única responsabilidad es componer escenas y decidir la experiencia. La dependencia apunta siempre hacia dentro, y el sistema de compilación se encarga de que un intento de importar interfaz desde el núcleo falle en vez de discutirse.

// Package.swift del nucleo compartido
let package = Package(
    name: "Nucleo",
    platforms: [.iOS(.v17), .macOS(.v14), .watchOS(.v10), .visionOS(.v1)],
    products: [.library(name: "Nucleo", targets: ["Nucleo"])],
    targets: [
        .target(name: "Nucleo"),
        .testTarget(name: "NucleoTests", dependencies: ["Nucleo"])
    ]
)

Declarar las cinco plataformas en el paquete tiene un efecto que va más allá de lo administrativo: convierte la portabilidad en un error de compilación. En cuanto alguien use en el núcleo una función que no existe en watchOS, la compilación falla en su máquina y no en la de otra persona seis semanas después. Es la misma idea que atraviesa todo el nivel llevada a la organización del proyecto: hacer que las decisiones importantes sean explícitas y verificables en lugar de confiar en que se recuerden.

Para las diferencias legítimas que sí atraviesan la frontera —dónde se guardan los ficheros, cómo se notifica, qué capacidades de sensor hay— la herramienta correcta no es el condicional sino la inyección. El núcleo declara qué necesita en forma de protocolo y cada aplicación aporta su implementación, con lo cual el condicional desaparece del código compartido y se convierte en una elección hecha una sola vez, en el sitio donde se construye la app.

public protocol Avisador: Sendable {
    func avisar(_ mensaje: String) async     // el nucleo declara la necesidad
}
// iOS notifica; macOS usa el centro de notificaciones; watchOS vibra.
// Ninguna de esas decisiones vive en el nucleo.