Forem: GoyesDev

[SC] Swift Concurrency y CoreData

GoyesDev — Thu, 07 May 2026 00:07:53 +0000

Comprensión durante la lectura

El autor sugiere seguir las mejores prácticas con CoreData. Para ello, pone un repositorio a disposición y una serie de artículos.

¿Por qué Core Data requiere acceso seguro a hilos (`thread-safety`)?

No se puede pasar un NSManagedObject de un hilo a otro.

¿Qué problema existe al pasar un `managed object` de un hilo a otro?

Un NSManagedObject estéa ligado al NSManagedObjectContext en el que fue creatdo y ese contexto solo es seguro usarlo desde el hilo en que fue creado. Si paso el objeto a otro hilo y acceso a sus propiedades puede ocurrir:

Corrupción de datos silenciosa.
Fallas impredecibles en tiempo de ejecución.
Condiciones de carrera.

La solución tradicional es pasar solo el NSManagedObjectID entre hilos y refetch del objeto en el contexto del hilo destino.

¿Por qué el autor habla de Core Data en lugar de SwiftData?

SwiftData está teniendo más soporte de Apple. CoreData parece un poco más "huérfano" y, además, es posible que haya muchos más proyectos usando esta biblioteca y gente teniendo problemas con ellos, que con SwiftData.

¿Qué limitaciones tiene Core Data al integrarse con Swift Concurrency?

NSManagedObject no es Sendable, lo que impide pasarlo entre actores o tareas concurrentes sin advertencias del compilador.
NSManagedObjectContext no es un actor, así que no garantiza automáticamente acceso serializado.
Métodos fundamentales como loadPersistentStores no tienen equivalente async/await nativo.
En modo estricto de concurrencia, muchas operaciones comunes de Core Data generan errores de compilación.

¿Qué API asíncrona ofrece `NSManagedObjectContext` para trabajar con `async`/`await`?

perform(schedule:_:)

¿Qué método de `NSPersistentContainer` no tiene una alternativa asíncrona todavía?

loadPersistentStores(completionHandler:)

¿Qué es el "persistent history tracking" y por qué se recomienda antes de migrar a Swift Concurrency?

El "persistent history tracking" es una funcionalidad de Core Data que registra todos los cambios realizados en el almacenamiento persistente en forma de transacciones (NSPersistentHistoryTransaction). Esto permite que distintos contextos, extensiones de app o procesos se enteren de cambios ocurridos mientras no estaban activos.

Se recomienda adaptarlo antes de migrar a Swift Concurrency porque:

Establece una base sólida para sincronizar cambios entre múltiples contextos.
Evita problemas de datos desactualizados cuando diferentes actores o tareas modifican el store simultáneamente.

Recordar sin releer

¿Puedes explicar con tus propias palabras por qué Core Data y Swift Concurrency no son totalmente compatibles aún?

¿Qué soluciones propone el autor para los casos en que Core Data no ofrece APIs asíncronas nativas?

¿Cuál es la postura del autor respecto al futuro de SwiftData en el curso?

Revisión y síntesis

¿Cuáles son las dos tecnologías principales que se integran en este módulo y cuál es el reto central entre ellas?

¿Qué recursos externos menciona el autor para profundizar o reportar problemas?

¿Qué conclusión puedes sacar sobre el estado actual de la adopción de Swift Concurrency en proyectos que usan Core Data?

Bibliografía

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

[SC] Evitar ciclos de retención al usar Task

GoyesDev — Wed, 06 May 2026 23:39:21 +0000

Comprensión durante la lectura

¿Qué es exactamente un "retain cycle" y por qué impide la desasignación de un objeto?

Un ciclo de retención aparece cuando dos objetos tienen referencias fuertes entre ellos. ARC elimina los objetos cuando el contador de cada uno llega a cero, sin embargo, debido que los dos objetos se referencian entre sí, ARC no es capaz de eliminarlos y se produce una fuga de memoria.

¿En qué situaciones concretas puede surgir un "retain cycle" al usar `Task`?

Aparece un ciclo de retención cuando un objeto retiene al Task y este, a su vez, retiene al objeto directa o indirectamente (a través de una referencia hacia alguna de sus propiedades).

Por otro lado, aunque no es un ciclo de retención estrictamente hablando, cuando el Task tiene una referencia fuerte a un objeto y lo retiene hasta que termina de ejecutar, también puede resultar un comportamiento inesperado.

El problema es especialmente delicado cuando el Task se ejecuta por un tiempo prolongado, como cuando se usa AsyncSequence para monitorear un evento a lo largo del tiempo. En este caso no se puede liberar al objeto retenido por el Task mientras que esté monitoreando, para lo cual se requiere detener manualmente esta actividad para poder liberar la referencia.

¿Cuál es la diferencia entre un "retain cycle" y una "one-way retention"?

En un ciclo de retención, hay dos objetos que tienen referencias fuertes entre sí.

En un "one-way retention", el objeto NO retiene al Task, pero el Task SÍ retiene al objeto y no deja que se libere hasta que haya terminado su trabajo.

¿Cómo y cuándo se puede romper un "retain cycle" manualmente?

El ciclo de retención puede romperse cuando se usa un [weak self] para no crearlo inicialmente, y cuando se cancela explícitamente el Task antes de liberar el objeto.

Aquí es importante no depender del deinit para la cancelación porque, precisamente, si hay un ciclo de retención, nunca se va a llamar el deinit.

¿Qué limitaciones existen en Swift 6.2 respecto a `deinit` y los actores?

Antes de Swift 6.2, los deinit eran nonisolated y no podían llamar métodos aislados. Ahora, desde Swift 6.2, se pueden modificar el deinit con isolated. Esto permite a un actor ejecutar métodos desde el deinit. Sin embargo, no soluciona el problema del ciclo de retención - Como hay un ciclo de retención, nunca se va a llamar el deinit.

Recordar sin releer

Cierra el artículo y explica con tus propias palabras qué es un retain cycle y cuándo ocurre con `Task`.

Escribe de memoria las dos versiones del método de "polling" (`startPollingWithRetainCycle` y sin él) y señala la diferencia clave.

Enumera las tres estrategias mencionadas para prevenir o romper "retain cycles" (captura débil, cancelación explícita, `isolated deinit`).

Revisión y síntesis

Revisa tus respuestas de la etapa Q y verifica si el artículo las respondió todas; anota dudas pendientes.

Escribe un mini-ejemplo propio (diferente al del artículo) donde un `Task` podría causar un "retain cycle" y cómo lo corregirias.

Bibliografía

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

[SC] Manejo de Memoria en Swift Concurrency

GoyesDev — Wed, 06 May 2026 17:53:46 +0000

Comprensión durante la lectura

¿Qué es Swift Concurrency y por qué es relevante para el manejo de memoria?

Swift Concurrency es un modelo de concurrencia de Swift que se basa en Tasks para ejecutar trabajo de forma asíncrona.

Es relevante para el manejo de memoria porque las Tasks puede retener instancias y provocar comportamientos inesperados debido a su efecto retardado.

¿De qué manera capturan variables las `Task` en Swift Concurrency, y en qué se parecen a los `closures` normales?

Un Task puede retener una referencia de forma fuerte tanto de forma implícita como explícita (con el "capture list").

