DEV Community: GoyesDev

[SC] Migrando a Notificaciones seguras (en términos de concurrencia)

GoyesDev — Mon, 25 May 2026 22:21:05 +0000

Comprensión durante la lectura

¿Por qué las notificaciones estándar de `NotificationCenter` no son thread-safe en Swift Concurrency?

Porque el tipo Notification es nonisolated por defecto, incluso cuando se publica desde un actor conocido como el MainActor. Esto impide que el compilador razone sobre la seguridad de hilos al llamar métodos con aislamiento específico como @MainActor, incluso aunque recibamos la notificación en el hilo principal.

func startObservingOldWay() {
  NotificationCenter.default.addObserver(forName: UIApplication.didBecomeActiveNotification, object: nil, queue: .main, using: { [weak self] notification in
    self?.handleDidBecomeActive()
  })
}

@MainActor
func handleDidBecomeActive() {
  print("Did become active!")
}

¿Qué problema concreto resuelve `MainActorMessage` frente al API anterior?

Garantiza que el closure de observación se ejecute en el main actor, eliminando la advertencia de concurrencia y permitiendo llamar directamente a métodos @MainActor sin conversiones manuales.

func startObservingNewWay() {
  token = NotificationCenter.default.addObserver(of: UIApplication.self, for: .didBecomeActive) { [weak self] message in
    self?.handleDidBecomeActive()
  }
}

@MainActor
func handleDidBecomeActive() {
  print("Did become active!")
}

¿Cuál es la diferencia clave entre `MainActorMessage` y `AsyncMessage`?

MainActorMessage entrega la notificación sincrónicamente en el main actor. AsyncMessage la entrega de forma asíncrona en un aislamiento arbitrario y puede publicarse desde cualquier dominio de aislamiento.

struct RecentBuildsChangedMessage: NotificationCenter.AsyncMessage {
  typealias Subject = [RecentBuild]

  let recentBuilds: Subject
}

extension NotificationCenter.MessageIdentifier where Self == NotificationCenter.BaseMessageIdentifier<RecentBuildsChangedMessage> {
  static var recentBuildsChanged: NotificationCenter.BaseMessageIdentifier<RecentBuildsChangedMessage> {
    .init()
  }
}

let recentBuilds = [RecentBuild(appName: "Stock Analyzer")]
let message = RecentBuildsChangedMessage(recentBuilds: recentBuilds)
NotificationCenter.default.post(message)

recentBuildsToken = NotificationCenter.default.addObserver(of: [RecentBuild].self, for: .recentBuildsChanged) { [weak self] message in
  self?.handleNewRecentBuilds(message.recentBuilds)
}

¿Qué ventajas concretas aporta migrar a notificaciones con tipo fuerte (strongly typed)?

Se elimina la necesidad de hacer casting manual desde notification.object as? [RecentBuild], se reduce el boilerplate y se obtiene verificación en tiempo de compilación, además de la seguridad de hilos.

¿Qué cambio de comportamiento en threading puede ocurrir al migrar al nuevo API?

En el API anterior las notificaciones se entregaban en la misma cola desde la que se publicaban. Con el nuevo API, el @MainActor se aplica más estrictamente, lo que puede cambiar el comportamiento de threading de la app tras la migración.

Bibliografía

Van der Lee, A. (2025). Swift Concurrency Course [Curso en línea]. avanderlee.com.

[SC] Migrando desde programación reactiva (RxSwift y Combine)

GoyesDev — Mon, 25 May 2026 22:01:50 +0000

Comprensión durante la lectura

¿Por qué la comunidad Swift está migrando de RxSwift y Combine?

Combine está recibiendo menos actualizaciones y la comunidad de programación reactiva está perdiendo popularidad.

¿Existe alguna alternativa nativa en Swift 6 para la observación reactiva de valores?

Existe una propuesta en curso SE-475 Transactional Observation of Values que técnicamente permite observar cambios sobre un atributo y procesarlos como si fuera un AsyncSequence:

let names = Observations { person.name }

Task.detached {
  for await name in names {
    print("Name 1 was updated to: \(name)")
  }
}


Task.detached {
  for await name in names {
    print("Name 2 was updated to: \(name)")
  }
}

¿Cómo se implementa el debouncing sin Combine?

$searchQuery
  .debounce(for: .milliseconds(500), scheduler: DispatchQueue.main)
  .sink(receiveValue: { [weak self] query in
    guard !query.isEmpty else {
      self?.searchResults = Self.articleTitlesDatabase
    return
  }

  /// A simplified static result and search implementation.
  self?.searchResults = Self.articleTitlesDatabase
    .filter { $0.lowercased().contains(query.lowercased()) }
  })
  .store(in: &cancellables)

¿Cómo funciona el reemplazo de un pipeline de `debounce` usando `Task.sleep` y cancelación manual?

/// Using manual cancellation management.
func search(_ query: String) {
  /// Cancel any previous searches that might be 'sleeping'.
  currentSearchTask?.cancel()

  currentSearchTask = Task {
    do {
      /// Debounce for 0.5 seconds to wait for a pause in typing before executing the search.
      try await Task.sleep(for: .milliseconds(500))

      print("Starting to search!")

      guard !query.isEmpty else {
        searchResults = Self.articleTitlesDatabase
        return
      }

      /// A simplified static result and search implementation.
      searchResults = Self.articleTitlesDatabase
        .filter { $0.lowercased().contains(query.lowercased()) }
    } catch {
      print("Search was cancelled!")
    }
  }
}

Problema con el `NotificationCenter`

NotificationCenter.default.publisher(for: .someNotification)
  .sink { [weak self] _ in
    self?.didReceiveSomeNotification()
  }.store(in: &cancellables)

Notifications today rely on an implicit contract that an observer’s code block will run on the same thread as the poster, requiring the client to look up concurrency contracts in documentation, or defensively apply concurrency mechanisms which may or may not lead to issues. Notifications do allow the observer to specify an OperationQueue to execute on, but this concurrency model does not provide compile-time checking and may not be desirable to clients using Swift Concurrency.

Se espera que el observador del NotificationCenter corra en el mismo hilo que emite la notificación.

¿Por qué los closures de `sink` no ofrecen seguridad en tiempo de compilación con actores?

Combine no está integrado con el sistema de concurrencia de Swift 6, por lo que el compilador no puede verificar si el código dentro de un sink es seguro respecto al aislamiento de actores.

NotificationCenter.default.publisher(for: .someNotification)
  .sink { [weak self] _ in
    self?.didReceiveSomeNotification()
    // ✅ Compila sin errores... pero puede crashear
  }.store(in: &cancellables)

// ❌ El compilador advierte que esto es inseguro
NotificationCenter.default.addObserver(...)

El closure de sink es esencialmente una caja negra para el compilador en términos de concurrencia. Swift no sabe en qué hilo se va a ejecutar ese closure, por lo que no puede garantizar que respete el aislamiento del @MainActor.

El riesgo concreto es el siguiente: si una notificación es enviada desde un Task.detached (fuera del hilo principal), el closure de sink se ejecutará en ese mismo hilo, violando el aislamiento del actor y produciendo un crash en tiempo de ejecución, no un error en tiempo de compilación.

Recordar sin releer

¿Cuál es el riesgo de threading cuando se usa `sink` junto con actores de Swift Concurrency?

¿Por qué `receive(on:)` no es suficiente para resolver problemas de aislamiento de actores?

¿Cuándo tiene sentido quedarse con Combine en lugar de migrar?

Revisión y síntesis

¿Cuáles son las dos soluciones propuestas para manejar `NotificationCenter` con actores?

¿Qué ventaja concreta ofrece reescribir código en Swift Concurrency respecto a la seguridad en tiempo de compilación?

En tu opinión, ¿los argumentos del autor son suficientes para justificar una migración completa en un proyecto grande?

Bibliografía

