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.

Saber que una aplicación ha sufrido un cuelgue, algún tirón de interfaz o una terminación inesperada es útil, pero muchas veces no es suficiente. El dato importante suele ser otro: qué estaba haciendo realmente la aplicación cuando ocurrió el problema. iOS 27 introduce StateReporting, un nuevo framework que permite añadir ese contexto funcional a los diagnósticos que recogen MetricKit e Instruments.

Hasta ahora, MetricKit podía decirnos que una aplicación había acumulado cierto tiempo estando bloqueada o que una animación había perdido fluidez. El problema es que esas cifras mezclaban situaciones muy distintas. Una pantalla sencilla podía funcionar perfectamente y otra mucho más pesada concentrar casi todos los problemas, pero el agregado global ocultaba esa diferencia. StateReporting permite definir estados propios de la aplicación para que MetricKit pueda relacionar determinadas métricas con ellos.

Swift Package Manager no sirve únicamente para distribuir librerías y resolver dependencias. También permite ampliar el flujo de trabajo mediante plugins escritos en Swift capaces de ejecutar herramientas, validar un proyecto, generar código o incorporar pasos adicionales al proceso de compilación.

La principal ventaja de este sistema es que la automatización pasa a formar parte del propio paquete. En lugar de depender de un script guardado en una carpeta, de una configuración manual de Xcode o de una herramienta instalada en el sistema operativo, el paquete puede declarar qué necesita, cuándo debe ejecutarse y qué permisos requiere.

Apple presentó FoundationModels en 2025 como una API nativa de Swift para trabajar con el modelo local de Apple Intelligence. La primera versión ya incluía sesiones con estado, generación estructurada mediante @Generable, streaming y llamadas a herramientas. Sin embargo, crear un asistente que permanezca activo durante mucho tiempo o que pueda cambiar de modelo plantea problemas que van más allá de enviar un prompt y recibir una respuesta.

Con iOS 27, Apple ha dado un paso más con FoundationModelsUtilities, un paquete de código abierto que reúne patrones emergentes para construir experiencias más complejas. No sustituye al framework principal ni pretende convertirse en una arquitectura completa para agentes. Su objetivo es proporcionar piezas reutilizables para resolver tres necesidades concretas:

SwiftUI incluye tres modificadores cuyos nombres parecen describir distintas versiones de una misma operación: geometryGroup(), compositingGroup() y drawingGroup(opaque:colorMode:).

Los tres crean distintos tipos de límites alrededor de una vista, pero actúan en momentos diferentes del proceso con el que SwiftUI calcula y representa la interfaz. El primero interviene en la geometría durante una animación, el segundo determina cómo se aplican los efectos de composición y el tercero rasteriza el contenido en una imagen intermedia: convierte la representación a píxeles estáticos.