Compartir con otros usuarios: registros compartidos, permisos e interfaz del sistema

Mientras una app solo sincroniza los datos de su dueño entre dispositivos, el modelo de seguridad es trivial: todo lo que hay en la base privada pertenece a quien ha iniciado sesión y no existe ninguna operación que el servidor pueda negarle. La compartición rompe ese supuesto de raíz y con él se derrumban varias suposiciones que estaban repartidas por todo el código sin que nadie las hubiera escrito: que el identificador de un registro basta para localizarlo, que la base de datos correcta se conoce de antemano, que si el objeto está en pantalla se puede editar, y que borrar un dato significa que desaparece. A partir del momento en que un segundo usuario entra en escena, la autorización deja de ser una decisión de la interfaz y pasa a ser un veredicto del servidor que tu código puede consultar pero no dictar.

La anatomía de una compartición

Compartir consiste en crear un registro especial, el objeto de compartición, que vive en la misma zona que aquello que se comparte y que actúa a la vez como lista de control de acceso y como generador de la invitación. Hay dos formas de crearlo y la elección condiciona todo lo demás. La primera toma un registro como raíz y comparte esa raíz junto con todo lo que la referencia jerárquicamente; la segunda comparte una zona entera, de modo que cualquier registro que se añada después queda incluido sin trámite. La jerárquica es más granular, la de zona es más simple de mantener.

Lo que ocurre en el lado del participante es la parte que más confusión genera. Sus datos no se copian: cuando acepta, aparece en su base compartida una zona que refleja la del propietario, con el mismo nombre pero con un identificador de dueño distinto. Esa zona no consume su cuota de iCloud, no está bajo su control y desaparecerá por completo si el propietario revoca el acceso o si él mismo abandona la compartición. Para el código del participante eso significa que la misma entidad puede vivir en dos bases de datos distintas y que localizar un registro exige saber en cuál buscar.

flowchart LR
a[Propietario crea la raiz en su zona personalizada] --> b[Se crea el objeto de comparticion junto a la raiz]
b --> c[El sistema genera una URL de invitacion]
c --> d[El invitado abre la invitacion y acepta]
d --> e[Aparece una zona espejo en la base compartida del invitado]
e --> f[Lectura y escritura segun el permiso concedido]
b --> g[El propietario revoca y la zona espejo desaparece]

// Compartir una jerarquia con raiz explicita
let comparticion = CKShare(rootRecord: proyecto)
comparticion[CKShare.SystemFieldKey.title] = "Proyecto de mudanza"
comparticion.publicPermission = .none          // solo por invitacion nominal

let (guardados, _) = try await db.modifyRecords(
    saving: [proyecto, comparticion], deleting: [], atomically: true
)

// Compartir una zona completa: todo lo que caiga dentro queda incluido
let deZona = CKShare(recordZoneID: zonaID)
deZona.publicPermission = .readOnly            // cualquiera con el enlace puede leer

Hay una restricción que conviene conocer antes de diseñar: la raíz y todo su contenido deben estar en una zona personalizada de la base privada del propietario, no en la zona por defecto, y no se puede compartir algo que ya pertenece a otra compartición. Reorganizar datos existentes para poder compartirlos implica moverlos de zona, lo que en la práctica significa crearlos de nuevo con identificadores distintos. Si la app va a necesitar compartir algún día, la estructura de zonas debe preverlo desde el primer despliegue.

Roles, permisos y participantes

El objeto de compartición contiene una lista de participantes y cada uno lleva tres atributos que se confunden con facilidad. El rol dice qué relación tiene con la compartición: propietario, invitado nominal o usuario que llegó por un enlace abierto. El permiso dice qué puede hacer: solo leer o leer y escribir. Y el estado de aceptación dice en qué punto del proceso está: invitado pero sin responder, aceptado o retirado. Un participante invitado con permiso de escritura que aún no ha aceptado no puede escribir nada, y esa combinación es la fuente habitual de informes de fallo que no reproducen.