Van der Lee, A. (2025). Swift Concurrency Course [Curso en línea]. avanderlee.com.

[SC] ¿Cuándo y cómo usar @preconcurrency ?

GoyesDev — Mon, 25 May 2026 20:59:48 +0000

Comprensión durante la lectura

¿Qué es el atributo `@preconcurrency` y para qué sirve?

El atributo @preconcurrency permite silenciar los warnings de concurrencia relacionados con conformar el protocolo Sendable.

La idea es que hay dependencias de terceros que están fuera de nuestro control y no podemos modificar. Por esta razón, podemos importar dichas dependencias así:

@preconcurrency import <some_module>

¿En qué se diferencia `@preconcurrency` de `@unchecked Sendable`?

@unchecked Sendable sirve para indicar que el tipo marcado ES Sendable, y que nosotros vamos a asegurarlo manualmente. El compilador no necesita revisar.

@preconcurrency sirve solo para silenciar las advertencias de la dependencia importada. Esto no necesariamente significa que dicha dependencia sea segura para concurrencia.

¿Qué riesgos conlleva suprimir las advertencias de concurrencia con este atributo?

Se puede ocultar una vulnerabilidad importante relacionada con el manejo de varios hilos en la biblioteca de terceros.

¿Qué sucede con las importaciones `@preconcurrency` al migrar a Swift 6?

Si una dependencia de tercero importada con @preconcurrency se actualiza y ya no presenta advertencias de tipo @preconcurrency, entonces resultará en un error de compilación una vez se use Swift 6.

Recordar sin releer

¿Puedes explicar con tus propias palabras cuándo tiene sentido usar `@preconcurrency` y cuándo no?

¿Qué pasos debería seguir un equipo que usa `@preconcurrency` para no olvidarse de ese código en el futuro?

Revisión y síntesis

¿Cuál es la alternativa preferible a usar `@preconcurrency` según el artículo, y por qué?

¿Qué estrategia recomienda el autor para gestionar las importaciones marcadas con `@preconcurrency` a largo plazo?

Bibliografía

Van der Lee, A. (2025). Swift Concurrency Course [Curso en línea]. avanderlee.com.

[SC] Técnicas para reescribir closures en código async/await

GoyesDev — Mon, 25 May 2026 20:46:19 +0000

Comprensión durante la lectura

¿Qué problema resuelve migrar de closures a `async/await`, y por qué se describe el problema anterior como "Closure-hell"?

El uso de closures puede ser peligroso porque:

el desarrollador puede olvidar invocar el closure para devolver el resultado.
Puede haber varios closures anidados lo que dificulta el mantenimiento
El manejo de errores también es complicado, porque los datos devueltos son opcionales.

¿Cuáles son las tres opciones de refactorización que ofrece Xcode y en qué se diferencian entre sí?

Add Async Wrapper: Crea un método "wrapper" de tipo async/await que invoca el método que usa closures.
Add Async Alternative: Escribe una versión alternativa al método que usa closures, pero usando async/await.
Convert Function to Async: Reemplaza la función en cuestión que usa closures, con otra que usa async/await.

¿Por qué el artículo recomienda usar primero un `async wrapper` en lugar de reescribir directamente la lógica central?

En el caso de agregar un wrapper, o de agregar una alternativa async, el autor sugiere marcar la versión que usa closure con:

@available(*, deprecated, renamed: "fetchImage(urlRequest:)", message: "Consider using the async/await alternative.")

Una vez se ponga esa etiqueta, aparecerá un warning en los puntos clientes que se deben modificar.

Esto permite concentrarse en reescribir la sintaxis async/await en el código de producción y en las pruebas, en lugar de preocuparse por la correcta conversión de la lógica asíncrona.

** LO MAS IMPORTANTE ES RESCRIBIR PRIMERO LAS PRUEBAS PARA QUE USEN EL WRAPPER ASYNC/AWAIT **

¿Qué dos reglas críticas hay que respetar al usar `withCheckedThrowingContinuation`?

Hacer "resume" exactamente una vez: 0 veces provoca una fuga. Más de 1, provoca un error en tiempo de ejecución. La variante "checked" (i.e. withCheckedThrowingContinuation) atrapa doble "resume"s en tiempo de desarrollo.
Evitar deadlocks: Si el closure que se pasa al "continuation" está esperando a algo que solo ocurre después del "resume", entonces aparece un "deadlock".

¿Por qué las herramientas de refactorización automática de Xcode no siempre producen el resultado óptimo?

A veces, a pesar de que la firma del método pasa a ser async/await, internamente puede usar una aproximación basada en closures, por lo que no termina siendo un refactor muy efectivo.

Al leer el código de `ImageFetcher`, ¿qué rol cumple el bloque `do`-`catch` dentro del closure de `URLSession`?

Captura un error en el catch y lo arroja con el "continuation".

¿Cómo cambia la implementación final de `ImageFetcherMigrated` respecto a las versiones intermedias generadas por Xcode?

Las versiones intermedias igual hacían la petición con URLSession usando closures. La versión final de ImageFetcherMigrated usa URLSession con su versión async (i.e. await URLSession.shared.data(for: urlRequest)).

Recordar sin releer

¿puedes describir los pasos del proceso de migración recomendado, en orden?

¿Qué ventajas concretas tiene la versión final con `async`/`await` respecto a la versión con closures?

Revisión y síntesis

¿Qué limitaciones actuales tienen las herramientas de Xcode para esta tarea, y qué mejora se menciona para el futuro?

¿Cómo se relaciona este proceso de migración con la estrategia general de mantener la estabilidad del código existente?

Bibliografía

Van der Lee, A. (2025). Swift Concurrency Course [Curso en línea]. avanderlee.com.

[SC] Herramienta de migración para "Upcoming features"

GoyesDev — Mon, 25 May 2026 20:26:34 +0000

Comprensión durante la lectura

¿Por qué es importante migrar un proyecto a las upcoming features de Swift 6?

Actualmente son opcionales, pero en un futuro será obligatorio tenerlas.

¿Qué limitaciones tiene la herramienta de migración automática mencionada en el artículo?

En un proyecto de iOS, la herramienta solo pone una advertencia en los puntos donde hace falta la migración. Esto obliga al desarrollador a revisar advertencia por advertencia y darle la solución que corresponda.

La herramienta de migración automática aplicada a paquetes de SPM funciona de forma independiente.

swift package migrate [<options>] --to-feature <to-feature>
swift package migrate --target <target_name> --to-feature <to-feature>

swift package migrate --to-feature ExistentialAny
swift package migrate --target "Diagnostics" --to-feature ExistentialAny

¿qué hace exactamente el valor Migrate en los Build Settings de Xcode?

Pone una advertencia sobre el punto que debe ser migrado.

¿En qué condición se actualiza el archivo Package.swift al ejecutar el comando de migración?

Si la migración es exitosa, sin errores, se actualiza el archivo Package.swift con:

swiftSettings: [
  .enableUpcomingFeature("ExistencialAny")
]

Recordar sin releer

¿cuál es el comando exacto para migrar únicamente un target específico de un paquete Swift?

¿Cuántos fix-its aplicó automáticamente el comando en el ejemplo del artículo y en cuántos archivos?

¿Qué propuesta de Swift (SE-XXX) introdujo la característica `ExistentialAny` usada como ejemplo?

Revisión y síntesis

¿Qué requisito deben cumplir las propuestas futuras de Swift para incluir soporte de migración, según el artículo?

En tu opinión, ¿qué ventaja práctica ofrece la migración por terminal frente a la de Xcode para proyectos de gran escala?

¿Qué tema aborda la lección siguiente mencionada al final del artículo, y cómo se relaciona con la migración a concurrencia?

Bibliografía

Van der Lee, A. (2025). Swift Concurrency Course [Curso en línea]. avanderlee.com.