¿Por qué la concurrencia puede ocultar o agravar problemas de memoria en comparación con código síncrono?

Una Task podría estar reteniendo un objeto que, en cierto momento se asume que ya fue liberado. Sin embargo, debido a su naturaleza asíncrona, el efecto de haber retenido dicho objeto puede aparecer más tarde, y esto puede ser difícil de rastrear.

¿Qué sucede con un objeto cuando una `Task` captura `self` de forma fuerte (strong reference) y el objeto se establece en `nil` antes de que la tarea termine?

El objeto se libera después de que la Task termina.

¿Cuál es la diferencia en el comportamiento del ciclo de vida del objeto cuando se usa `[weak self]` dentro de una `Task`?

Al usar [weak self], ARC puede liberar self durante la suspensión del Task. Cuando la tarea reanuda después de await, self puede ser nil por lo que las llamadas posteriores a self no se ejecutan.

¿Qué significa que los actores (`actors`) gestionan su memoria de forma independiente y serializan el acceso a sus propiedades?

Los actores sincronizan el acceso a su memoria a través de un executor. De este modo, todo cliente que quiera modificar una propiedad tendrá que hacerlo a través de un método accesor async, y se puede leer directamente accediendo con await a la propiedad.

Según el artículo, ¿en qué orden aparecen los mensajes impresos cuando `fetchData()` captura `self` fuertemente y el `viewModel` se pone en `nil`? ¿Por qué ocurre ese orden?

@MainActor
final class ContentViewModel {
  deinit {
    print("Deinit!")
  }

  func fetchData() {
    Task {
      await performNetworkRequest()
      updateUI() // ⚠️ Captures self strongly!
    }
  }

  func updateUI() {
    print("Update UI!")
  }

  func performNetworkRequest() async {
    print("Perform network request")
    try? await Task.sleep(for: .seconds(1))
    print("Finished network request")
  }
}

var viewModel: ContentViewModel? = .init()
viewModel?.fetchData()
viewModel = nil
print("Set viewModel to nil")

Imprime:

// Perform network request
// Set viewModel to nil
// Finished network request
// Update UI!
// Deinit!

El deinit se llama al final, incluso aunque se puso viewModel = nil porque la Task retuvo el objeto.

¿Qué ocurre con `performNetworkRequest()` cuando se usa `[weak self]` y el objeto se libera a mitad de la ejecución?

La petición simulada termina después de que se libera el objeto en cuestión. Luego, cuando el flujo de control regresa al Task, las instrucciones siguientes no se ejecutan porque self es nil.

Recordar sin releer

Sin mirar el artículo, ¿puedes explicar con tus propias palabras por qué una `Task` puede mantener vivo un objeto más tiempo del esperado?

¿Cuáles son las dos formas de capturar `self` dentro de una `Task` que muestra el artículo, y cuál es la consecuencia de cada una?

Revisión y síntesis

¿Cuál es la conclusión principal del artículo sobre el manejo de memoria en Swift Concurrency respecto al código normal?

¿Qué impacto práctico puede tener una retención prolongada de objetos en el rendimiento de una aplicación?

¿Qué temas o ejemplos adicionales anticipa el artículo que se cubrirán en la siguiente lección?

Bibliografía

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

[SC] Control del dominio de aislamiento por defecto en Swift 6.2

GoyesDev — Wed, 06 May 2026 17:44:43 +0000

Comprensión durante la lectura

¿Qué significa exactamente "dominio de aislamiento por defecto" y por qué importa en Swift Concurrency?

Los tipos de datos (funciones y propiedades globales) en Swift 6.2 viven en algún tipo de aislamiento, bien sea nonisolated o un actor específico.

Como la mayoría de aplicaciones comienzan en el hilo principal y solo cambian de hilo si se introduce concurrencia explícitamente (lo que implica que la mayoría de tipos de datos vivirían en el mismo dominio de aislamiento MainActor), hay una funcionalidad opcional en Xcode 26 que permite marcar todos los tipos de datos dentro de un dominio de aislamiento por defecto. Este dominio de aislamiento puede ser MainActor (anteriormente era nonisolated por defecto).

Esta funcionalidad es importante porque, antes de que existiera, aparecía un montón de advertencias en todos los tipos de datos debido a que se asumía que todas eran nonisolated, pese a que de alguna manera estaban relacionadas con tipos de datos de MainActor. Silenciar una advertencia por un lado, podía levantar otra por otro lado.

¿Por qué tantos desarrolladores terminaban añadiendo `@MainActor` en todas partes?

La aplicación de iOS podía iniciar en @MainActor y no cambiar de hilo, sino hasta ejecutar alguna tarea específica.

El compilador no podía asumir que todas las clases no marcadas con @MainActor vivían dentro del dominio de MainActor, incluso aunque el desarrollador supiera que así ocurría, y que no había ningún riesgo de introducir una carrera de datos. Por esta razón, el desarrollador tenía que marcar todas las clases con @MainActor. Ahora, todas traen @MainActor implícito y, en caso de no querer este dominio de aislamiento, se tiene que cambiar manualmente.

¿Qué diferencia hay entre `nonisolated` y `@MainActor` como dominio por defecto?

nonisolated por defecto, indica que el código no está aislado en ningún dominio de aislamiento específico, por lo que el compilador no puede asegurar la ausencia de carreras de datos. ATENCIÓN: Esto no significa que HABRÁ una carrera de datos - Puede no haberla. Solo quiere decir que no se puede asegurar que no la haya.

@MainActor por defecto, indica que todo el código está aislado en MainActor, a no ser que se indique lo contrario. Esto asegura que no haya carreras de datos entre los llamados.

¿Cómo se configura el dominio de aislamiento por defecto en un proyecto Xcode y en un paquete Swift?

En un proyecto de Xcode hay que cambiar "default actor isolation".

En el caso del paquete de Swift, se puede aplicar el setting SwiftSetting.defaultIsolation(_:_:), teniendo en cuenta que puede recibir como aislamiento MainActor.self o nil.

Tomar como referencia el siguiente código para configurar un paquete de Swift:

import PackageDescription

let package = Package(
  name: "MyPackage",
  targets: [
    .target(
      name: "MyTarget",
      swiftSettings: [
        .define("ENABLE_FEATURE_A"),
        .define("DEBUG_MODE", .when(configuration: .debug)),
        .enableUpcomingFeature("ExistentialAny")
      ]
    ),
    .testTarget(
      name: "MyTargetTests",
      dependencies: ["MyTarget"]
    ),
  ]
)

¿Por qué tiene sentido que la mayoría del código de una app corra en el hilo principal por defecto?

La mayoría de código de una app inicia en el hilo principal y permanece allí hasta que explícitamente se introduce concurrencia. En este escenario, si todo corre secuencial, no hay carreras de datos, así que asumir que el código está en nonisolated provoca falsas alarmas. En lugar de eso, es mejor asumir por defecto que el código corre en el hilo principal.

Según el ejemplo de código del artículo, ¿qué ocurre con la inferencia de aislamiento en `class`, `struct`s y `actor` cuando se usa `@MainActor` como valor por defecto?