Una advertencia sobre identidad que ahorra sorpresas: el sistema identifica a los participantes por su cuenta de iCloud y solo revela su nombre y su dato de contacto si esa persona lo ha autorizado. Tu app no puede asumir que dispone del correo de nadie, y mostrar la lista de colaboradores puede requerir un permiso de acceso a los contactos para completar los nombres. Cuando el permiso falta, lo correcto es mostrar una identidad neutra y no un hueco vacío.

La interfaz del sistema

Apple ofrece un controlador de compartición que resuelve la parte más delicada del flujo: generar la invitación, elegir el canal de envío, presentar los participantes, cambiar permisos y permitir detener la compartición. Usarlo no es una comodidad opcional, es prácticamente obligatorio, porque replicar a mano la generación de la URL y la gestión de participantes produce un flujo peor y con más aristas legales sobre privacidad. En SwiftUI se integra envolviendo el controlador o, en versiones recientes, ofreciendo la compartición como contenido transferible en un enlace de compartir.

struct BotonCompartir: UIViewControllerRepresentable {
    let comparticion: CKShare
    let contenedor: CKContainer

    func makeUIViewController(context: Context) -> UICloudSharingController {
        let vc = UICloudSharingController(share: comparticion, container: contenedor)
        vc.availablePermissions = [.allowPrivate, .allowReadWrite]
        vc.delegate = context.coordinator
        return vc
    }

    func updateUIViewController(_ vc: UICloudSharingController, context: Context) {}
    func makeCoordinator() -> Coordinador { Coordinador() }
}

El otro extremo del flujo es la aceptación, y ahí hay un detalle que se olvida con frecuencia. Cuando alguien abre la invitación, el sistema no abre tu app por una URL normal: entrega los metadatos de la compartición a un método específico del delegado de escena, y ese método puede llamarse antes de que tu almacén esté listo. La implementación robusta guarda los metadatos, espera a que el contenedor exista y solo entonces acepta, porque aceptar dos veces o aceptar sin almacén produce estados a medias difíciles de diagnosticar.

func windowScene(_ escena: UIWindowScene,
                 userDidAcceptCloudKitShareWith metadatos: CKShare.Metadata) {
    Task {
        do {
            try await esperarAlmacenListo()
            let aceptar = CKAcceptSharesOperation(shareMetadatas: [metadatos])
            aceptar.qualityOfService = .userInitiated
            try await ejecutar(aceptar, en: CKContainer(identifier: metadatos.containerIdentifier))
            await navegarA(metadatos.hierarchicalRootRecordID)
        } catch {
            await mostrarFalloDeInvitacion(error)
        }
    }
}

Vivir con datos que no son tuyos

La primera consecuencia práctica es que la interfaz debe preguntar antes de ofrecer. Un participante con permiso de solo lectura verá botones de edición que al pulsarse producirán un error del servidor, y ese error llegará tarde, en forma de fallo de escritura, cuando el usuario ya ha invertido esfuerzo. Consultar el permiso antes de dibujar y deshabilitar lo que no procede convierte una frustración en una restricción comprensible. Los contenedores de Core Data ofrecen consultas directas sobre si un objeto puede modificarse o borrarse, y usarlas es más fiable que deducirlo del rol.

let editable = contenedor.canUpdateRecord(forManagedObjectWith: objeto.objectID)
let borrable = contenedor.canDeleteRecord(forManagedObjectWith: objeto.objectID)

La segunda consecuencia afecta al ciclo de vida de los datos. Un objeto compartido puede desaparecer sin que el usuario haya hecho nada, porque el propietario dejó de compartir, cambió los permisos o simplemente lo borró. Una interfaz que mantenga una referencia a un registro inexistente y falle al abrirlo es un error común y evitable: toda navegación hacia contenido compartido debe tolerar la ausencia y devolver al usuario a un lugar sensato con una explicación. Lo mismo vale para la sincronización, donde la desaparición de una zona entera es un suceso normal y no un fallo.