[SC] El BuildSetting "Approachable Concurrency"

GoyesDev — Sat, 23 May 2026 16:34:27 +0000

"Approachable concurrency" es la unión de las siguientes propuestas:

5.9 SE-401: Disable Outward Actor Isolation Inference
6.0 SE-418: Infer Sendable for methods & key path literals
6.0 SE-434: Usability of global-actor-isolated types
6.2 SE-461: nonisolated(nonsending) by Default
6.2 SE-466: Control default actor isolatioin inference
6.2 SE-470: Global-actor isolated conformances
6.2 SE-486: Migration tooling for Swift features

Enables upcoming features that aim to provide a more approachable path to Swift Concurrency: DisableOutwardActorInference, GlobalActorIsolatedTypesUsability, InferIsolatedConformances, InferSendableFromCaptures, and NonisolatedNonsendingByDefault.

En el proyecto de iOS se busca SWIFT_APPROACHABLE_CONCURRENCY.

Revisión de las propuestas:

Disable Outward Actor Isolation Inference

Declarations that are not explicitly annotated with either a global actor or nonisolated can infer global actor isolation from several different places:

A struct or class containing a wrapped instance property with a global actor-qualified wrappedValue infers actor isolation from that property wrapper:

@propertyWrapper
struct UIUpdating<Wrapped> {
  @MainActor var wrappedValue: Wrapped
}

struct CounterView { // infers @MainActor from use of @UIUpdating
  @UIUpdating var intValue: Int = 0
}

El código anterior era confuso. Por esta razón:

This proposal advocates for removing this inference rule when compiling in the Swift 6 language mode. Given the example above, CounterView would no longer infer @MainActor isolation in Swift 6.

Usability of global-actor-isolated types

Esta propuesta de Swift 6.0 resuelve tres problemas de usabilidad relacionados con tipos que están aislados a actores globales (como @MainActor).

Problema 1: Propiedades `var` en `structs` aislados

Antes: Si tenías un struct con @MainActor, las propiedades var no podían usarse fuera del actor sin marcarlas nonisolated(unsafe), lo cual era innecesariamente alarmante:

@MainActor struct S {
  nonisolated(unsafe) var x: Int = 0 // feo e innecesario
}

Después: Si la propiedad es de tipo Sendable (como Int), Swift infiere automáticamente nonisolated dentro del mismo módulo, porque acceder a un valor Sendable nunca puede causar una carrera de datos:

@MainActor struct S {
  var x: Int = 0 // Swift lo trata como nonisolated dentro del módulo
}

La clave es que esto solo aplica dentro del módulo, porque desde afuera alguien podría convertir esa propiedad en "computed" (con lógica aislada al actor) y eso rompería compatibilidad.

Problema 2: Closures aislados y @Sendable

Antes: Un closure @MainActor no era automáticamente @Sendable, lo que causaba errores absurdos al pasarlo a un Task:

func test(fn: @escaping @MainActor () -> Void) {
  Task {
    await fn() // ❌ error: tipo no-Sendable capturado
  }
}

Después: @Sendable se infiere automáticamente en closures aislados a un actor global. Tiene sentido porque ese closure siempre corre en el mismo actor, así que nunca habrá acceso concurrente. Incluso puede capturar valores non-Sendable de forma segura:

class NonSendable {}

func test() {
  let ns = NonSendable()
  let closure = { @MainActor in
    print(ns) // ✅ seguro, siempre corre en MainActor
  }
  Task { await closure() }
}

Problema 3: Subclases aisladas de superclases no-Sendable

Antes: Esto daba un error aunque en muchos casos sería perfectamente válido:

class Base {}          // no-Sendable

@MainActor
class Sub: Base {}     // ❌ error en Swift 5.10

El problema real era que @MainActor implica Sendable, lo que permitía pasar Sub entre contextos de concurrencia heredando estado mutable no protegido de Base.

Después: Se permite la subclase aislada, pero sin conformancia a Sendable. Así se evita el peligro sin bloquear el patrón por completo:

@MainActor
class Sub: Base {}  // ✅ permitido, pero Sub no es Sendable

Global-actor isolated conformances

Tipos de datos aislados en MainActor pueden conformar protocolos en @MainActor.

Inferring `Sendable` for methods and key path literals

Problema 1: Referencias a métodos y `@Sendable`

En Swift puedes tomar una referencia a un método sin llamarlo. Esto se llama referencia parcial o unapplied method reference:

struct Counter: Sendable {
  func increment() { ... }
}

// Referencia al método sin llamarlo
let fn = Counter.increment  // tipo: (Counter) -> () -> Void

El problema era que al pasar esa referencia a un contexto concurrente, Swift se quejaba de que no era @Sendable, aunque el tipo Counter sí lo fuera:

// ❌ Antes: error aunque Counter es Sendable
Task {
  let fn = Counter.increment  // 'Counter.increment' no es @Sendable
}

Esto era inconsistente: si Counter es Sendable, cualquier referencia a sus métodos también debería serlo, porque no capturan estado no-Sendable.

Después: el compilador infiere @Sendable automáticamente:

// ✅ Ahora: funciona sin anotaciones
Task {
  let fn = Counter.increment  // @Sendable inferido
}

Problema 2: Key paths y Sendable

Un key path es una referencia a una propiedad que puedes almacenar y usar después:

struct Person {
  var name: String
}

let kp = \Person.name  // KeyPath<Person, String>

El problema era que Swift marcaba los key paths como Sendable de forma conservadora, lo que causaba advertencias confusas incluso cuando no había ningún riesgo real:

// ❌ Antes: advertencia innecesaria en contextos no concurrentes
let kp = \Person.name  // ⚠️ advertencia: key path debería ser Sendable

Y al revés, si necesitabas que fuera Sendable explícitamente, no había forma de anotarlo.

Después: dos mejoras:

// ✅ Sin advertencia si no se usa en contexto concurrente
let kp = \Person.name  // Sendable solo se infiere si hace falta

// ✅ Puedes forzarlo explícitamente cuando lo necesitas
let kp: any KeyPath<Person, String> & Sendable = \Person.name

nonisolated(nonsending) by Default

Las funciones async no aisladas (nonisolated) siempre saltaban a un executor genérico al ejecutarse. Con esta propuesta, en cambio, heredan el actor del contexto que las llama, a menos que se marquen explícitamente con @concurrent.

Para activar manualmente los Upcoming features en un paquete de SPM

Usar .swiftLanguageMode(.v5)

.target(
  name: "YourPackageTarget",
  swiftSettings: [
    .swiftLanguageMode(.v5)
    .enableUpcomingFeature("DisableOutwardActorInference"),
    .enableUpcomingFeature("GlobalActorIsolatedTypesUsability"),
    .enableUpcomingFeature("InferIsolatedConformances"),
    .enableUpcomingFeature("InferSendableFromCaptures"),
    .enableUpcomingFeature("NonisolatedNonsendingByDefault")
  ]
)

Notas del video

Pasos para implementar concurrency:

Escribir código secuencial, de un solo hilo.
Suspender la ejecución, sin paralelismo.
Introducir paralelismo para mejorar el desempeño.

¿Cuáles son los nuevos cambios?

