Rust y Swift comparten una promesa poco habitual: ofrecer seguridad de memoria sin depender de un recolector de basura. Ambos dos liberan recursos de forma determinista, permiten construir abstracciones de alto nivel y evitan gran parte de los errores que sufriríamos al gestionar punteros manualmente. Sin embargo, llegan a ese resultado desde puntos de partida muy distintos.

Rust hace que la propiedad de cada valor forme parte central del lenguaje. El compilador comprueba quién posee un recurso, durante cuánto tiempo puede prestarse y en qué momento deja de ser utilizable. Swift, en cambio, combina semántica de valor para struct y enum, conteo automático de referencias para las clases y un sistema de ownership que normalmente permanece oculto tras copias implícitas.

El framework Observation dio un salto importante con @Observable, pero hasta ahora había una diferencia bastante grande entre lo que SwiftUI podía hacer automáticamente y lo que teníamos disponible fuera de una vista. En SwiftUI basta con leer una propiedad observable desde el body para que el sistema registre la dependencia y vuelva a evaluar la vista cuando cambie. En un controlador, un coordinador o una capa de infraestructura, en cambio, mantener una observación durante toda la vida de un objeto requería bastante más trabajo. Swift 6.4 y los SDK 27 incorporan withContinuousObservation precisamente para cubrir ese hueco.

Apple ha incorporado en iOS 27 un nuevo framework llamado MediaIntelligence, pensado para entender conjuntos de imágenes y el contenido temporal de los vídeos directamente en el dispositivo. A primera vista puede parecer una nueva capa del framework Vision, pero su propósito es diferente: Vision produce observaciones sobre una imagen o un fotograma; Media Intelligence conserva resultados, relaciona elementos entre distintos recursos y responde a preguntas sobre una colección completa o una línea temporal.

La concurrencia en Swift no consiste únicamente en ejecutar varias tareas a la vez. Una parte fundamental del modelo introducido con Swift Concurrency es impedir que dos contextos concurrentes accedan de forma insegura al mismo estado mutable. Sendable y @Sendable son dos de las herramientas que permiten al compilador comprobarlo incluso antes de que el código llegue a ejecutarse.

Sendable es un protocolo marcador. No define métodos ni propiedades que debamos implementar, sino una garantía semántica: un valor de un tipo Sendable puede transferirse entre distintos dominios de concurrencia sin introducir una carrera de datos. Esto ocurre, por ejemplo, cuando enviamos un valor a un actor, lo devolvemos desde una tarea o lo capturamos desde código que puede ejecutarse concurrentemente.

Durante la transición a Apple Silicon, publicar una aplicación universal fue la decisión más prudente: un único paquete contenía código arm64 para los nuevos Mac y x86_64 para los modelos Intel. Seis años después del primer Mac con M1, Apple ha empezado a cerrar esa etapa y permite que determinadas aplicaciones ya publicadas en la Mac App Store abandonen la arquitectura Intel.

La novedad afecta a las aplicaciones universales cuyo target sea macOS 13 o posterior. Si cumplen esa condición, pueden enviar una actualización que contenga únicamente arm64, aunque sus versiones anteriores también fueran compatibles con Mac Intel. Hasta ahora, la posibilidad de publicar solo para Apple Silicon estaba pensada principalmente para aplicaciones que nunca habían ofrecido soporte Intel; el cambio anunciado en las notas de App Store Connect elimina esa restricción para las aplicaciones universales elegibles.