Últimos articulos

Cuando una pantalla de SwiftUI solo presenta una vista modal, un Bool parece la solución más natural. El problema aparece en cuanto esa misma vista necesita abrir un formulario de creación, un editor, una pantalla de filtros y alguna opción adicional. Cada destino incorpora su propio @State, su botón y su modificador .sheet, mientras la lógica de presentación queda repartida por todo el body.

struct TravelPlanView: View {
    @State private var showsNewStop = false
    @State private var showsFilters = false
    @State private var stopToEdit: Stop?

    var body: some View {
        TripTimeline()
            .sheet(isPresented: $showsNewStop) {
                NewStopView()
            }
            .sheet(isPresented: $showsFilters) {
                FilterStopsView()
            }
            .sheet(item: $stopToEdit) { stop in
                EditStopView(stop: stop)
            }
    }
}

El código funciona, pero el número de variables y modificadores crece al mismo ritmo que los destinos. Además, el estado permite combinaciones que la interfaz no puede representar: showsNewStop y showsFilters podrían ser true al mismo tiempo. Aunque SwiftUI termine mostrando una única vista, el modelo ya no describe con precisión lo que ocurre en pantalla.

Desde iOS 15, SwiftUI permite hacer seleccionable el contenido de una vista Text con el modificador .textSelection(.enabled). La API era sencilla y útil, pero en iPhone y iPad tenía una limitación importante: al mantener pulsado, las acciones del menú contextual se aplicaban al bloque completo. Si una pantalla mostraba un párrafo largo, el usuario podía copiarlo entero, pero no elegir únicamente una palabra o una frase.

iOS 27 elimina esa limitación y lo hace sin añadir una API nueva. El mismo modificador muestra ahora el resaltado y los indicadores de selección del sistema, de modo que es posible ajustar el rango y actuar solo sobre el fragmento escogido. El cambio parece pequeño, pero acerca el comportamiento de Text al que los usuarios ya esperan encontrar en Safari, Notas y otras aplicaciones del sistema.

Durante años, hablar de Swift en Windows significaba demostrar que el compilador podía generar un ejecutable y que Foundation era capaz de resolver tareas reales fuera de los sistemas de Apple. Esa etapa ya está superada. Swift se utiliza en Windows sobre arquitecturas AMD64 y ARM64, tanto en herramientas de línea de comandos como en aplicaciones con interfaz gráfica, y para red algunos proyectos recurren directamente a URLSession mientras otros se integran con componentes escritos en C++.

Los Universal Links suelen presentarse como una funcionalidad sencilla: se añade la capability de Associated Domains al proyecto, se publica un fichero apple-app-site-association en el servidor y la aplicación procesa la URL recibida. Esta explicación es correcta, pero solo describe el camino ideal.

Cuando una aplicación trabaja con varios dominios, distintas versiones, entornos de pruebas, rutas localizadas por idioma o campañas de marketing, ese pequeño fichero JSON se convierte en parte de la infraestructura del producto. Un error no produce necesariamente un crash ni una respuesta HTTP fallida. El enlace, sencillamente, se abre en el navegador y la causa puede encontrarse en la aplicación, el servidor, la caché de Apple o una regla de redirección demasiado amplia.

Durante años, On-Demand Resources ha permitido publicar aplicaciones y juegos cuyo contenido no cabe —o no conviene incluir— dentro de la descarga inicial. En lugar de empaquetar todos los vídeos, audios, modelos 3D o mapas dentro de la aplicación, Xcode los agrupa en asset packs que el App Store aloja y entrega cuando son necesarios. El resultado es una instalación más pequeña y un primer arranque más rápido.

Sin embargo, esta tecnología ya ha entrado en su recta final. Apple ha marcado On-Demand Resources como obsoleto a partir de iOS 27, iPadOS 27, tvOS 27 y visionOS 27. Las aplicaciones existentes continuarán funcionando a corto plazo, pero el soporte se retirará en futuras versiones. Apple no ha anunciado todavía una fecha concreta para su eliminación, así que no hay una urgencia inmediata por retirar el código existente, aunque sí una señal inequívoca para no diseñar nuevas arquitecturas alrededor de NSBundleResourceRequest.