Al usar @MainActor como valor por defecto, class y struct (junto con atributos y métodos), vivirán enMainActor. Al crear unactor, sus métodosinitydeinitseránnonisolated` y el resto estarán aislados dentro del dominio de aislamiento definido por él mismo.

En el caso de que class y struct conformen un protocolo, estos heredarán el dominio de aislamiento definido para el protocolo.

Recordar sin releer

¿Este cambio rompe proyectos existentes? ¿Por qué sí o por qué no?

No rompe proyectos existentes el cambio es opcional. Si no se aplica, entonces el código asume por defecto nonisolated.

¿El ajuste se aplica globalmente a todo el proyecto o hay que configurarlo módulo por módulo?

Hay que configurarlo por módulo.

Revisión y síntesis

¿Cuál es el impacto práctico de cambiar el dominio de aislamiento en la migración a Swift 6?

¿Qué riesgos menciona el equipo de Swift respecto a tener dialectos de lenguaje distintos según el módulo?

Bibliografía

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

[SC] nonisolated(nonsending) y @concurrent

GoyesDev — Tue, 28 Apr 2026 22:10:03 +0000

Preguntas

¿Cuál es la diferencia entre el comportamiento anterior y el nuevo de las funciones `nonisolated async` a partir de Swift 6.2?

Antes de Swift 6.2, las funciones nonisolated async se ejecutaban de forma independiente, sin heredar el contexto de ejecución. Esto significa que cada función nonisolated async es una sub-tarea que decide por sí misma dónde ejecutarse. Si se anota con @MainActor o algún @globalActor, entonces se va a ejecutar en el executor de dicho actor. En caso contrario, se va a ir a un hilo de segundo plano.

A partir de Swift 6.2 las funciones nonisolated async corren, por defecto, en al actor invocador.

Para rechazar la herencia de dominio de aislamiento, se debe marcar el método específicamente con el atributo @concurrent.

¿Bajo qué circunstancias una tarea (`Task`) puede ejecutarse en el hilo principal en lugar de en un hilo en segundo plano?

Una Task se puede ejecutar en el hilo principal si está marcada con @MainActor, o si fue invocada por una tarea marcada con @MainActor en Swift 6.2.

¿Para qué sirve el atributo `@concurrent` y cuándo se debe usar?

@concurrent sirve para que un método nonisolated async NO herede el contexto del método invocador.

¿Qué problema resuelve `nonisolated(nonsending)` y cuándo es apropiado aplicarlo?

En caso de que la propiedad NonisolatedNonsendingByDefault esté puesta en NO, puede aparecer un error como Sending value of non-Sendable type ‘MyType’ risks causing data races.

Este error aparece porque Swift asume que, sin nonisolated(nonsending), la función va a correr en un dominio de aislamiento diferente al del llamador. Cuando eso pasa, Swift necesita enviar el valor (selfu otros parámetros) de un dominio a otro - y si el tipo no esSendable`, el compilador dice: "Peligro, datarace!".

nonisolated(nonsending) le dice al compilador: "Esta función va a heredar el dominio de aislamiento del llamador, así que no hay ningún envío entre dominios".

Si no hay envío, no hay riesgo de data race.

nonisolated(nonsending) no es una solución mágica universal. Funciona solo cuando de verdad estoy de acuerdo con que la función bloquee el actor del llamador.

Si la función hace algo pesado, usar nonisolated(nonsending) podría bloquear el hilo en cuestión. En ese caso, la solución correcta sería hacer el tipo Sendable.

¿Cómo se puede verificar en qué hilo se está ejecutando una tarea durante el desarrollo?

Usar Thread.current. Teniendo en cuenta que posiblemente sea necesario usar la extensión:

swift extension Thread { public static var currentThread: Thread { return Thread.current } }

Por otro lado, siempre se puede poner un punto de quiebre para mirar en qué hilo se está parado.

¿cómo explica el autor que el actor de llamada puede influir en el hilo donde se ejecuta una tarea?

El actor del llamador determina dónde empieza la tarea y a dónde regresa después de cada punto de suspensión.

En el ejemplo del artículo:

`swift
@MainActor
private func updateUI() {
Task {
print("Starting on the main thread")
await someBackgroundTask()
print("Resuming on the main thread")
}
}

private func someBackgroundTask() async {
print("Background task on thread: 8")
}
`

