Deep links y restauración de la pila

Abrir una app en una pantalla concreta parece un problema de enlaces, y no lo es. Es un problema de reconstrucción: una notificación, una URL o un reinicio del sistema te entregan una descripción de un destino, y tu trabajo consiste en fabricar a partir de ella un pasado plausible, no solo un presente. Que la pila sea un valor convierte esa tarea en una función pura de traducción, y que ese valor sepa codificarse la convierte además en algo que sobrevive al cierre de la app.

De una URL a un historial

El error habitual consiste en tratar el enlace profundo como una orden de mostrar una pantalla. Si lo haces así, el usuario aterriza en un detalle sin contexto y el botón de retroceso no lleva a ninguna parte razonable. La traducción correcta produce la pila entera.

enum Ruta: Hashable, Codable {
    case proyecto(id: UUID)
    case tarea(id: UUID)
    case adjunto(id: UUID)
}

func pila(desde url: URL) -> [Ruta]? {
    guard url.scheme == "dios",
          let partes = URLComponents(url: url, resolvingAgainstBaseURL: false)
    else { return nil }
    // dios://proyecto/UUID/tarea/UUID  produce DOS escalones, no uno
    return Parser.rutas(de: partes.path)
}

Fíjate en el tipo de retorno. No devuelve una vista ni ejecuta una acción: devuelve datos, y opcionales, porque una URL puede ser inválida. Toda la lógica de enrutado profundo queda así en una función comprobable sin interfaz, que es exactamente lo que prometía la primera lección del nivel.

.onOpenURL { url in
    guard let nueva = pila(desde: url) else { return }
    path = nueva            // sustituir, no acumular
}

Sustituir el historial completo, y no añadir al existente, es casi siempre lo correcto: el usuario que abre un enlace externo espera llegar a ese sitio, no encontrárselo apilado sobre lo que estuviera haciendo hace tres días.

Un enlace universal llega por otra puerta —una actividad del sistema en lugar de una URL directa— pero desemboca en la misma función, y esa convergencia es justamente lo que quieres.

.onContinueUserActivity(NSUserActivityTypeBrowsingWeb) { actividad in
    guard let url = actividad.webpageURL,
          let nueva = pila(desde: url) else { return }
    path = nueva
}

flowchart LR
U[URL entrante] --> P[parser puro]
P --> A[array de rutas]
A --> S[NavigationStack reconstruye]
P --> N[nada si es invalida]
style P fill:#a6e3a1,color:#11111b
style N fill:#f38ba8,color:#11111b

Un historial que sabe escribirse

NavigationPath ofrece una representación codificable, pero solo bajo una condición estricta: todos los valores que contiene deben conformar a Codable además de a Hashable. Si uno solo no lo hace, la propiedad devuelve nada y no hay nada que guardar.

@State private var path = NavigationPath()

var guardable: Data? {
    guard let representable = path.codable else { return nil }
    return try? JSONEncoder().encode(representable)
}

func restaurar(desde datos: Data) {
    guard let rep = try? JSONDecoder()
        .decode(NavigationPath.CodableRepresentation.self, from: datos)
    else { return }
    path = NavigationPath(rep)
}

La decodificación necesita conocer los tipos originales, que quedan registrados por nombre dentro de la representación. De ahí una consecuencia práctica que sorprende a mucha gente: renombrar o mover un tipo de ruta invalida las pilas guardadas por versiones anteriores de la app. No es un fallo, es el precio de un contenedor con borrado de tipos que debe reconstruirlos, y se gestiona igual que cualquier migración: aceptando que una restauración puede fallar y volviendo a la raíz sin drama.

@SceneStorage("pila") private var pilaGuardada: Data?

NavigationStack(path: $path) { Raiz() }
    .onChange(of: path) { _, _ in pilaGuardada = guardable }
    .task { if let d = pilaGuardada { restaurar(desde: d) } }

El almacenamiento por escena es el sitio correcto porque la navegación es estado de una ventana, no del usuario ni del documento. En iPad y en Mac pueden convivir varias escenas de la misma app, cada una con su propio historial, y guardarlo en un almacén compartido las fundiría todas en una.

Reconstruir con criterio

Restaurar no es aplicar lo guardado sin mirar. Entre lo que se guardó y lo que se recupera pueden haber cambiado los permisos, la sesión, el contenido y hasta el esquema de datos.

func saneada(_ rutas: [Ruta]) -> [Ruta] {
    var resultado: [Ruta] = []
    for ruta in rutas {
        guard repositorio.existe(ruta) else { break }  // trunca, no descarta todo
        resultado.append(ruta)
    }
    return resultado
}

Truncar en lugar de vaciar es la política más amable: si el adjunto ya no existe pero la tarea sí, dejar al usuario en la tarea conserva la mayor parte del contexto. Vaciar entero castiga por un fallo en el último escalón.