NonisolatedNonsendingByDefault.
- `nonisolated(nonsending) no envía el objeto/estado a otro dominio de aislamiento.

Si se activa Migrate sobre NonisolatedNonsendingByDefault entonces aparece un warning sobre el código:

swift // ⚠️ Feature 'NonisolatedNonsendingByDefault' will cause nonisolated async instance method 'performAsync' to run on the calle's actor; use '@concurrency' to preserve behavior.

En el warning aparece un signo de interrogación para aprender más y también un botón "Fix" para aplicar el cambio.

Es importante apoyarse en el "Migration tooling" porque la migración manual puede ser peligrosa.

Control default actor isolation inference

Originalmente todo es nonisolated. Sin embargo, se puede poner MainActor por defecto en todo.
Puede ser peligroso usar MainActor por defecto.
Para nuevos proyectos, sirve tener MainActor por defecto. Cuando se requiera mejor desempeño, se puede cambiar a nonisolated o @concurrent. Sin embargo, en código legado, es mejor hacer la migración manual.

Global-actor isolated conformances

swift @MainActor final class PersonViewModel { let id: UUID var name: String init(id: UUID, name: String) { self.id = id self.name = name } } // ❌ Conformance of 'PersonViewModel' to protocol 'Equatable' crosses into main actor-isolated code and can cause data races extension PersonViewModel: Equatable { static func == (lhs: PersonViewModel, rhs: PersonViewModel) -> Bool { lhs.id == rhs.id } }

Soluciones:

1. Marcar con `nonisolated` el método de `Equatable` (i.e. `nonisolated static func ==`).

Esto permite usar el método desde cualquier dominio de aislamiento. Sin embargo, al hacer esto, es obligatorio asegurarse que los datos a usar son Sendable.

swift extension PersonViewModel: Equatable { nonisolated static func == (lhs: PersonViewModel, rhs: PersonViewModel) -> Bool { lhs.id == rhs.id && lhs.name == rhs.name // ❌ Main actor-isolated property 'name' can not be referenced from a nonisolated autoclosure } }

2. Conformar un protocolo solo en un actor global (i.e. `extension PersonViewModel: @MainActor Equatable`).

Con esto se puede comparar sin problema (usando Equatable) siempre que se esté en MainActor. Si se está en otro dominio de aislamiento, habrá un error.

swift extension PersonViewModel: @MainActor Equatable { static func == (lhs: PersonViewModel, rhs: PersonViewModel) -> Bool { lhs.id == rhs.id && lhs.name == rhs.name } }

Estrategias de migración

No activar "Approachable Concurrency" de forma grupal. En su lugar, activar las funcionalidades una por una. Luego, hacer un PR por cada "upcoming feature". Esto hará más entendible los cambios.

Al final de todo el proceso sí se activa "Approachable Concurrency".

Algunos consejos:

Hacerlo de forma iterativa.
Sendable por defecto.
Evitar refactorizar todo durante la marcha. El foco es concurrency.
Hacer cambios pequeños en un PR que pueda ser revisado rápidaemtne.
En nuevos proyectos: activar 1) Swift 6.2, 2) aislamiento por defecto en MainActor y 3) "Approachable concurrency".
No aislar todo en MainActor.

¿Cómo migrar código existente?

Encontrar código aislado. Posiblemente un solo archivo o clase pequeña.
Incrementar la validación estricta de concurrencia. Pasar primero a Targeted y luego Complete.
Habilitar "Upcoming Features" uno a uno.
Deshabilitar/reiniciar los settings modificados.
Someter PR a revisión.
Cuando todo esté listo, activar Swift 6.2.

Error en tiempo de ejecución

"Block was expected to execute on queue []"

El sink de combine no funciona bien con atributos marcados con MainActor. Nada impide llamar sink desde un hilo de segundo plano. Artículo.

`for await` no puede tener `return` en su interior.

En lugar de usar return, debe haber continue al interior de for await.

Bibliografía

Van der Lee, A. (2025). Swift Concurrency Course [Curso en línea]. avanderlee.com.

[SC] Pasos para migrar a Swift 6 y verificación estricta de concurrencia

GoyesDev — Fri, 22 May 2026 11:34:25 +0000

Comprensión durante la lectura

¿Por qué se recomienda comenzar la migración con un fragmento de código aislado?

Entre menos dependencias tenga un fragmento de código más fácil es hacer la migración. Que haya dependencias significa que aparecerán casos donde, luego de arreglar 50 errores, aparecen 80 más.

¿Qué ventaja ofrece actualizar las dependencias de terceros antes de habilitar el "strict concurrency checking"?

Puede ser que el código que planeo migrar dependa de otras bibliotecas de terceros. En este caso, vale la pena primero actualizar dichas dependencias, en caso de que estas estén al día con el uso de Swift Concurrency.

De hecho, si las dependencias de terceros ya introdujeron cambios para estar al día con strict concurrency checking, muy probablemente se le exigirá a mi código que introduzca algunos cambios incluso antes de habilitar el "strict concurrency checking".

¿Vale la pena usar `@MainActor` por defecto?

Si se está trabajando en una aplicación móvil, es buena idea activar @MainActor por defecto. Esto va a resolver muchas advertencias y errores.

En un proyecto de iOS buscar "Default Actor Isolation". En un paquete de SPM:

.target(
    name: "DefaultActorIsolationPackage",
    swiftSettings: [
        .defaultIsolation(MainActor.self)
    ]
)

¿Qué diferencia hay entre los niveles `Minimal`, `Targeted` y `Complete` de `strict concurrency checking`?

Minimal Solo revisa código que tenga palabras clave de concurrencia explícita: async/await, @Sendable, @MainActor. Todo lo demás se ignora.
Targeted revisa todo tipo que conforma Sendable, aunque no se async directamente.
Complete revisa absolutamente todo el código base, incluso si no toca concurrencia. Este nivel pregunta: "¿Podría este código, algún día, cruzar un isolation domain".

Consideremos los siguientes escenarios:

class UserCache {
  var name: String = ""
  var age: Int = 0
}
func loadUser() {
  let cache = UserCache()
  cache.name = "Ana"
}

Minimal: No hay warning porque no hay async, @Sendable ni @MainActor.
Targeted: No hay warning porque no conforma Sendable ni usa concurrencia.
Complete: warning - UserCache se un class con propiedades mutables y no es Sendable.

class UserCache {
  var name: String = ""
}
func doWork(completion: @escaping @Sendable (UserCache) -> Void) {
  let cache = UserCache()
  completion(cache) // captura UserCache dentro de @Sendable
}

Minimal: warning - El parámetro es @Sendable, pero UserCache no conforma Sendable.
Targeted: warning - Igual que minimal.
Complete: error - Convierte en error el warning de Sendable.

struct Config: Sendable {
  var timeout: Int
  var logger: Logger // Logger es una class, no Sendable
}
class Logger {
  var prefix: String = ""
}
func run(config: Config) {
  // código síncrono, sin async
}

Minimal: nada - run es síncrono, así que no valida nada.
Targeted: error - Config es Sendable, pero su propiedad logger no.
Complete: error - Igual que Targeted. Además, advierte que Logger no es Sendable y se puede usar en cualquier otro lado.

En SPM se activa así:

.target(
  name: "CoreExtensions",
  dependencies: ["Logging"],
  path: "CoreExtensions/Sources",
  swiftSettings: [
    /// Used to be like this in Xcode 14:
    SwiftSetting.unsafeFlags(["-Xfrontend", "-strict-concurrency=complete"]),
    /// Xcode 15, 16, 26, and up. Remove `=targeted` to use the default `complete`. Potentially isolate to a platform to further reduce scope.
    .enableExperimentalFeature("StrictConcurrency=targeted", .when(platforms: [.macOS]))
  ]
)

¿En qué situación tendría sentido quedarse en un paso intermedio como agregar alternativas `async` en lugar de migrar por completo?

Puede ser que el fragmento de código aislado sobre el que estemos trabajando sea una dependencia de algún otro módulo. En este caso, se puede proveer una alternativa async/await del API que permita a otro desarrollador migrar los clientes a Swift Concurrency.

Al proveer una alternativa async/await se puede agregar un "Async wrapper" desde el menú "Refactor" y poner la siguiente etiqueta en el código que recibe closures:

@available(*, deprecated, renamed: "fetchImage(urlRequest:)", message: "Consider using the async/await alternative.")

La etiqueta anterior va a levantar una advertencia en todos los puntos donde se use la versión con closures, lo que permitirá identificar con rapidez donde se debe reemplazar con la versión que usa async/await.

Usar un "Async wrapper" puede ser útil porque permite a los otros desarrolladores avanzar en la migración mientras yo me enfoco en construir la solución final de Swift Concurrency por detrás.

¿Por qué es útil conformar `Sendable` en los tipos de datos de un paquete?

Un paquete puede ser ampliamente usado por algún cliente. En este caso, conviene conformar Sendable para que se pueda usar con tranquilidad en lugares donde sí hay cambios de dominio de aislamiento.

¿Qué relación existe entre el `swift-tools-version` y el modo de lenguaje Swift 6?

swift-tools-version permite elegir la versión del lenguaje de un paquete (de SPM). Al elegir // swift-tools-version: 6.0 luego se puede poner en versión 5 a algunas dependencias específicas con .swiftLanguageMode(.v5).

.target(
    name: "CoreNetworking",
    swiftSettings: [
        .swiftLanguageMode(.v5)
    ]
)

Recordar sin releer

Sin mirar el artículo, ¿puedes enumerar los 9 pasos de la migración en orden?

¿Cómo explicarías con tus propias palabras la diferencia entre `.swiftLanguageMode(.v5)` y cambiar el `swift-tools-version` a 6.0?

¿Qué hace exactamente el atributo `@available(*, deprecated, renamed:)` y por qué se prefiere sobre la versión sin `deprecated`?

Revisión y síntesis

¿Qué pasos del proceso considera el autor como opcionales y por qué?

¿De qué manera el concepto de `Default Actor Isolation` en Swift 6.2 cambia la estrategia de migración respecto a versiones anteriores?

Si tuvieras que migrar un proyecto con muchas dependencias entrelazadas, ¿qué ajustes harías al orden propuesto en el artículo?

¿Qué relación existe entre `Approachable Concurrency` y los "upcoming features" mencionados al final?

Bibliografía

Van der Lee, A. (2025). Swift Concurrency Course [Curso en línea]. avanderlee.com.

[SC] Seis hábitos para una migración exitosa hacia Swift 6

GoyesDev — Tue, 19 May 2026 11:38:46 +0000

Comprensión durante la lectura

¿Por qué el autor recomienda abordar la migración por iteraciones en lugar de hacerlo todo de una vez?

Es más fácil migrar 30 minutos al día por varios días, que dejar la aplicación rota un largo tiempo mientras se arreglan todos los errores. Para esto, activar el "chequeo" estricto de swift, arreglar algunos "warnings" y luego volver a apagarlo.

¿Qué significa hacer los tipos "`Sendable` por defecto" y por qué es relevante para equipos de trabajo?

El nuevo código debe escribirse conformando Sendable por defecto y usando async/await. La idea es no usar el paradigma viejo en el código nuevo.

¿Cuándo y por qué debería usarse el modo Swift 6 en proyectos nuevos, aunque el proyecto principal aún no haya migrado?

Activar Swift 6 temporalmente y revisar que el código nuevo pase la validación. De esa forma se evita aumentar la deuda técnica y que crezca el scope de la migración.

¿Por qué el autor advierte en contra de refactorizar durante la migración, si en principio refactorizar es algo positivo?

El autor sugiere concentrarse en hacer la migración a Swift 6 y no hacer ningún refactor en el camino, a no ser que el refactor sea algo bloqueante para la migración.

¿Qué ventaja tiene abrir pull requests pequeños y enfocados durante el proceso de migración?

Los PRs grandes son más difíciles de revisar y menos probable de ser integrados rápidamente. Por esto, si se actualizó una sola clase a Swift Concurrency, es buena idea abrir un PR e integrarlo en la rama feature/swift-6-migration. Esto es un checkpoint pequeño durante la migración y es una medida de progreso.

¿Cuál es el riesgo de abusar del atributo `@MainActor` y en qué casos sí tiene sentido usarlo ampliamente?

La mayor parte de aplicaciones pueden tener @MainActor por defecto activado. Sin embargo, no siempre es buena idea marcar absolutamente todo con @MainActor, sino que conviene pensar si se puede aislar el código en otro actor.

Recordar sin releer

Revisión y síntesis

Bibliografía

Van der Lee, A. (2025). Swift Concurrency Course [Curso en línea]. avanderlee.com.

[SC] Swift Concurrency Extras (Point-Free)

GoyesDev — Thu, 14 May 2026 11:49:44 +0000

Comprensión durante la lectura

¿Por qué las pruebas asíncronas en Swift pueden ser inestables (flaky) cuando se usan tareas no estructuradas?

Aunque el artículo era sobre pruebas inestables en relación con asincronismo, en realidad tenía que ver con la incapacidad de detectar un cambio interno en un método sobre una variable que podía cambiar varias veces y una prueba de caracterización no servía.

¿Qué es `withMainSerialExecutor` y cuál es su propósito dentro de los tests?

La biblioteca "Swift Concurrency Extras" ofrece el método withMainSerialExecutor(operation:) que ejecuta cierto código en el executor serial del MainActor. Esto implica que, para que funcione, tiene que aislarse la prueba o la suite de pruebas en MainActor.

Por otro lado, es obligatorio que donde se use withMainSerialExecutor se defina la suite como serial:

@Suite(.serialized)
@MainActor
final class ImageFetcherSwiftTesting {
  // ...
}

Se usa de la siguiente manera:

await withMainSerialExecutor {
  // Everything performed in this scope is performed serially...
}

En el artículo se usa en conjunto con await Task.yield() para hacer que una Task ceda la ejecución a otra. Particularmente, se tenía una Task en la prueba que envolvía el llamado al código de producción que también ejecutaba una Task (i.e. downloadImage: (URL) async throws -> Data).

¿Cómo funciona `Task.yield()` y por qué su comportamiento varía dependiendo del ejecutor?

Task.yield() cede el funcionamiento a otra tarea que esté esperando. Si la tarea en cuestión tiene la prioridad más alta, entonces vuelve a tomar el control.

Si el executor está ocupado con alguna otra prueba, entonces el comportamiento de Task.yield() no va a conmutar entre dos Task como se pretende. Por esta razón, se aísla cierto bloque de código con withMainSerialExecutor.

¿Cuál es la diferencia entre usar `Task.yield()` con y sin el ejecutor serial principal?

Sin el ejecutor serial principal, no se puede garantizar conmutación entre dos tareas.

¿Cómo se integra esta solución con `XCTest` y con Swift Testing respectivamente?

@Suite(.serialized)
@MainActor
final class ImageFetcherSwiftTesting {
  /// By running the test using a main serial executor, we allow ourselves to use `Task.yield()` and read state in between.
  @Test
  func isLoadingWithMainSerialExecutor() async throws {
    try await withMainSerialExecutor {
      let imageFetcher = ImageFetcher(downloadImage: { url in

        /// Yield here to allow the test to continue evaluation. This allows us to check the `isLoading` state.
        await Task.yield()

        /// Return plain `Data()` for this test as we're just interested in the `isLoading` state.
        return Data()
      })

      /// Call into the `fetchImage` method to ensure the `isLoading` state flips to `true` and `false`.
      let task = Task {
        _ = try await imageFetcher.fetchImage(
          imageURL: URL(string: "https://example-image.url")!
        )
      }

      /// Suspends the current test task and allow the above task to start executing up until `downloadImage(...)` is called.
      await Task.yield()

      /// Check the `isLoading` state while we're 'paused' just at `downloadImage`.
      #expect(imageFetcher.isLoading == true)

      /// Await the result of the image fetching.
      try await task.value

      /// Validate that `isLoading` restores to `false`.
      #expect(imageFetcher.isLoading == false)
    }
  }
}

¿Por qué el artículo recomienda usar `.serialized` en suites de Swift Testing?

withMainSerialExecutor sobreescribe el ejecutor global de Swift con el ejecutor serial principal. Por esta razón, cuando se usa, todas las tareas quedarán encoladas en el ejecutor serial principal hasta que el scope del ejecutor termine.

Si se ejecutan las pruebas en paralelo, esto afectará a las pruebas simultáneamente. Por esto se debe serializar la suite de pruebas.

Recordar sin releer

¿Podrías explicar con tus propias palabras cómo el ejecutor serial resuelve la inestabilidad de los tests?

¿Qué advertencias hace el autor sobre el uso de `withMainSerialExecutor`?

Revisión y síntesis

¿En qué escenarios de tu propio proyecto aplicarías esta técnica y en cuáles no sería necesaria?

¿Qué limitaciones tiene este enfoque y cómo las mitigarías?

Bibliografía

Van der Lee, A. (2025). Swift Concurrency Course [Curso en línea]. avanderlee.com.

[SC] Probando código concurrente con SwiftTesting

GoyesDev — Wed, 13 May 2026 12:23:25 +0000

Comprensión durante la lectura

¿Qué diferencias fundamentales existen entre XCTest y Swift Testing?

No se usa el API de XCTest, o sea clases como XCTestCase o XCTAssert.
Swift Testing no soporta el uso de XCTestExpectation.
Se prefiere el uso de struct sobre class.
Se usan macros como @Test, @Suite, #expect.

¿Por qué las `expectations` no funcionan en Swift Testing y cómo se reemplazan?

Swift Testing no soporta el uso de XCTestExpectation porque es una biblioteca diferente.

En su lugar se puede combinar el uso de:

withCheckedContinuation(isolation:function:_:) para poder envolver el llamado de un código asíncrono que no tiene async en la firma
withObservationTracking(_:onChange:) para detectar cambios en alguna propiedad y, ante esto, invocar resume() sobre el CheckedContinuation.

¿Qué rol juegan `withCheckedContinuation` y `confirmation()` al probar código asíncrono?

withCheckedContinuation sirve para poner un await sobre un código asíncrono que no tenía async en su firma. Este código asíncrono debe llamar resume() sobre el CheckedContinuation.

confirmation(_:expectedCount:isolation:sourceLocation:_:) confirma que cierto evento ocurrió durante el llamado de una función. Este método recibe un body con async en su firma, cuenta cuántas veces se invocó el Confirmation mientras estuvo esperando el body (i.e. await body(confirmation)).

En la práctica este último método sirve para ver si efectivamente hubo la modificación que se esperaba. En el artículo se usó en conjunto con withObservationTracking(_:onChange:) para detectar si hubo un cambio en articleSearcher.searchResults.

¿Cómo se reemplazan `setUp` y `tearDown` en Swift Testing?

setUp y tearDown se reemplazan con init y deinit (para este último se requiere usar class en lugar de struct).

¿Por qué no se puede llamar código `async` dentro de `deinit` y cómo se soluciona?

Se supone que deinit se llama porque ya se va a liberar el objeto de memoria - No se puede retrasar más esta operación, así que no se puede retener self ni ningún atributo de la prueba.

Para solucionarlo se requiere llamar el código async que se quiere que vaya en el deinit, directamente dentro del método de prueba.

Una solución alternativa consiste en definir un TestScoping, que es un protocolo que le dice al test runner que ejecute un código personalizado antes o después de que ejecuta la suite o función de pruebas. Lo anterior quiere decir que se usa en conjunto con SuiteTrait y/o TestTrait.

Particularmente, si lo que se requiere es manipular el "sut" entonces se lo puede inyectar en una variable estática marcada con el macro TaskLocal para poder usarla desde el contexto de un Task.

Por ejemplo:

struct Environment {
  @TaskLocal static var articleSearcher = ArticleSearcher()
}

struct ArticleSearcherDatabaseTrait: SuiteTrait, TestTrait, TestScoping {
  @MainActor
  func provideScope(
    for test: Test,
    testCase: Test.Case?,
    performing function: () async throws -> Void
  ) async throws {
    print("Running for test \(test.name)")

    let articleSearcher = ArticleSearcher()
    try await ArticleSearcherSwiftTesting.Environment.$articleSearcher
      .withValue(articleSearcher) {
        await articleSearcher.prepareDatabase()
        try await function()
        await articleSearcher.closeDatabase()
      }
  }
}

@Test(ArticleSearcherDatabaseTrait())
func testEmptyQuery() async {
  await Environment.articleSearcher.search("")
  #expect(
    Environment.articleSearcher.searchResults
      == ArticleSearcher.articleTitlesDatabase
  )
}

¿Qué hace exactamente el macro `@Test` y en qué se diferencia de `XCTestCase`?

Marca una función como prueba para ser ejecutada por el runner de pruebas.

¿Cuándo conviene usar `withCheckedContinuation` versus `confirmation()`?

El primero es para convertir código asíncrono que recibe closures, en async/await. El segundo es para validar si un evento ocurre durante el llamado de una función async.

¿Qué protocolos implementa `ArticleSearcherDatabaseTrait` y para qué sirve cada uno?

Implementa SuiteTrait y TestTrait. El primero sirve para agregar código antes y después de la ejecución de todos los métodos de la suite de pruebas, y el segundo solo cubre a una sola función de pruebas.

¿Qué hace `@TaskLocal` y por qué es importante en el contexto de los "Test Scoping Traits"?

@TaskLocal permite acceder a una propiedad dentro de una jerarquía de tareas. O sea que, sin importar el nivel de profundidad dentro de esta jerarquía, siempre que no se haya usado un Task.detached, se puede acceder a ese TaskLocal.

Recordar sin releer

¿Puedes explicar con tus propias palabras cómo funciona el flujo completo de un "Test Scoping Trait"?

¿Cuál es la diferencia práctica entre aplicar un `trait` a un `@Test` individual versus a un `@Suite`?

¿Por qué es obligatorio usar `await` dentro del closure de `confirmation()`?

Revisión y síntesis

¿Qué ventajas concretas aporta Swift Testing sobre XCTest para código concurrente?

¿En qué escenarios usarías Test Scoping Traits en lugar de simplemente usar init/deinit?

¿Qué limitaciones tiene aún Swift Testing según el artículo?

Bibliografía

Van der Lee, A. (2025). Swift Concurrency Course [Curso en línea]. avanderlee.com.

[SC] Probando código concurrente con XCTest

GoyesDev — Wed, 13 May 2026 11:15:10 +0000

Comprensión durante la lectura

¿Por qué es difícil escribir tests para código asíncrono?

Si las pruebas para código asíncrono no están bien hechas, puede ser que funcionen por coincidencia, dando la falsa idea de que el código es seguro.

¿Qué son los "flaky tests" y cómo se pueden evitar?

Un "flaky test" es una prueba que funciona algunas veces, y otras no.

¿Qué desafíos introduce `@MainActor` al momento de hacer tests?

Si una clase o método de producción está aislado en MainActor, la prueba (o clase de prueba) puede hacer await para hacer el cambio de dominio de aislamiento, o también puede ser marcada con @MainActor. No obstante, esto último implicaría que las pruebas (o clase de prueba) marcadas con @MainActor se ejecutan de forma serial.

Ante esta problemática, se recomienda extraer el comportamiento en otra clase que no esté marcada con @MainActor.

¿Cómo se puede esperar a que una tarea asíncrona complete dentro de un test?

Un método async puede esperarse con await directamente, y poniendo async en la firma de la prueba.

¿Por qué no se puede usar `wait(for:)` en contextos de concurrencia?

Los métodos normales para esperar por un XCTExpectation no están diseñados para trabajar en un ambiente concurrente. Por esta razón, se debe usar en su lugar fulfillment(of:timeout:enforceOrder:).

¿Qué es el "System Under Test" (SUT)?

"SUT" es una convención de nombre para referirse a la clase que va a ser probada.

¿Por qué falla el test con `searchWithSearchTask` aunque el código se vea correcto?

Internamente tiene un try await Task.sleep(for: .milliseconds(500)). Como inicialmente se construyó la prueba como si fuera síncrona, esto no daba tiempo al código de producción para ejecutar el sleep y terminar adecuadamente.

Recordar sin releer

¿Cómo se usa `withObservationTracking` para resolver el problema de esperar resultados?

Se crea un XCTExpectation. Por ejemplo: let expectation = self.expectation(description: "\"Search complete\")"
Se monitorean cambios en una variable de una clase marcada con @Observable, o que sea @Published, con el bloque withObservationTracking(_:onChange:). El objetivo es que, ante cualquier cambio de la variable de interés, se haga fulfill() sobre el XCTestExpectation.
Se espera al fulfill() del XCTExpectation con fulfillment(of:timeout:enforceOrder:).
Se hacen las validaciones que sean necesarias con XCTAssert.

¿Cómo se declaran `setUp` y `tearDown` para soportar código asíncrono?

Revisión y síntesis

¿Cuáles son las tres técnicas clave aprendidas para testear código concurrente?

¿En qué situaciones usarías `@MainActor` en un test y cuál es su costo?

¿Qué diferencia hay entre este enfoque y el que ofrece el framework Swift Testing mencionado al final?

Bibliografía

Van der Lee, A. (2025). Swift Concurrency Course [Curso en línea]. avanderlee.com.

[SC] sync vs async vs paralelo

GoyesDev — Tue, 12 May 2026 23:13:32 +0000

Comprensión durante la lectura

¿Cuál es el espectro de ejecución propuesto por el autor y en qué orden recomienda transitarlo?

Síncrono
Asíncrono
Paralelo.

Empezar desde el nivel más bajo y solo avanzar cuando se pruebe que es necesario. Esto evita optimización prematura y mantiene la complejidad baja.

¿Qué criterios determinan que un método es candidato a ejecutarse de forma asíncrona o en paralelo?

Solo si cumple alguna de las siguientes condiciones, se puede pensar en usar código asíncrono (ni siquiera estamos hablando de ejecución en segundo plano).

No toca la UI.
Almacena datos de forma persistente.
Transforma o procesa conjuntos de datos grandes.
Se comunica a través de internet.

¿Por qué el autor recomienda empezar siempre con un método sincrónico, incluso cuando la tarea parece pesada?

La mayoría de dispositivos de hoy en día tienen una gran capacidad de cómputo y el código corre muy rápidamente. Saltar a un dominio de aislamiento de segundo plano puede ralentizar el código más de lo que puede optimizarlo.

¿Cómo define el autor el concepto de "carga cognitiva" y por qué lo relaciona con la concurrencia?

Cada capa de concurrencia añade:

Más puntos de suspensión.
Más estados para entender.
Más oportunidades para bugs por cancelación.

Por estas razones, si el código se mantiene síncrono, entonces se evita esta carga cognitiva.

¿Qué lista de verificación propone el autor antes de decidir usar ejecución asíncrona o paralela?

¿Este código bloquea el MainActor lo suficiente para que sea visible?
¿Este trabajo escala con los datos del usuario? (N items -> N costo)
¿El trabajo involucra I/O?
¿El trabajo se beneficia de combinar varias operaciones independientes?
¿Esta lógica se llama con frecuencia?

Si se cumplen 2 o más condiciones, entonces se justifica usar async o paralelismo.

¿Qué costos asocia el autor con la ejecución paralela y cómo afectan a los dispositivos Apple?

Puede haber un aumento en CPU y memoria.
Se pueden saturar los recursos del sistema.
Posible mayor consumo de batería.

¿Cómo justifica el autor que la experiencia de usuario (UX) puede motivar el uso del segundo plano incluso cuando el rendimiento no lo exige?

A veces interrumpir la UI por un frame va a hacer sentir al usuario que la aplicación es lenta. En este caso, vale la pena ejecutar en segundo plano incluso aunque el tiempo total aumente ligeramente.

Recordar sin releer

Sin mirar el artículo, ¿cuáles son las tres fases de concurrencia y qué representa cada una?

¿Cuántas condiciones de la lista de verificación deben cumplirse para justificar el uso de async/paralelo?

¿Qué pregunta clave se hace el autor a sí mismo al considerar si el paralelismo vale la pena?

Explica con tus propias palabras por qué incluso una operación de 80 ms puede justificar ejecutarse en segundo plano.

Revisión y síntesis

¿En qué situaciones concretas de tu propio código aplicarías el espectro sincrónico → asíncrono → paralelo?

¿Estás de acuerdo con la recomendación de empezar siempre con código sincrónico? ¿Qué argumentos a favor o en contra puedes formular?

¿Cómo se relaciona el concepto de "optimización prematura" mencionado aquí con principios generales de ingeniería de software que ya conoces?

¿Qué limitaciones o contextos en los que el enfoque del autor podría no ser aplicable puedes identificar?

Bibliografía

Van der Lee, A. (2025). Swift Concurrency Course [Curso en línea]. avanderlee.com.

DEV Community: GoyesDev

[SC] Migrando a Notificaciones seguras (en términos de concurrencia)

Comprensión durante la lectura

¿Por qué las notificaciones estándar de NotificationCenter no son thread-safe en Swift Concurrency?

¿Qué problema concreto resuelve MainActorMessage frente al API anterior?

¿Cuál es la diferencia clave entre MainActorMessage y AsyncMessage?

¿Qué ventajas concretas aporta migrar a notificaciones con tipo fuerte (strongly typed)?

¿Qué cambio de comportamiento en threading puede ocurrir al migrar al nuevo API?

Bibliografía

[SC] Migrando desde programación reactiva (RxSwift y Combine)

Comprensión durante la lectura

¿Por qué la comunidad Swift está migrando de RxSwift y Combine?

¿Existe alguna alternativa nativa en Swift 6 para la observación reactiva de valores?

¿Cómo se implementa el debouncing sin Combine?

¿Cómo funciona el reemplazo de un pipeline de debounce usando Task.sleep y cancelación manual?

Problema con el NotificationCenter

¿Por qué los closures de sink no ofrecen seguridad en tiempo de compilación con actores?

Recordar sin releer

¿Cuál es el riesgo de threading cuando se usa sink junto con actores de Swift Concurrency?

¿Por qué receive(on:) no es suficiente para resolver problemas de aislamiento de actores?

¿Cuándo tiene sentido quedarse con Combine en lugar de migrar?

Revisión y síntesis

¿Cuáles son las dos soluciones propuestas para manejar NotificationCenter con actores?

¿Qué ventaja concreta ofrece reescribir código en Swift Concurrency respecto a la seguridad en tiempo de compilación?

En tu opinión, ¿los argumentos del autor son suficientes para justificar una migración completa en un proyecto grande?

Bibliografía

[SC] ¿Cuándo y cómo usar @preconcurrency ?

Comprensión durante la lectura

¿Qué es el atributo @preconcurrency y para qué sirve?

¿En qué se diferencia @preconcurrency de @unchecked Sendable?

¿Qué riesgos conlleva suprimir las advertencias de concurrencia con este atributo?

¿Qué sucede con las importaciones @preconcurrency al migrar a Swift 6?

Recordar sin releer

¿Puedes explicar con tus propias palabras cuándo tiene sentido usar @preconcurrency y cuándo no?

¿Qué pasos debería seguir un equipo que usa @preconcurrency para no olvidarse de ese código en el futuro?

Revisión y síntesis

¿Cuál es la alternativa preferible a usar @preconcurrency según el artículo, y por qué?

¿Qué estrategia recomienda el autor para gestionar las importaciones marcadas con @preconcurrency a largo plazo?

Bibliografía

[SC] Técnicas para reescribir closures en código async/await

Comprensión durante la lectura

¿Qué problema resuelve migrar de closures a async/await, y por qué se describe el problema anterior como "Closure-hell"?

¿Cuáles son las tres opciones de refactorización que ofrece Xcode y en qué se diferencian entre sí?

¿Por qué el artículo recomienda usar primero un async wrapper en lugar de reescribir directamente la lógica central?

¿Qué dos reglas críticas hay que respetar al usar withCheckedThrowingContinuation?

¿Por qué las herramientas de refactorización automática de Xcode no siempre producen el resultado óptimo?

Al leer el código de ImageFetcher, ¿qué rol cumple el bloque do-catch dentro del closure de URLSession?

¿Cómo cambia la implementación final de ImageFetcherMigrated respecto a las versiones intermedias generadas por Xcode?

Recordar sin releer

¿puedes describir los pasos del proceso de migración recomendado, en orden?

¿Qué ventajas concretas tiene la versión final con async/await respecto a la versión con closures?

Revisión y síntesis

¿Qué limitaciones actuales tienen las herramientas de Xcode para esta tarea, y qué mejora se menciona para el futuro?

¿Cómo se relaciona este proceso de migración con la estrategia general de mantener la estabilidad del código existente?

Bibliografía

[SC] Herramienta de migración para "Upcoming features"

Comprensión durante la lectura

¿Por qué es importante migrar un proyecto a las upcoming features de Swift 6?

¿Qué limitaciones tiene la herramienta de migración automática mencionada en el artículo?

¿qué hace exactamente el valor Migrate en los Build Settings de Xcode?

¿En qué condición se actualiza el archivo Package.swift al ejecutar el comando de migración?

Recordar sin releer

¿cuál es el comando exacto para migrar únicamente un target específico de un paquete Swift?

¿Cuántos fix-its aplicó automáticamente el comando en el ejemplo del artículo y en cuántos archivos?

¿Qué propuesta de Swift (SE-XXX) introdujo la característica ExistentialAny usada como ejemplo?

Revisión y síntesis

¿Qué requisito deben cumplir las propuestas futuras de Swift para incluir soporte de migración, según el artículo?

En tu opinión, ¿qué ventaja práctica ofrece la migración por terminal frente a la de Xcode para proyectos de gran escala?

¿Qué tema aborda la lección siguiente mencionada al final del artículo, y cómo se relaciona con la migración a concurrencia?

Bibliografía

[SC] El BuildSetting "Approachable Concurrency"

Revisión de las propuestas:

Disable Outward Actor Isolation Inference

Usability of global-actor-isolated types

Problema 1: Propiedades var en structs aislados

Problema 2: Closures aislados y @Sendable

Problema 3: Subclases aisladas de superclases no-Sendable

Global-actor isolated conformances

Inferring Sendable for methods and key path literals

Problema 1: Referencias a métodos y @Sendable

¿Por qué las notificaciones estándar de `NotificationCenter` no son thread-safe en Swift Concurrency?

¿Qué problema concreto resuelve `MainActorMessage` frente al API anterior?

¿Cuál es la diferencia clave entre `MainActorMessage` y `AsyncMessage`?

¿Cómo funciona el reemplazo de un pipeline de `debounce` usando `Task.sleep` y cancelación manual?

Problema con el `NotificationCenter`

¿Por qué los closures de `sink` no ofrecen seguridad en tiempo de compilación con actores?

¿Cuál es el riesgo de threading cuando se usa `sink` junto con actores de Swift Concurrency?

¿Por qué `receive(on:)` no es suficiente para resolver problemas de aislamiento de actores?

¿Cuáles son las dos soluciones propuestas para manejar `NotificationCenter` con actores?

¿Qué es el atributo `@preconcurrency` y para qué sirve?

¿En qué se diferencia `@preconcurrency` de `@unchecked Sendable`?

¿Qué sucede con las importaciones `@preconcurrency` al migrar a Swift 6?

¿Puedes explicar con tus propias palabras cuándo tiene sentido usar `@preconcurrency` y cuándo no?

¿Qué pasos debería seguir un equipo que usa `@preconcurrency` para no olvidarse de ese código en el futuro?

¿Cuál es la alternativa preferible a usar `@preconcurrency` según el artículo, y por qué?

¿Qué estrategia recomienda el autor para gestionar las importaciones marcadas con `@preconcurrency` a largo plazo?

¿Qué problema resuelve migrar de closures a `async/await`, y por qué se describe el problema anterior como "Closure-hell"?

¿Por qué el artículo recomienda usar primero un `async wrapper` en lugar de reescribir directamente la lógica central?

¿Qué dos reglas críticas hay que respetar al usar `withCheckedThrowingContinuation`?

Al leer el código de `ImageFetcher`, ¿qué rol cumple el bloque `do`-`catch` dentro del closure de `URLSession`?

¿Cómo cambia la implementación final de `ImageFetcherMigrated` respecto a las versiones intermedias generadas por Xcode?

¿Qué ventajas concretas tiene la versión final con `async`/`await` respecto a la versión con closures?

¿Qué propuesta de Swift (SE-XXX) introdujo la característica `ExistentialAny` usada como ejemplo?

Problema 1: Propiedades `var` en `structs` aislados

Inferring `Sendable` for methods and key path literals

Problema 1: Referencias a métodos y `@Sendable`

1. Marcar con `nonisolated` el método de `Equatable` (i.e. `nonisolated static func ==`).

2. Conformar un protocolo solo en un actor global (i.e. `extension PersonViewModel: @MainActor Equatable`).

`for await` no puede tener `return` en su interior.

¿Vale la pena usar `@MainActor` por defecto?

¿Qué diferencia hay entre los niveles `Minimal`, `Targeted` y `Complete` de `strict concurrency checking`?

¿En qué situación tendría sentido quedarse en un paso intermedio como agregar alternativas `async` en lugar de migrar por completo?

¿Por qué es útil conformar `Sendable` en los tipos de datos de un paquete?

¿Qué relación existe entre el `swift-tools-version` y el modo de lenguaje Swift 6?

¿Cómo explicarías con tus propias palabras la diferencia entre `.swiftLanguageMode(.v5)` y cambiar el `swift-tools-version` a 6.0?

¿Qué hace exactamente el atributo `@available(*, deprecated, renamed:)` y por qué se prefiere sobre la versión sin `deprecated`?

¿De qué manera el concepto de `Default Actor Isolation` en Swift 6.2 cambia la estrategia de migración respecto a versiones anteriores?

¿Qué relación existe entre `Approachable Concurrency` y los "upcoming features" mencionados al final?

¿Qué significa hacer los tipos "`Sendable` por defecto" y por qué es relevante para equipos de trabajo?

¿Cuál es el riesgo de abusar del atributo `@MainActor` y en qué casos sí tiene sentido usarlo ampliamente?

¿Qué es `withMainSerialExecutor` y cuál es su propósito dentro de los tests?

¿Cómo funciona `Task.yield()` y por qué su comportamiento varía dependiendo del ejecutor?

¿Cuál es la diferencia entre usar `Task.yield()` con y sin el ejecutor serial principal?

¿Cómo se integra esta solución con `XCTest` y con Swift Testing respectivamente?

¿Por qué el artículo recomienda usar `.serialized` en suites de Swift Testing?

¿Qué advertencias hace el autor sobre el uso de `withMainSerialExecutor`?

¿Por qué las `expectations` no funcionan en Swift Testing y cómo se reemplazan?

¿Qué rol juegan `withCheckedContinuation` y `confirmation()` al probar código asíncrono?

¿Cómo se reemplazan `setUp` y `tearDown` en Swift Testing?

¿Por qué no se puede llamar código `async` dentro de `deinit` y cómo se soluciona?

¿Qué hace exactamente el macro `@Test` y en qué se diferencia de `XCTestCase`?

¿Cuándo conviene usar `withCheckedContinuation` versus `confirmation()`?