someBackgroundTask() corre en el hilo 8. No obstante, la primera línea del Task de updateUI() corre en el hilo 1, y después de la suspensión de await someBackgroundTask()`, el trabajo regresa al hilo 1.

¿Qué cambio introduce SE-461 y cuál es la justificación filosófica que da el autor al citarlo?

SE-461: Run nonisolated async functions on the caller’s actor by default hace que las funciones nonisolated async hereden el contexto del método invocador. En caso de no querer que esto pase, entonces hay que marcar con el atributo @concurrent.

El comportamiento anterior de las funciones nonisolated async sacrificaba usabilidad innecesariamente para proteger la responsividad del hilo principal.

Recitación

¿puedes explicar con tus palabras qué ocurre cuando una función nonisolated es llamada desde un contexto `@MainActor` en Swift 6.2 con el nuevo flag activado?

¿Cuándo elegirías `@concurrent` y cuándo `nonisolated(nonsending)`? ¿Puedes describir un caso de uso para cada uno?

¿Cómo habilitarías el nuevo comportamiento de `NonisolatedNonsendingByDefault` en un proyecto de Xcode?

Revisión

¿Cómo se relacionan los conceptos de actor isolation, `@MainActor` y el pool cooperativo de hilos de Swift?

¿Por qué el autor advierte que este cambio puede confundir a quienes ya conocían Swift Concurrency antes de la versión 6.2?

¿Qué implicaciones de rendimiento puede tener el nuevo comportamiento por defecto si no se usa `@concurrent` donde corresponde?

¿En qué se diferencia el error de compilación "Sending value of non-Sendable type" del problema que resuelve `nonisolated(nonsending)`?

Bibliografía

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

[SC] Puntos de suspensión de una Task

GoyesDev — Tue, 28 Apr 2026 16:33:05 +0000

Preguntas

¿Qué es exactamente un punto de suspensión en una tarea de Swift?

Un punto de suspensión es un momento donde una Task puede pausar su ejecución para permitir que otro trabajo pueda ejecutarse.

Cada uso de await es un punto de suspensión potencial.

¿Por qué no todo `await` garantiza una suspensión real?

Si la tarea esperada (await) puede ser completada de forma síncrona, la tarea de origen no se suspende sino que seguirá ejecutando inmediatamente. Esto puede ocurrir cuando el método asíncrono pertenece al mismo dominio de aislamiento. await simplemente marca un posible punto de suspensión, no uno garantizado.

¿Qué es la reentrada de actores y cuándo ocurre?

Un actor garantiza que solo una Task puede acceder a su estado aislado a la vez. Sin embargo, si una tarea encuentra un punto de suspensión dentro del actor, existe la posibilidad de que otra tarea empiece a trabajar con el actor antes de que la primera termine.

¿Qué riesgos concretos introduce un punto de suspensión dentro de un actor?

Todo estado mutable que asume una ejecución ininterrumpida podría comportarse de forma incorrecta si la tarea es suspendida. Esto puede derivar en un estado inconsistente porque podría solaparse con otra tarea que podría mutar el estado del actor antes de que la primera termine.

¿Cómo se puede evitar el comportamiento inesperado por reentrada?

Evitar modificar el estado mutable de un actor después de un punto de suspensión.
Guardar información importante para el desarrollo del método en variables locales.

¿Qué cambia exactamente en la versión corregida del método `deposit`?

El punto de suspensión aparece después de modificar el estado del actor. Todas las modificaciones al estado del actor se agrupan antes del await.

// Antes
func deposit(amount: Int) async {
  balance += amount
  print("[\(balance)] Deposited \(amount), balance is now \(balance)")

  await logTransaction(amount) // ⚠️ Suspension point

  balance += 10 // bonus after logging
  print("[\(balance)] Applied bonus, balance is now \(balance)")
}

// Después
func deposit(amount: Int) async {
  balance += amount
  print("[\(balance)] Deposited \(amount), balance is now \(balance)")

  balance += 10 // bonus after logging
  print("[\(balance)] Applied bonus, balance is now \(balance)")
  await logTransaction(amount) // ⚠️ Suspension point
}

Recitación / comprensión

Explica con tus propias palabras por qué el balance pasa de 100 → 200 en lugar de 100 → 110.

¿Cuál es la diferencia entre un punto de suspensión posible y uno garantizado?

¿Por qué mover el `await` al final del método soluciona el problema de reentrada?

Revisión y síntesis

¿Cuál es la regla práctica más importante para mutar el estado de un actor de forma segura?

¿En qué situaciones de tu propio código deberías revisar dónde caen los puntos de suspensión?

¿Qué tema cubre la siguiente lección y cómo se relaciona con lo aprendido aquí?

Bibliografía

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

[SC] Deshacerse de la mentalidad de hilos

GoyesDev — Tue, 28 Apr 2026 15:36:04 +0000

Preguntas

¿Por qué Swift Concurrency quiere que dejes de controlar manualmente los hilos?

Controlar manualmente los hilos trae los siguientes costos:

Costo elevado en memoria (stack de cada thread)
Intercambio de contextos innecesariamente alto (más trabajo para los procesadores)
problemas de inversión de prioridad.

Debido a los problemas anteriores, Swift Concurrency nos invita a dejar que el framework se encargue del manejo de hilos.

¿Qué es un dominio de aislamiento y cómo reemplaza el concepto de hilo?

Un dominio de aislamiento es una región o contexto al que pertenece un fragmento de código. Este contexto determina cómo ejecutar el código de forma segura y sin carreras de datos.

El cambio de paradigma consiste en que ahora se declara a qué dominio pertenece el código y Swift se encarga de ejecutarlo de forma segura, en el hilo que considere más eficiente.

¿Qué papel juegan los actores (`actors`) en Swift Concurrency?

Todo el código definido dentro un actor pertenece a su dominio de aislamiento y es ejecutado por un executor independiente, lo que garantiza que el código se ejecute de forma serial dentro del actor, evitando acceso concurrentes a su estado interno.

¿Cómo se le dan "pistas" al sistema sobre la prioridad de una tarea?

La "prioridad" de una tarea no establece directamente el orden de ejecución del código, sino que sugiere al runtime el nivel de importancia que tiene el bloque a ejecutar.

Sin embargo, puede darse el caso que tenga una tarea de prioridad alta que esté esperando a que una tarea de prioridad baja termine. Por esto se dice que la "prioridad" de una tarea es más bien una sugerencia.

¿Por qué una tarea de alta prioridad no garantiza ejecución inmediata?

La prioridad de una "tarea" es una sugerencia para el runtime. No se está asignando la tarea a un hilo, sino que se está indicando la naturaleza del trabajo a realizar.

¿Qué problema resuelve la conformancia con `Sendable`?

Un dato Sendable es seguro para cruzar dominios de aislamiento. Como Swift puede mover código entre hilos y no se puede predecir en cuál reanudará, es necesario garantizar que los datos compartidos entre dominios son seguros de transferir.

Según el artículo, ¿cuáles son los tres problemas que evita dejar que Swift gestione los hilos?

Uso excesivo de memoria (para guardar el contexto)
Uso elevado de procesador (para cambiar de contexto)
Inversión de prioridad

En el ejemplo de código, ¿por qué la "`Task` 1" aparece ejecutándose en hilos distintos al inicio y al reanudarse?

La creación de una Task no garantiza la ejecución en un hilo específico. En el ejemplo, ante la aparición del punto de suspensión, la Task 1 cambió de hilo.

Recitación

Con tus propias palabras, ¿qué significa pensar en dominios de aislamiento en lugar de hilos?

Explica por qué Sendable se vuelve necesario precisamente porque Swift puede mover trabajo entre hilos.

Revisión

¿Qué cambio mental fundamental propone el artículo respecto a cómo escribir código concurrente en Swift?

¿Cómo conectan entre sí los conceptos de actores, prioridades y Sendable dentro del modelo de Swift Concurrency?

Bibliografía

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

[SC] Relación entre Hilos y Tasks

GoyesDev — Tue, 28 Apr 2026 11:47:54 +0000

Preguntas

¿Qué es exactamente un hilo y por qué tiene un alto costo de creación y cambio de contexto?

Un hilo es un recurso, manejado por el sistema operativo, que ejecuta una secuencia de instrucciones. Crear hilos y cambiar el contexto entre ellos es una operación muy costosa.

Cada hilo requiere su propia pila de memoria (stack) y el cambio de contexto obliga al CPU a guardar y restaurar el estado completo del hilo (registros, puntero de instrucción, etc).

¿Por qué Swift Concurrency no garantiza en qué hilo se ejecutará una función asíncrona?

Swift Concurrency dispone de un pool global concurrente de hilos (tantos como el número de procesadores del dispositivo).

Para optimizar el uso de hilos, se despacha una Task en cualquier hilo disponible. Cuando hay un punto de suspensión (await), el runtime de Swift Concurrency cede el hilo a cualquier otra tarea. Luego, cuando la Task recupera el contexto, el runtime de SC le asigna cualquier hilo disponible - que puede ser el que tenía inicialmente, pero no está garantizado, porque el sistema pudo haberlo asignado a otra Task.

Aquí quien limita los hilos no es el sistema operativo sino el framework Swift Concurrency. El sistema operativo podría crear muchos más hilos (como lo hacía GCD). Es una decisión de diseño del framework, no una restricción del sistema operativo.

¿Qué ocurre exactamente cuando una tarea llega a un punto de suspensión con `await`?

El sistema suspende la Task y devuelve el hilo al pool global de hilos - Lo que significa que está disponible para que cualquier otra Task lo tome.

¿Cómo funciona el `cooperative thread pool` y por qué limita los hilos al número de núcleos de CPU?

Para no tener "thread explosion" y así degradar el desempeño de la aplicación debido al cambio de contexto entre hilos y posibles problemas de inversión de prioridades, el sistema operativo limita la creación de hilos al número de núcleos del procesador.

El "cooperative thread pool" son todos los hilos disponibles para ser usados por las distintas Tasks.

¿Qué es el `thread explosion` y cómo lo evita Swift Concurrency?

"thread explosion" ocurre porque se crean demasiados hilos y aparecen bloqueos que provocan:

Desperdicio de memoria debido a los hilos detenidos.
Intercambio excesivo de contexto (que reduce la eficiencia del procesador)
Problemas de inversión de prioridad.

¿Por qué tener menos hilos no reduce el rendimiento comparado con GCD?

Aunque es contraintuitivo, el intercambio innecesario de contexto y el desperdicio de memoria son problemas que se reducen al tener menos hilos.

¿Qué demuestra el ejemplo de código con `ThreadingDemonstrator` sobre la relación entre tareas e hilos?

private struct ThreadingDemonstrator {
  private func firstTask() async throws {
    print("Task 1 started on thread: \(Thread.currentThread)")
    try await Task.sleep(for: .seconds(2))
    print("Task 1 resumed on thread: \(Thread.currentThread)")
  }

  private func secondTask() async {
    print("Task 2 started on thread: \(Thread.currentThread)")
  }

  func demonstrate() {
    Task {
      try await firstTask()
    }
    Task {
      await secondTask()
    }
  }
}

struct ThreadingDemonstratorTests {
  @Test
  func execute() async throws {
    let sut = ThreadingDemonstrator()
    sut.demonstrate()

    try await Task.sleep(for: .seconds(3))
  }
}

No se puede garantizar el orden de ejecución de las tareas firstTask y secondTask. Para hacerlo hay que usar await.
Cuando se asigna un hilo a una tarea y esta se suspende, no se puede garantizar que lo recupere una vez se reanude.

¿Por qué la tarea 1 puede reanudarse en un hilo diferente al que inició?

Cuando se suspende la tarea 1, cede ("yield") el hilo que tenía y el sistema operativo es libre de asignárselo a cualquier otra tarea.

¿Qué diferencia introduce el modo Swift 6 respecto a acceder a `Thread.current` y cómo se resuelve?

Usar Thread.current desde un contexto asíncrono arrojará el error de compilación: Class property 'current' is unavailable from asynchronous contexts; Thread.current cannot be used from async contexts..

La solución fue envolver el llamado de Thread.current en un método (variable computada) nonisolated static:

extension Thread {
  public nonisolated static var currentThread: Thread {
    return Thread.current
  }
}

Recitación

Explica con tus propias palabras qué significa "ceder el hilo" (yielding the thread) cuando se usa await.

¿Cuáles son los tres conceptos erróneos sobre Swift Concurrency que menciona el artículo? ¿Puedes refutarlos?

¿Qué tres consecuencias negativas produce el thread explosion en GCD?

¿Cómo describirías el cooperative thread pool a alguien sin experiencia en concurrencia?

Revisión

¿En qué situaciones concretas deberías seguir pensando en si algo corre en el hilo principal o en un hilo en segundo plano?

Si Swift Concurrency ya gestiona los hilos automáticamente, ¿qué valor tiene entender cómo funcionan internamente?

¿Cómo cambiaría tu forma de escribir código asíncrono ahora que sabes que `await` no bloquea el hilo?

¿Qué preguntas te quedan sin responder sobre el `@MainActor` y cómo encaja con lo aprendido aquí?

Bibliografía

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

[SC] ¿Cuándo usar AsyncStream en lugar de AsyncSequence?

GoyesDev — Tue, 28 Apr 2026 10:59:43 +0000

Preguntas

¿Cuándo debería usar `AsyncSequence` en lugar de `AsyncStream`, y viceversa?

AsyncSequence es la abstracción a la que debería acoplarme, mientras que AsyncStream es una implementación concreta de AsyncSequence que puedo utilizar para emitir eventos.

¿Qué ventajas ofrece `AsyncStream` para casos de uso comunes?

Se puede usar directamente esta implementación concreta, definiendo el closure que recibe un continuation.

El API de AsyncStream es fácil de recordar y escribir, y especialmente útil para crear puentes entre delegados, llamados a closures y emisión manual de eventos.

¿Cómo se relacionan `AsyncSequence` y `AsyncStream` entre sí?

AsyncStream conforma AsyncSequence.

¿Qué ejemplo concreto usa el artículo para ilustrar el puente de delegates con `AsyncThrowingStream`?

En el artículo se creó un LocationMonitor que funciona como delegado (CLLocationManagerDelegate) de un CLLocationManager. Este LocationMonitor tenía un atributo llamado stream de tipo AsyncThrowingStream<CLLocation, Error>, manejado con un continuation de tipo AsyncThrowingStream<CLLocation, Error>.Continuation?.

Cada vez que el LocationMonitor recibía un evento como delegado de LocationMonitor, emitía un evento al stream a través del continuation con yield(_:), y finish(throwing:).

¿Cómo funciona el método `AsyncStream.init(unfolding:oncancel:)` en el ejemplo del servicio de `ping`?

AsyncStream.init(unfolding:onCancel:) recibe un closure asíncrono que produce elementos (unfolding) y otro opcional que se maneja la cancelación (oncancel).

¿Por qué el artículo compara `AsyncSequence` con el protocolo `Sequence` en Swift?

AsyncSequence es la versión asíncrona de Sequence. Además, el artículo menciona que muy pocas veces implementamos el protocolo Sequence, sino que son mayormente otros tipos de datos del SDK de iOS que lo conforman - Básicamente nosotros como desarrolladores tendríamos la misma relación con AsyncSequence.

Recitación / comprensión

Sin releer, ¿puedes explicar con tus palabras cuándo elegirías `AsyncStream` sobre `AsyncSequence`?

¿Qué hace la `continuation` en el ejemplo de `LocationMonitor` y por qué es clave?

¿Qué APIs estándar de Apple mencionadas en el artículo conforman `AsyncSequence`?

Repaso final

¿Cuál es la conclusión principal del artículo sobre cuál opción usar en la mayoría de proyectos reales?

¿Qué limitación menciona el artículo sobre el ejemplo de `LocationMonitor`?

¿En qué escenarios reales, mencionados explícitamente, tiene más sentido usar `AsyncStream`?

Bibliografía

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

[SC] AsyncStream y AsyncThrowingStream

GoyesDev — Tue, 28 Apr 2026 01:33:44 +0000

Preguntas

¿Qué es un `AsyncStream` y en qué se diferencia de un `AsyncThrowingStream`?

Un AsyncStream es un AsyncSequence que puede emitir eventos de progreso y fin con base en un AsyncStream.Continuation.

Es muy parecido a un Publisher de Combine, con la diferencia que solo admite un suscriptor.

AsyncThrowingStream es la versión que arroja error de AsyncStream.

¿Por qué podría querer reemplazar un closure de progreso/completación con un `AsyncThrowingStream`?

Facilita la integración del API de async/await en lugar de una integración basada en closures. Además, AsyncStream permite poder iterar con for try await en lugar de anidar closures, lo que hace el flujo más lineal y legible.

¿Qué sucede si no se llama a `continuation.finish()` al terminar un `stream`?

La implementación se va a quedar colgada sin terminar. El código que itera el stream con for try await nunca avanza más allá del loop porque el stream nunca emite el evento de terminación.

¿Qué son las `buffer policies` y cuándo tendría sentido usar cada una?

Las "buffer policies" define qué hacer con los valores emitidos cuando no hay ningún consjmidor leyendo aún. Es decir: regulan el buffer previo a la lecutra, no a la entrega en tiempo real. En el artículo se mencionan:

AsyncStream.Continuation.BufferingPolicy.unbounded: El suscriptor recibe todos los eventos pasados emitidos por el AsyncStream antes de la suscripción.
AsyncStream.Continuation.BufferingPolicy.bufferingOldest(_:): El suscriptor recibe los primeros (oldest) n eventos emitidos por el AsyncStream.
AsyncStream.Continuation.BufferingPolicy.bufferingNewest(_:): El suscriptor recibe los últimos (newest) n eventos emitidos por el AsyncStream. En el artículo ponen de ejemplo que al usar bufferingnewest(0), se ignoran todos los eventos pasados emitidos por el AsyncStream.

¿En qué se diferencia un `AsyncStream` de un `publisher` de `Combine`?

El Publisher de Combine puede tener varios suscriptores. El AsyncStream solo puede tener uno.

¿Cómo se usa el `continuation` para enviar valores, manejar errores y terminar el `stream`?

Sobre el continuation se pueden usar los siguientes métodos:

yield(with:): Para emitir un elemento de tipo Result<Element,Never> en unAsyncStream`.
yield(with:): Para emitir un elemento de tipo Result<Element,Failure> en un AsyncThrowingStream`.
finish(): Para cerrar el Stream sin emitir error.
finish(throwing:): Para cerrar el Stream emitiendo un error
onTermination: Suscribe un closure para ejecutar algún trabajo cuando termina el stream. Este sirve para hacer labores de limpieza o depuración.

¿Qué hace el `callback onTermination` y para qué casos de uso es útil?

Suscribe un closure para ejecutar algún trabajo cuando termina el stream. Este sirve para hacer labores de limpieza o depuración.

¿Cómo y cuándo se cancela un stream, y qué efecto tiene la cancelación?

Un Stream se cancela cuando el contexto asíncrono que lo envuelve es cancelado (e.g. Task.cancel()).

El stream se termina (no en error, ni en success), sino que se invoca onTermination con la causa (i.e. "termination reason: cancelled")

No hay forma de cancelar el stream explícitamente, solo de forma indirectamente a través del Task que lo envuelve.

¿Por qué no es seguro tener múltiples consumidores de un mismo `AsyncStream`?

Como solo puede tener un suscriptor, no se sabe a cuál le va a entregar el valor. Los valroes se reparten entre los consumidores en lugar de duplicarse - Cada valor lo recibe uno solo, de forma impredecible.

Recordar sin mirar el texto

Explica con tus propias palabras el ciclo de vida de un `AsyncThrowingStream`, desde su creación hasta su terminación.

¿Cuáles son las tres razones posibles por las que un stream puede terminar y cómo se reporta cada una?

Sin mirar el código, describe cómo transformarías el `FileDownloader` basado en closures a uno basado en `AsyncThrowingStream`.

Revisión y conexión de ideas

¿En qué escenarios concretos de tu propio código usarías un `AsyncStream` en lugar de `Combine` o callbacks?

¿Cuál es la limitación más importante de `AsyncStream` mencionada en el artículo y cómo se puede mitigar?

¿Qué errores de programación comunes advierte el artículo y qué estrategias propone para detectarlos?

Bibliografía

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

[SC] Trabajando con secuencias asíncronas

GoyesDev — Mon, 27 Apr 2026 23:31:04 +0000

Preguntas

¿Qué es un `AsyncSequence` y en qué se diferencia de un `Sequence` normal?

AsyncSequence es un tipo de dato que provee acceso secuencial e iterativo a una colección de forma asíncrona.

AsyncSequence es un hermano de Sequence que prácticamente puede hacer todo lo que hace Sequence (como contains(_:), map(_:)) con la diferencia que los datos se recorren de forma asíncrona.

¿Qué rol cumplen `AsyncIterator` y el método `next()` dentro de una secuencia asíncrona?

Un tipo de dato que conforme el protocolo AsyncSequence debe definir el método makeAsyncIterator() que devuelve una instancia que conforme el protocolo AsyncIteratorProtocol.

Un AsyncIterator es como un IteratorProtocol con la diferencia que debe recorrer una colección asíncrona a través del método next() async que puede tener puntos de suspensión y, retorna el siguiente valor de la colección o nil si ya terminó el trabajo.

¿Cómo se indica el fin de la iteración en un `AsyncSequence` personalizado?

Se indica el fin de una iteración devolviendo nil. Esto puede ocurrir por dos razones:

se alcanzó el límite configurado
la tarea fue cancelada (Task.isCancelled).

¿Por qué se recomienda usar `AsyncStream` en lugar de implementar `AsyncSequence` directamente?

AsyncStream es más conveniente de configurar que AsyncSequence, porque al usar este último se debe un AsyncIterator y manejar su estado.

¿Qué operadores de `Sequence` están disponibles también para secuencias asíncronas?

Métodos como:

contains(where:) - Tener cuidado que métodos como este esperan a que la secuencia asíncrona termine de emitir elementos y se puede quedar esperando indefinidamente.
map(_:)
filter(_:)

Identifica cómo el protocolo `AsyncSequence` define el acceso a valores sin generarlos por sí mismo.

AsyncSequence se encarga de la construcción del AsyncIteratorProtocol, quien técnicamente es el encargado de generar los elementos en el método next() async.

Analiza cómo la cancelación con `Task.isCancelled` interactúa con el ciclo de vida de la secuencia.

Entro del contexto de next() async es de vital importancia verificar que la tarea no haya sido cancelada con Task.isCancelled (sin esta verificación, la secuencia seguiría emitiendo valores a pesar de que la tarea hubiera sido cancelada). Si lo fue, entonces retornar nil.

Recitación

Explica con tus palabras qué hace el método `next()` en el ejemplo `Counter`.

¿Cómo se usa `for await` para iterar sobre un `AsyncSequence` y por qué es necesario el `await`?

Menciona al menos dos operadores que se pueden aplicar sobre una secuencia asíncrona y describe su efecto.

¿Qué ocurre si una secuencia asíncrona nunca termina y usas un método como `contains`?

Revisión

¿En qué situaciones reales tiene sentido usar un `AsyncSequence` en lugar de un `array` estático?

¿Por qué el artículo dice que un `AsyncSequence` "prepara para valores asíncronos" aunque no siempre los envíe de forma asíncrona?

¿Qué relación existe entre los task groups vistos en lecciones anteriores y el concepto de `AsyncSequence`?

Después de leer este módulo, ¿qué preguntas tienes sobre `AsyncStream`, el siguiente tema?

Bibliografía

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

[SC] Usando un Mutex como alternativa a los actores

GoyesDev — Mon, 27 Apr 2026 21:29:37 +0000

Preguntas

¿Qué es un `Mutex` y en qué se diferencia de un `Lock`?

Un Mutex es un tipo de Lock del framework Synchronization usado para sincronizar accesos a una variable a través del método withLock(_:).

El método withLock es equivalente a hacer:

mutex.lock()
defer {
  mutex.unlock()
}
return try body(&value)

Observar que value es un valor inout, que se devuelve el valor generado por try body(&value) y que puede arrojar un error.

La diferencia importante entre Mutex y Lock es que usando Lock, el tipo de dato no es Sendable (tendría que marcarse con @unchecked Sendable). En cambio, Mutex sí es Sendable porque encapsula su valor internamente y controla todo acceso a él.

¿Por qué Apple introdujo un `Mutex` si ya existen los actores en Swift Concurrency?

Mutex es una aproximación bloqueante síncrona que, en ocasiones, puede servir en lugar de un actor asíncrono. Usar el actor asíncrono implica un "overhead" de "scheduling", además de que el invocador debe estar en un contexto síncrono.

El Mutex es útil cuando el trabajo protegido es breve y el bloqueo es más eficiente que suspender y reanudar una tarea.

¿Desde qué versiones de iOS y macOS está disponible el framework `Synchronization`?

iOS 18 y macOS 15.

¿Cómo se usa el método `withLock` y qué tipo de acceso proporciona al valor protegido?

Debido a que el parámetro que recibe withLock es inout, entonces da un acceso por referencia.

withLock se usa pasando un closure que puede modificar el valor protegido y puede retornar algún valor. En el ejemplo del artículo teníamos:

var currentCount: Int {
  count.withLock { currentCount in
    return currentCount
  }
}

func increment() {
  count.withLock { currentCount in
    currentCount += 1
  }
}

¿Cómo permite el `Mutex` trabajar con tipos no-`Sendable` como `NSBezierPath`?

A pesar de que NSBezierPath es no-Sendable, se puede crear un Mutex, constante (let), que envuelva al NSBezierPath y modificar el path protegido.

let path = Mutex<NSBezierPath>(NSBezierPath())

func storeTouch(_ point: NSPoint) {
  path.withLock { path in
    path.move(to: point)
  }
}

¿Qué sucede cuando múltiples hilos intentan adquirir un `Mutex` al mismo tiempo?

Si un hilo trata de tomar el Mutex y este ya fue tomado, entonces el hilo permanece bloqueado hasta que el Mutex sea liberado.

Recapitulación

¿En qué situaciones concretas es preferible usar un `Mutex` en lugar de un actor?

¿Cómo se puede lanzar un error desde dentro del closure `withLock`?

Repaso y reflexión

¿Cuál es la conclusión principal del artículo respecto a la elección entre actores y `Mutex`?

¿Qué ventajas y desventajas tiene cada herramienta según el contexto del proyecto?

Bibliografía

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

Forem: GoyesDev

[SC] Swift Concurrency y CoreData

Comprensión durante la lectura

¿Por qué Core Data requiere acceso seguro a hilos (thread-safety)?

¿Qué problema existe al pasar un managed object de un hilo a otro?

¿Por qué el autor habla de Core Data en lugar de SwiftData?

¿Qué limitaciones tiene Core Data al integrarse con Swift Concurrency?

¿Qué API asíncrona ofrece NSManagedObjectContext para trabajar con async/await?

¿Qué método de NSPersistentContainer no tiene una alternativa asíncrona todavía?

¿Qué es el "persistent history tracking" y por qué se recomienda antes de migrar a Swift Concurrency?

Recordar sin releer

¿Puedes explicar con tus propias palabras por qué Core Data y Swift Concurrency no son totalmente compatibles aún?

¿Qué soluciones propone el autor para los casos en que Core Data no ofrece APIs asíncronas nativas?

¿Cuál es la postura del autor respecto al futuro de SwiftData en el curso?

Revisión y síntesis

¿Cuáles son las dos tecnologías principales que se integran en este módulo y cuál es el reto central entre ellas?

¿Qué recursos externos menciona el autor para profundizar o reportar problemas?

¿Qué conclusión puedes sacar sobre el estado actual de la adopción de Swift Concurrency en proyectos que usan Core Data?

Bibliografía

[SC] Evitar ciclos de retención al usar Task

Comprensión durante la lectura

¿Qué es exactamente un "retain cycle" y por qué impide la desasignación de un objeto?

¿En qué situaciones concretas puede surgir un "retain cycle" al usar Task?

¿Cuál es la diferencia entre un "retain cycle" y una "one-way retention"?

¿Cómo y cuándo se puede romper un "retain cycle" manualmente?

¿Qué limitaciones existen en Swift 6.2 respecto a deinit y los actores?

Recordar sin releer

Cierra el artículo y explica con tus propias palabras qué es un retain cycle y cuándo ocurre con Task.

Escribe de memoria las dos versiones del método de "polling" (startPollingWithRetainCycle y sin él) y señala la diferencia clave.

Enumera las tres estrategias mencionadas para prevenir o romper "retain cycles" (captura débil, cancelación explícita, isolated deinit).

Revisión y síntesis

Revisa tus respuestas de la etapa Q y verifica si el artículo las respondió todas; anota dudas pendientes.

Escribe un mini-ejemplo propio (diferente al del artículo) donde un Task podría causar un "retain cycle" y cómo lo corregirias.

Bibliografía

[SC] Manejo de Memoria en Swift Concurrency

Comprensión durante la lectura

¿Qué es Swift Concurrency y por qué es relevante para el manejo de memoria?

¿De qué manera capturan variables las Task en Swift Concurrency, y en qué se parecen a los closures normales?

¿Por qué la concurrencia puede ocultar o agravar problemas de memoria en comparación con código síncrono?

¿Qué sucede con un objeto cuando una Task captura self de forma fuerte (strong reference) y el objeto se establece en nil antes de que la tarea termine?

¿Cuál es la diferencia en el comportamiento del ciclo de vida del objeto cuando se usa [weak self] dentro de una Task?

¿Qué significa que los actores (actors) gestionan su memoria de forma independiente y serializan el acceso a sus propiedades?

Según el artículo, ¿en qué orden aparecen los mensajes impresos cuando fetchData() captura self fuertemente y el viewModel se pone en nil? ¿Por qué ocurre ese orden?

¿Qué ocurre con performNetworkRequest() cuando se usa [weak self] y el objeto se libera a mitad de la ejecución?

Recordar sin releer

Sin mirar el artículo, ¿puedes explicar con tus propias palabras por qué una Task puede mantener vivo un objeto más tiempo del esperado?

¿Cuáles son las dos formas de capturar self dentro de una Task que muestra el artículo, y cuál es la consecuencia de cada una?

Revisión y síntesis

¿Cuál es la conclusión principal del artículo sobre el manejo de memoria en Swift Concurrency respecto al código normal?

¿Qué impacto práctico puede tener una retención prolongada de objetos en el rendimiento de una aplicación?

¿Qué temas o ejemplos adicionales anticipa el artículo que se cubrirán en la siguiente lección?

Bibliografía

[SC] Control del dominio de aislamiento por defecto en Swift 6.2

Comprensión durante la lectura

¿Qué significa exactamente "dominio de aislamiento por defecto" y por qué importa en Swift Concurrency?

¿Por qué tantos desarrolladores terminaban añadiendo @MainActor en todas partes?

¿Qué diferencia hay entre nonisolated y @MainActor como dominio por defecto?

¿Cómo se configura el dominio de aislamiento por defecto en un proyecto Xcode y en un paquete Swift?

¿Por qué tiene sentido que la mayoría del código de una app corra en el hilo principal por defecto?

Según el ejemplo de código del artículo, ¿qué ocurre con la inferencia de aislamiento en class, structs y actor cuando se usa @MainActor como valor por defecto?

Recordar sin releer

¿Este cambio rompe proyectos existentes? ¿Por qué sí o por qué no?

¿El ajuste se aplica globalmente a todo el proyecto o hay que configurarlo módulo por módulo?

Revisión y síntesis

¿Cuál es el impacto práctico de cambiar el dominio de aislamiento en la migración a Swift 6?

¿Qué riesgos menciona el equipo de Swift respecto a tener dialectos de lenguaje distintos según el módulo?

Bibliografía

[SC] nonisolated(nonsending) y @concurrent

Preguntas

¿Cuál es la diferencia entre el comportamiento anterior y el nuevo de las funciones nonisolated async a partir de Swift 6.2?

¿Bajo qué circunstancias una tarea (Task) puede ejecutarse en el hilo principal en lugar de en un hilo en segundo plano?

¿Para qué sirve el atributo @concurrent y cuándo se debe usar?

¿Qué problema resuelve nonisolated(nonsending) y cuándo es apropiado aplicarlo?

¿Cómo se puede verificar en qué hilo se está ejecutando una tarea durante el desarrollo?

¿cómo explica el autor que el actor de llamada puede influir en el hilo donde se ejecuta una tarea?

¿Qué cambio introduce SE-461 y cuál es la justificación filosófica que da el autor al citarlo?

Recitación

¿puedes explicar con tus palabras qué ocurre cuando una función nonisolated es llamada desde un contexto @MainActor en Swift 6.2 con el nuevo flag activado?

¿Cuándo elegirías @concurrent y cuándo nonisolated(nonsending)? ¿Puedes describir un caso de uso para cada uno?

¿Cómo habilitarías el nuevo comportamiento de NonisolatedNonsendingByDefault en un proyecto de Xcode?

¿Por qué Core Data requiere acceso seguro a hilos (`thread-safety`)?

¿Qué problema existe al pasar un `managed object` de un hilo a otro?

¿Qué API asíncrona ofrece `NSManagedObjectContext` para trabajar con `async`/`await`?

¿Qué método de `NSPersistentContainer` no tiene una alternativa asíncrona todavía?

¿En qué situaciones concretas puede surgir un "retain cycle" al usar `Task`?

¿Qué limitaciones existen en Swift 6.2 respecto a `deinit` y los actores?

Cierra el artículo y explica con tus propias palabras qué es un retain cycle y cuándo ocurre con `Task`.

Escribe de memoria las dos versiones del método de "polling" (`startPollingWithRetainCycle` y sin él) y señala la diferencia clave.

Enumera las tres estrategias mencionadas para prevenir o romper "retain cycles" (captura débil, cancelación explícita, `isolated deinit`).

Escribe un mini-ejemplo propio (diferente al del artículo) donde un `Task` podría causar un "retain cycle" y cómo lo corregirias.

¿De qué manera capturan variables las `Task` en Swift Concurrency, y en qué se parecen a los `closures` normales?

¿Qué sucede con un objeto cuando una `Task` captura `self` de forma fuerte (strong reference) y el objeto se establece en `nil` antes de que la tarea termine?

¿Cuál es la diferencia en el comportamiento del ciclo de vida del objeto cuando se usa `[weak self]` dentro de una `Task`?

¿Qué significa que los actores (`actors`) gestionan su memoria de forma independiente y serializan el acceso a sus propiedades?

Según el artículo, ¿en qué orden aparecen los mensajes impresos cuando `fetchData()` captura `self` fuertemente y el `viewModel` se pone en `nil`? ¿Por qué ocurre ese orden?

¿Qué ocurre con `performNetworkRequest()` cuando se usa `[weak self]` y el objeto se libera a mitad de la ejecución?

Sin mirar el artículo, ¿puedes explicar con tus propias palabras por qué una `Task` puede mantener vivo un objeto más tiempo del esperado?

¿Cuáles son las dos formas de capturar `self` dentro de una `Task` que muestra el artículo, y cuál es la consecuencia de cada una?

¿Por qué tantos desarrolladores terminaban añadiendo `@MainActor` en todas partes?

¿Qué diferencia hay entre `nonisolated` y `@MainActor` como dominio por defecto?

Según el ejemplo de código del artículo, ¿qué ocurre con la inferencia de aislamiento en `class`, `struct`s y `actor` cuando se usa `@MainActor` como valor por defecto?

¿Cuál es la diferencia entre el comportamiento anterior y el nuevo de las funciones `nonisolated async` a partir de Swift 6.2?

¿Bajo qué circunstancias una tarea (`Task`) puede ejecutarse en el hilo principal en lugar de en un hilo en segundo plano?

¿Para qué sirve el atributo `@concurrent` y cuándo se debe usar?

¿Qué problema resuelve `nonisolated(nonsending)` y cuándo es apropiado aplicarlo?

¿puedes explicar con tus palabras qué ocurre cuando una función nonisolated es llamada desde un contexto `@MainActor` en Swift 6.2 con el nuevo flag activado?

¿Cuándo elegirías `@concurrent` y cuándo `nonisolated(nonsending)`? ¿Puedes describir un caso de uso para cada uno?

¿Cómo habilitarías el nuevo comportamiento de `NonisolatedNonsendingByDefault` en un proyecto de Xcode?

¿Cómo se relacionan los conceptos de actor isolation, `@MainActor` y el pool cooperativo de hilos de Swift?

¿Qué implicaciones de rendimiento puede tener el nuevo comportamiento por defecto si no se usa `@concurrent` donde corresponde?

¿En qué se diferencia el error de compilación "Sending value of non-Sendable type" del problema que resuelve `nonisolated(nonsending)`?

¿Por qué no todo `await` garantiza una suspensión real?

¿Qué cambia exactamente en la versión corregida del método `deposit`?

¿Por qué mover el `await` al final del método soluciona el problema de reentrada?

¿Qué papel juegan los actores (`actors`) en Swift Concurrency?

¿Qué problema resuelve la conformancia con `Sendable`?

En el ejemplo de código, ¿por qué la "`Task` 1" aparece ejecutándose en hilos distintos al inicio y al reanudarse?

¿Qué ocurre exactamente cuando una tarea llega a un punto de suspensión con `await`?

¿Cómo funciona el `cooperative thread pool` y por qué limita los hilos al número de núcleos de CPU?

¿Qué es el `thread explosion` y cómo lo evita Swift Concurrency?

¿Qué demuestra el ejemplo de código con `ThreadingDemonstrator` sobre la relación entre tareas e hilos?

¿Qué diferencia introduce el modo Swift 6 respecto a acceder a `Thread.current` y cómo se resuelve?

¿Cómo cambiaría tu forma de escribir código asíncrono ahora que sabes que `await` no bloquea el hilo?

¿Qué preguntas te quedan sin responder sobre el `@MainActor` y cómo encaja con lo aprendido aquí?

¿Cuándo debería usar `AsyncSequence` en lugar de `AsyncStream`, y viceversa?

¿Qué ventajas ofrece `AsyncStream` para casos de uso comunes?

¿Cómo se relacionan `AsyncSequence` y `AsyncStream` entre sí?

¿Qué ejemplo concreto usa el artículo para ilustrar el puente de delegates con `AsyncThrowingStream`?

¿Cómo funciona el método `AsyncStream.init(unfolding:oncancel:)` en el ejemplo del servicio de `ping`?

¿Por qué el artículo compara `AsyncSequence` con el protocolo `Sequence` en Swift?