Jorge Calderita's Blog

Model Parts

2026-07-08T00:00:00Z

Mi Problema 🤔

Cuando escribo migraciones con Fluent, los índices, las claves foráneas y las restricciones únicas se definen dentro del método prepare de la migración. Pertenecen a la migración, no al modelo.

func prepare(on db: Database) async throws {
    try await db.schema("products")
        .id()
        .field(.externalId, .string, .required)
        .field(.categoryId, .uuid, .references("categories", "id", onDelete: .cascade, onUpdate: .cascade))
        .unique(on: .externalId)
        .create()
}

El problema es que esa información no es legible fuera de la migración. Forma parte de un método que se ejecuta una vez y no expone nada al resto del código. Cuando quiero escribir un test de integración que verifique que la migración creó los índices correctos, ¿de dónde saco los nombres esperados? Los tengo que repetir como strings en el test. Y cuando quiero verificar que las claves foráneas existen, lo mismo: strings hardcodeados, acoplados a lo que esté dentro del prepare.

Mi modelo sabe qué tabla representa. Mi modelo sabe qué campos tiene. Pero no sabe nada de su propia estructura de base de datos: índices, referencias, unicidad. Esa información pertenece a la migración, y la única forma de acceder a ella es ejecutándola.

Mi Solución 🧩

Mi idea es convertir el modelo en la única fuente de verdad para toda la metadata estructural de su tabla. Creé un protocolo SchemaDescribable que extiende Model de Fluent con tres propiedades estáticas: índices, claves foráneas y restricciones únicas.

protocol SchemaDescribable: Model {
    static var indexes: [IndexDefinition] { get }
    static var foreignKeys: [ForeignKeyDefinition] { get }
    static var uniques: [UniqueDefinition] { get }
}

Cada tipo de constraint tiene su propio tipo con factory methods que hacen la declaración legible y segura. La conformancia la declaro en la capa de base de datos, no en el modelo compartido:

extension ProductModel: SchemaDescribable {
    static var indexes: [IndexDefinition] {
        [
            .btree("idx_products_sku", [.sku]),
            .btree("idx_products_category_id", [.categoryId]),
            .btree("idx_products_brand_id", [.brandId]),
            .btree("idx_products_supplier_id", [.supplierId]),
            .btree("idx_products_warehouse_id", [.warehouseId]),
            .btree("idx_products_parent_id", [.parentId]),
            .lower("idx_products_name_prefix", .name),
        ]
    }

    static var foreignKeys: [ForeignKeyDefinition] {
        [
            .references(.parentId, on: ProductModel.self),
            .references(.categoryId, on: CategoryModel.self),
            .references(.brandId, on: BrandModel.self),
            .references(.supplierId, on: SupplierModel.self),
            .references(.warehouseId, on: WarehouseModel.self),
        ]
    }

    static var uniques: [UniqueDefinition] { [.on(.externalId)] }
}

Cada modelo declara de forma explícita todos sus índices B-Tree, sus claves foráneas y sus restricciones únicas. Los factory methods como .btree, .lower, .references y .on hacen que la declaración sea compacta y difícil de equivocar.

Con las definiciones en el modelo, la migración se limita a aplicarlas. Un método addConstraints(for:) sobre SchemaBuilder añade las claves foráneas y las restricciones únicas, y createIndexes genera los índices — todo a partir de lo que el modelo declara:

struct CreateProducts: AsyncMigration, MigrationProtocol {
    typealias ModelType = ProductModel
    let target: DeployTarget

    func prepare(on db: Database) async throws {
        try await db.schema(model)
            .id(default: true)
            .field(.externalId, .string, .required)
            .field(.name, .string, .required)
            .field(.sku, .string, .required)
            .field(.price, .double, .required)
            .field(.weight, .double)
            .field(.stock, .int)
            .field(.parentId, .uuid)
            .field(.categoryId, .uuid)
            .field(.brandId, .uuid)
            .field(.supplierId, .uuid)
            .field(.warehouseId, .uuid)
            .timestamps(default: true)
            .addConstraints(for: model)
            .create()

        try await createIndexes(on: db)
    }

    func revert(on db: Database) async throws {
        try await db.schema(model).delete()
    }
}

La migración ya no contiene ninguna definición de constraint. Solo declara los campos y delega toda la estructura de índices, foreign keys y uniques al modelo a través de addConstraints(for:) y createIndexes. El protocolo MigrationProtocol proporciona estos métodos gracias al typealias ModelType, que conecta la migración con su modelo y permite acceder a las definiciones de SchemaDescribable.

Mi Resultado 🎯

Ahora los índices, claves foráneas y restricciones únicas son propiedades del modelo, no código enterrado en una migración. Cualquier parte de mi proyecto puede leerlas.

El beneficio más inmediato son las migraciones limpias. Pero el que me compensa a futuro es que los tests pueden hablar directamente con el modelo — en un próximo artículo veremos cómo aprovecho esto para escribir tests de integración que verifican la estructura de la base de datos sin un solo string hardcodeado.

Un solo sitio donde leer toda la metadata estructural de cada modelo
Migraciones sin repetición — addConstraints(for: model) aplica todo de un paso
Cambios localizados — añadir un índice o FK solo toca la conformancia del modelo

La clave es reconocer que un modelo no es solo un contenedor de campos: es también la descripción completa de su tabla. SchemaDescribable hace explícito lo que antes estaba implícito — y pertenecía solo a la migración.

Keep coding, keep running 🏃‍♂️

AI Status Bar

2026-07-01T00:00:00Z

Mi Problema 🤔

Cuando trabajo con Claude Code en la shell, hay información que necesito consultar constantemente: cuánto contexto llevo consumido, en qué porcentaje estoy de los límites de uso, qué rama de git tengo activa, con qué modelo estoy trabajando. Información que no cambia cada segundo, pero que sí necesito tener a mano para tomar decisiones.

El problema es que obtenerla tiene fricción. Puedo pedírsela a la IA directamente, pero eso implica gastar tokens en una pregunta cuya respuesta es completamente determinista. También puedo abrir otra sesión de terminal, o lanzar un comando en background para consultarlo cada cierto tiempo. Pero todas esas opciones interrumpen el flujo de trabajo.

Lo que en realidad necesitaba era algo más simple: una línea siempre visible que me diera esa información sin que yo tuviera que pedirla, sin consumir contexto, y sin interrumpir lo que estaba haciendo.

Mi Solución 🧩

Claude Code tiene una funcionalidad llamada statusLine que permite definir un comando externo que se ejecuta cuando hay cambios en la sesión: tras cada respuesta del asistente, al terminar un /compact, al cambiar el modo de permisos o al togglear el modo vim. La herramienta llama al script, le pasa información del estado actual de la sesión como JSON por stdin, y muestra lo que el script devuelva por stdout en la barra inferior de la interfaz.

La configuración vive en settings.json y es de una sola línea:

{
  "statusLine": {
    "type": "command",
    "command": "zsh statusline-command.zsh"
  }
}

El JSON que recibe el script por stdin contiene toda la información relevante de la sesión: modelo activo, directorio de trabajo, porcentaje de uso del contexto, tamaño total de la ventana, y límites de uso de los periodos de 5 horas y 7 días, cada uno con su porcentaje y timestamp de reset.

El script se ejecuta en cada uno de esos eventos, con un debounce de 300 ms que agrupa cambios rápidos. Y aquí hay un detalle importante: si llega un nuevo evento mientras el script todavía corre, Claude Code cancela la ejecución en curso y lanza una nueva — un script lento se interrumpiría a sí mismo. Por eso lo escribí buscando que fuera barato: builtins de zsh en lugar de subprocesos, una única llamada a jq en lugar de nueve, y helpers que devuelven el resultado en REPLY para evitar capturarlo con $(…) en el camino caliente.

Lo primero es cargar el módulo de fecha de zsh y extraer los nueve campos del JSON en una sola pasada. La salida de jq es una lista ordenada de valores que voy capturando posicionalmente con read:

#!/bin/zsh

zmodload zsh/datetime

MAGENTA=$'\e[35m'; CYAN=$'\e[36m'; YELLOW=$'\e[33m'; GREEN=$'\e[32m'
BLUE=$'\e[34m';    RED=$'\e[31m';  DIM=$'\e[2m';     RESET=$'\e[0m'

input=$(</dev/stdin)
{
    read -r model_display_name
    read -r current_dir
    read -r used_percentage
    read -r context_window_size
    read -r five_hour_pct
    read -r five_hour_reset
    read -r seven_day_pct
    read -r seven_day_reset
    read -r effort_level
} < <(jq -r '
    .model.display_name // "",
    .workspace.current_dir // "",
    (.context_window.used_percentage // 0),
    (.context_window.context_window_size // 0),
    (.rate_limits.five_hour.used_percentage as $p | if $p then ($p | floor) else "" end),
    (.rate_limits.five_hour.resets_at // ""),
    (.rate_limits.seven_day.used_percentage as $p | if $p then ($p | floor) else "" end),
    (.rate_limits.seven_day.resets_at // ""),
    ((.effortLevel // .effort) as $e | if ($e | type) == "object" then $e.level else ($e // "") end)
' <<<"$input")

Con eso tengo las nueve variables pobladas con un único fork de jq. Si el nivel de esfuerzo no venía en el JSON, lo busco primero en el settings.json del proyecto y, si tampoco está, en el del usuario. Después calculo los derivados y construyo la barra de progreso con el left-padding nativo de zsh:

extract_effort='(.effortLevel // .effort // empty) | if type == "object" then .level else . end // empty'
[[ -z "$effort_level" && -f "$current_dir/.claude/settings.json" ]] && \
    effort_level=$(jq -r "$extract_effort" "$current_dir/.claude/settings.json" 2>/dev/null)
[[ -z "$effort_level" && -f "$HOME/.claude/settings.json" ]] && \
    effort_level=$(jq -r "$extract_effort" "$HOME/.claude/settings.json" 2>/dev/null)

current_tokens=$(( used_percentage * context_window_size / 100 ))
current_k=$(( current_tokens / 1000 ))
max_k=$(( context_window_size / 1000 ))
project_name=${current_dir:t}
git_branch=$(git -C "$current_dir" -c core.fileMode=false rev-parse --abbrev-ref HEAD 2>/dev/null)

bar_width=20
filled=$(( used_percentage * bar_width / 100 ))
empty=$(( bar_width - filled ))
progress_bar="${(l:filled::=:):-}${(l:empty:: :):-}"

Detalles que evitan procesos hijo: ${current_dir:t} es el equivalente nativo de basename, y ${(l:filled::=:):-} construye una cadena rellenada por la izquierda con caracteres = sin bucles ni concatenación.

Luego vienen los umbrales de color. En la primera versión tenía dos funciones casi idénticas, una para porcentajes y otra para tokens absolutos. Las unifiqué en una sola que recibe el valor y los dos umbrales como argumentos, y aproveché para que devolviera el resultado en REPLY en lugar de imprimirlo:

threshold_color() {
    if (( $1 >= $2 )); then REPLY=$RED
    elif (( $1 >= $3 )); then REPLY=$YELLOW
    else REPLY=$GREEN
    fi
}

format_reset() {
    REPLY=
    [[ -z "$1" ]] && return
    if (( $1 - EPOCHSECONDS < 86400 )); then
        strftime -s REPLY '%H:%M' $1
    else
        strftime -s REPLY '%a %H:%M' $1
    fi
}

build_rate_part() {
    local part
    if [[ -n "$2" ]]; then
        threshold_color $2 80 50
        part="${MAGENTA}$1:${RESET} ${REPLY}$2%${RESET}"
    else
        part="${MAGENTA}$1:${RESET} ${DIM}-${RESET}"
    fi
    format_reset $3
    [[ -n "$REPLY" ]] && part+=" ${DIM}($REPLY)${RESET}"
    REPLY=$part
}

Aplicando esos umbrales:

Contexto verde por debajo de 100k tokens — zona segura
Contexto amarillo entre 100k y 150k tokens — señal para considerar un /clear
Contexto rojo por encima de 150k tokens — hay que actuar

Lo mismo para los límites de uso de 5 horas y 7 días: verde por debajo del 50%, amarillo entre 50% y 79%, rojo a partir del 80%.

Las tres funciones devuelven en REPLY: así me ahorro el $(…) y el subshell asociado en cada llamada, lo que reduce el riesgo de que una invocación se cancele a sí misma cuando llegan eventos seguidos. format_reset tira del builtin strftime y de $EPOCHSECONDS del módulo zsh/datetime, así que tampoco arranca un proceso date cada vez.

Finalmente la composición. La primera línea siempre lleva los mismos elementos: modelo, barra de progreso, porcentaje de contexto, tokens actuales sobre el máximo y nombre del proyecto. La segunda se construye solo con las partes que tengan datos — si no hay límite de 5h, no hay nivel de esfuerzo configurado o no hay rama de git, simplemente no aparecen y los separadores se ajustan:

threshold_color $current_tokens 150000 100000
context_color=$REPLY
status_line="${MAGENTA}${model_display_name}${RESET} ${CYAN}[${RESET}${progress_bar}${CYAN}]${RESET}"
status_line+=" ${context_color}${used_percentage}%${RESET} |"
status_line+=" ${context_color}${current_k}k/${max_k}k${RESET} |"
status_line+=" ${BLUE}${project_name}${RESET}"

typeset -a parts
build_rate_part 5h "$five_hour_pct" "$five_hour_reset"; parts+=("$REPLY")
build_rate_part 7d "$seven_day_pct" "$seven_day_reset"; parts+=("$REPLY")
[[ -n "$effort_level" ]] && parts+=("${MAGENTA}effort:${RESET} ${YELLOW}${effort_level}${RESET}")
[[ -n "$git_branch" ]]   && parts+=("${GREEN}${git_branch}${RESET}")

sep=" ${CYAN}|${RESET} "
(( ${#parts} )) && status_line+=$'\n'"${(pj.$sep.)parts}"

print -rn -- "$status_line"

La expansión ${(pj.$sep.)parts} une los elementos del array parts con el separador sep — un join nativo de zsh, sin bucles ni hacks con IFS.

Un detalle importante sobre la hora de reset: el script la formatea como HH:MM si el reset ocurre dentro de las próximas 24 horas, y como Día HH:MM si es más adelante. Así sé de un vistazo cuándo se libera el límite sin tener que hacer cálculos.

Mi Resultado 🎯

El resultado es exactamente lo que buscaba: información siempre presente sin interrumpir nada ni gastar un solo token en obtenerla.

Lo que veo de un vistazo en cualquier momento:

Modelo activo — qué versión de Claude está usando la sesión actual
Barra de contexto — representación visual de cuánto contexto he consumido
Tokens actuales sobre el máximo — por ejemplo, 87k/200k, que me dice exactamente en qué punto estoy de la ventana
Uso 5h y 7d con hora de reset — para saber si me acerco a un límite de tasa y cuándo se libera
Nivel de esfuerzo — confirmación visual de que la sesión tiene el nivel correcto configurado
Rama de git — en qué rama estoy trabajando en el proyecto activo

Lo que más valoro es que esta información no cuesta nada. No es una pregunta a la IA, no es un comando que tengo que recordar lanzar, no es una ventana adicional que abrir. Es texto que aparece, se actualiza solo, y desaparece del foco en cuanto me pongo a trabajar.

El enfoque también encaja bien con lo que exploraba en Back to Shell: la shell como espacio de composición, donde los scripts hacen el trabajo determinista y la IA hace el trabajo contextual. La status bar es el ejemplo más visible de esa separación — toda la lógica de formateo y colores vive en el script, y la IA no sabe que existe.

Si trabajas con Claude Code y tienes información que consultas repetidamente, la statusLine es la forma más eficiente de tenerla siempre a mano. El script puede mostrar lo que necesites: uso de APIs externas, estado de un servicio, variables de entorno, lo que quieras exponer desde un comando de shell.

Keep coding, keep running 🏃‍♂️

Back to Shell

2026-06-24T00:00:00Z

Mi Problema 🤔

Empecé a programar cuando la shell no era una opción, era el sitio. No había ratón, no había ventanas. Solo un cursor parpadeando, esperando un comando. Aprendí a pensar en texto: entrada, salida, pipe, redirección.

Después llegó el giro. La industria decidió que la productividad tenía cara de ventana. Cada disciplina pasó a tener su propio programa, con su interfaz y su curva de aprendizaje:

Bases de datos — su aplicación con su panel y sus pestañas
Control de versiones — otra ventana, otra forma de ver lo mismo
Despliegues — otro dashboard, otra cuenta, otros botones
Observabilidad — otro panel, otros gráficos, otra suscripción

La shell quedó relegada a “eso que usan los que saben mucho” y a las tareas que las interfaces gráficas todavía no habían conquistado.

Yo seguí la corriente. Fui acumulando aplicaciones, dashboards y ventanas hasta que dejé de visitar la shell. La fui desempolvando cada vez con menos frecuencia, hasta que solo aparecía cuando no quedaba más remedio.

El problema llegó al incorporar la IA a mi flujo de trabajo. No como buscador ni como generador de fragmentos, sino como agente que actúa sobre mi entorno. Y ese agente no tiene ratón. No abre ventanas. Trabaja exactamente como yo al principio: con texto, con comandos, con la shell.

La pregunta que me quedó flotando fue incómoda: ¿había pasado años aprendiendo interfaces gráficas para hacer lo mismo que ya hacía al empezar, pero con más pasos por el medio?

Mi Solución 🧩

La solución no fue una ruptura. No cerré ventanas de golpe ni escribí un manifiesto anti-interfaz. Solo dejé de resistirme a volver a la shell cuando el trabajo me llevaba ahí de forma natural.

El cambio empezó observando. Cuando un agente necesita inspeccionar algo, no busca una vista bonita — escribe un comando. Cuando quiere ver logs, los lee con un pipe. No le interesa qué aplicación prefiero yo. Solo le interesa el resultado.

Mi primer instinto fue corregirlo: “Espera, para eso tengo una herramienta gráfica.” Pero al detenerme entendí que estaba metiendo fricción donde no había ninguna. El agente sabía qué ejecutar. Yo sabía leer el output. La interfaz no aportaba nada — solo añadía pasos: abrir, conectar, navegar, encontrar.

Así que empecé a hacer lo mismo por mi cuenta. Donde antes abría una ventana, ahora abro una shell:

Revisar un estado — un comando directo en lugar de un panel que cargar
Transformar datos — encadeno operaciones en lugar de exportar, abrir y volver a guardar
Automatizar una tarea — la escribo una vez y la reutilizo en cualquier sitio
Reproducir un flujo — copio y pego texto en lugar de explicar clics

No por nostalgia, sino porque es más rápido y más composable.

Ese fue el verdadero giro mental: los comandos se componen de un modo que las interfaces gráficas nunca podrán igualar. Una ventana me ofrece lo que su diseñador imaginó que necesitaría. La shell me da lo que yo decido que necesito.

Y hubo algo que me sorprendió: el conocimiento seguía intacto. No había que estudiar otra vez. Solo había que desempolvar.

Mi Resultado 🎯

El resultado no ha sido una ruptura con las interfaces gráficas. Sigo abriendo ventanas cuando aportan algo que el texto no puede ofrecer. Pero la shell ha vuelto a ocupar el centro de gravedad de mi flujo, en lugar de ser el último recurso.

Lo que cambió concretamente:

Velocidad — un comando es casi siempre más rápido que navegar hasta la opción equivalente en una GUI
Composabilidad — puedo encadenar operaciones que ninguna ventana contempla en combinación
Consistencia con la IA — hablamos el mismo idioma; no hay traducción entre lo que el agente ejecuta y lo que yo veo
Portabilidad — un comando funciona igual en local, en un servidor y en CI

Pero lo que más me llamó la atención fue el aprendizaje que no tuve que hacer. Daba por hecho que volver a la shell exigiría tiempo y práctica. Ese tiempo ya estaba invertido décadas atrás: los comandos, los pipes, la lógica de redirección — todo seguía ahí, esperando una excusa para volver a usarse.

La IA no me enseñó a usar la shell. Me recordó que ya sabía hacerlo.

El ciclo que empezó con un triciclo, pasó por el cohete de las interfaces gráficas y vuelve a los fundamentos no es un retroceso. Es un círculo que cierra mejor de lo que abrió. A veces el futuro del desarrollo no consiste en aprender algo nuevo, sino en redescubrir lo que ya sabíamos hacer cuando empezamos.

Keep coding, keep running 🏃‍♂️

WWDC26 Group Labs

2026-06-17T00:00:00Z

Mi Problema 🤔

Cuando publiqué mi guía de videos de la WWDC26, dediqué el Bloque 17 a los Group Labs con apenas una línea de contexto por sesión. La razón era sencilla: las descripciones oficiales de Apple son prácticamente idénticas entre sí —«Únete a nosotros para profundizar en WWDC26 con ingenieros de Apple»— y no dicen nada útil sobre lo que se habló dentro.

Lo que no conté entonces es que, antes de escribir ese bloque, me había puesto a ver los Group Labs y me había llevado una sorpresa. No son sesiones pasivas. Son rondas de Q&A en directo entre desarrolladores reales e ingenieros del equipo de Apple, y la calidad de las preguntas y respuestas es muy distinta a la de las sesiones normales. En las sesiones ordinarias, Apple muestra lo que quiere mostrar. En los Group Labs, los desarrolladores preguntan lo que de verdad necesitan saber, y los ingenieros responden de forma directa.

El problema es que ese contenido es prácticamente invisible. No hay transcripciones, no hay índice, no hay forma de buscar dentro del video. Si no te sientas a ver la sesión entera, no sabes qué cubre.

Me puse a tomar notas. Una sesión, otra, y al final acabé con dieciocho.

Mi Solución 🧩

Decidí transcribir y estructurar el contenido de cada Group Lab: los temas preguntados, el timecode exacto, la respuesta resumida y qué ingenieros participaron. El objetivo era tener algo consultable, que me permitiera ir directamente al minuto que me interesa en lugar de buscar a ciegas en el video.

Antes de la lista, tres ejemplos de lo que apareció dentro y que no encontrarías en ninguna sesión principal:

En el Swift Group Lab, el equipo del lenguaje explicó por qué habrían diseñado la concurrencia de forma diferente si empezaran hoy, y qué fue lo que cambió en Swift 6.2 para corregir el modelo.
En el SwiftUI Group Lab, los ingenieros desmontaron cuándo usar AnyView, cómo funciona DynamicProperty antes que body, y por qué los condicionales dentro de contenedores lazy son un antipatrón.
En el Apple Intelligence Group Lab, el equipo explicó las diferencias reales entre App Schemas e IndexEntity, y los límites actuales del soporte de vídeo en Foundation Models.

Aquí están todas las sesiones disponibles, con enlace directo al video oficial:

Lenguaje y datos

Swift Group Lab — Concurrencia, rendimiento, SwiftPM y características del lenguaje.
SwiftData Group Lab — ResultsObserver, HistoryObserver, el nuevo Codable, CloudKit sync, migraciones y concurrencia.

SwiftUI

SwiftUI Group Lab - Part 1 — Liquid Glass, flujo de datos, rendimiento de layouts y AnyView.
SwiftUI Group Lab - Part 2 — ForEach con colecciones grandes, NavigationTransition, Liquid Glass en botones y layouts adaptativos.
SwiftUI for Beginners Group Lab — SwiftUI vs multiplataforma, @State por dentro y rutas de aprendizaje.

Herramientas y rendimiento

Xcode Tips and Tricks Group Lab — Cómo sacarle el máximo a Xcode 27.
Power and Performance Group Lab — Instrumentación, MetricKit y rendimiento en producción.

Plataformas y web

visionOS Group Lab — Acceso a la cámara, depuración inmersiva, exportación USD y accesorios espaciales.
watchOS Group Lab — Foundation Models en Watch, transición desde iOS y debugging en dispositivo.
Safari and Web Technologies Group Lab — WebKit, CSS Grid Lanes, Web Extensions y más.

Inteligencia, ML y AI

Apple Intelligence Group Lab — Foundation Models, App Schemas, Siri y Evaluations.
Machine Learning & AI Group Lab — Foundation Models, Private Cloud Compute, Core AI, MLX y evaluaciones.
Coding Intelligence for Beginners Group Lab — Slash commands, Xcode frente a agentes externos y contexto entre proyectos.
Coding Intelligence, Machine Learning & AI Group Lab — Core AI vs Core ML vs MLX, ventanas de contexto e inferencia en background.

Calidad y distribución

Accessibility Technologies Group Lab — VoiceOver, Dynamic Type y accesibilidad en controles personalizados.
Privacy and Security Group Lab — App Attest, Trust Insights y diseño seguro de features agénticas.
Camera and Photo Technologies Group Lab — AVFoundation, captura RAW y Center Stage.
App Store Connect Group Lab — In-App Purchase, suscripciones y StoreKit.

Mi Resultado 🎯

El valor de los Group Labs no está en las descripciones oficiales —está dentro. Las preguntas de los desarrolladores sacan a la superficie los casos de uso que Apple no cubre en las sesiones principales: los bugs que el equipo reconoce, las decisiones de diseño que explican en off, los patrones que recomiendan en la práctica y no en el marketing.

Si ya tienes mi guía de videos como mapa del catálogo, los Group Labs son la capa que va encima: donde los ingenieros de Apple hablan de verdad sobre lo que construyeron.

Keep coding, keep running 🏃‍♂️

WWDC26 Videos

2026-06-11T00:00:00Z

Mi Problema 🤔

Cada año el mismo ritual: el lunes después de la Keynote abro los videos de la WWDC26 y me encuentro con más de cien sesiones. Apple ofrece filtros por tema, plataforma y framework que se pueden ir acumulando hasta dejar el catálogo a tu medida — una base estupenda para arrancar.

Lo que me pasa a mí es que, incluso con esos filtros activos, si no me marco un orden propio acabo saltando de video en video según el título que más me llame en ese momento. Veo algo de SwiftUI, luego salto a AI, luego me pongo con herramientas, y al final del día he consumido cinco sesiones inconexas que no se refuerzan entre sí. La comprensión es superficial porque cada bloque temático necesita contexto previo que no tengo.

Llevo tiempo queriéndome armar mi propio esquema sobre lo que Apple ofrece. Un camino con sentido, que construya el conocimiento de manera acumulativa, que ponga primero lo que da contexto para todo lo demás — y que me sirva también como checklist para tachar bloques a medida que avanzo durante el año.

Este año lo he hecho.

Mi Solución 🧩

Mi criterio es simple: primero la visión general, luego el núcleo del lenguaje, después las herramientas, y al final las áreas específicas según lo que más use en mi trabajo. Cada bloque prepara el terreno para el siguiente.

Dejo fuera solo las versiones en ASL y los recaps (Dub Dub Daily, recap del State of the Union). Todo lo demás entra — incluso los Group Labs, que aunque eran sesiones interactivas en directo Apple los mantiene en el catálogo y los dejo localizados al final por si necesitas referencia del tema.

Lo que viene a continuación es la agrupación que uso yo, y que voy tachando bloque a bloque a lo largo del año. Si te sirve, hazla tuya: lo que importa es tener un camino que seguir, no que sea el mío.

Bloque 0 — Las presentaciones

Antes de cualquier sesión técnica, estos videos dan el marco del año. El teaser abre boca; Keynote y State of the Union son los que mandan.

Get ready for WWDC26
El teaser pre-evento de la propia WWDC. Marginal una vez vista la Keynote pero está en el catálogo.

Keynote
El gran anuncio del año. Liquid Glass, Apple Intelligence con la nueva Siri, Xcode 27 con agentes de código. No es técnico — es el por qué de todo lo demás.

Platforms State of the Union
La Keynote para desarrolladores. Aquí ya aparece la capa técnica: qué cambia en las plataformas, qué prioridades tiene Apple este ciclo, y qué va a importar para el trabajo del día a día. Este video es el mapa del territorio.

Bloque 1 — Swift y herramientas

Con el contexto del año claro, entro en el núcleo. Swift primero porque todo lo demás construye sobre el lenguaje.

What’s new in Swift
Actualización del lenguaje: mejoras de ergonomía, concurrencia mejorada, código de alto rendimiento más seguro, Embedded Swift e interoperabilidad con C y Java. El estado del lenguaje en 2026.

What’s new in Xcode 27
Las novedades del entorno: agentes de código, Device Hub, localización, rendimiento y herramientas de testing. Si voy a vivir aquí, necesito saber qué ha cambiado.

Get the most out of Device Hub
Tour profundo de Device Hub: cómo acelera el flujo de desarrollo y cómo diagnosticar y reproducir issues rápido con dispositivos y simuladores. El compañero natural del video anterior.

Xcode, agents, and you
Cómo incorporar los agentes de código de Xcode al flujo de trabajo real. Desde el prototipo inicial hasta pulir una app terminada. La parte práctica de lo que se presentó en el video anterior.

Create UI prototypes using agents in Xcode
Prototipado con agentes: técnicas para iterar sobre layouts, generar soluciones creativas y refinar las ideas hasta una experiencia pulida. La cara creativa de los agentes en Xcode.

Translate your app using agents in Xcode
Cómo los agentes traducen String Catalogs usando el contexto de la app. Estrategias para revisar el output y ajustar las localizaciones. La cara práctica para producto global.

Build, deliver, and automate with Xcode Cloud
Las novedades de Xcode Cloud: arranque simplificado, tests en la nube, webhooks y distribución. Fundamentos para cualquiera que lo use en CI.

Profile, fix, and verify: Improve app responsiveness with Instruments
Un flujo completo para atacar problemas de rendimiento: Swift Concurrency instrument, Time Profiler y System Trace. Encontrar el cuello de botella, medir la mejora, confirmar el fix.

Meet the new MetricKit
MetricKit renovado con métricas de rendimiento vitales y diagnósticos accionables. Cruzar métricas con estado de la app vía StateReporting framework para tener el cuadro completo de optimización.

Migrate to Swift Testing
Adoptar Swift Testing junto a los XCTests existentes usando interoperabilidad entre frameworks. Patrones para introducir las nuevas capacidades de testing de manera incremental. Conecta con lo que cuento en SIGBUS.

Bloque 2 — SwiftUI y persistencia

El stack de UI y datos. Lo veo junto porque en la práctica van de la mano.

What’s new in SwiftUI
Nuevo protocolo Document con acceso directo a disco, APIs de reordenación en listas y grids, mejoras en toolbars, nuevas presentaciones, caché en AsyncImage y lazy state para Observable. El overview de lo nuevo en el framework.

What’s new in SwiftData
Persistencia de tipos externos con Codable, agrupación de resultados en secciones para SwiftUI, ModelResultsObserver e HistoryObserver para observar cambios fuera de la vista. Las novedades del ORM de Apple.

Code-along: Add persistence with SwiftData
Manos al teclado: añadir persistencia a una app existente paso a paso. Definir modelos, integrar datos persistentes con SwiftUI, gestionar el estado de la app. El mejor sitio para que lo visto en el video anterior se consolide.

Code-along: Build powerful drag and drop in SwiftUI
Construir Solitario para explorar las nuevas capacidades de drag and drop: API de reordenación, drag containers para mover múltiples ítems, y ciclo de vida personalizado. Práctico y directo.

Dive into lazy stacks and scrolling with SwiftUI
Rendimiento de listas y scroll en SwiftUI. Cuándo usar lazy stacks, cómo optimizar el comportamiento de scroll, qué patrones evitar.

Compose advanced graphics effects with SwiftUI
Efectos gráficos avanzados con SwiftUI. Composición de capas, blending modes y efectos visuales que van más allá de lo básico.

Use SwiftUI with AppKit and UIKit
Adopción incremental de SwiftUI en apps existentes de AppKit o UIKit: el framework Observation para actualizar vistas, integrar componentes SwiftUI en jerarquías existentes, y añadir escenas completas SwiftUI sin cambiar la arquitectura.

Modernize your UIKit app
Actualizar layouts de iPhone para funcionar bien con iPhone Mirroring y en iPad. Nuevas APIs de tab y navigation bars, preparar la app para Apple Intelligence, y un skill para el agente de código que moderniza el codebase.

Bloque 3 — Apple Intelligence y Foundation Models

El bloque que más me interesa este año. Lo veo como una unidad porque cada video construye sobre el anterior.

What’s new in the Foundation Models framework
Acceso a Private Cloud Compute, integración de modelos de terceros y open source, capacidades de visión, APIs de gestión de contexto, búsqueda semántica integrada y primitivas para experiencias agénticas. El overview del framework principal de AI en Apple.

Build agentic app experiences with the Foundation Models framework
Perfiles dinámicos, instrucciones dinámicas, gestión del contexto y patrones de orquestación entre modelos locales y de servidor. La capa avanzada sobre el video anterior.

Bring an LLM provider to the Foundation Models framework
Extender el framework implementando un LanguageModelExecutor para modelos nuevos. Interactuar con el transcript de la sesión, gestionar estado, optimizar el cache KV y soportar tipos de segmento personalizados. La puerta para integrar tu propio modelo en el stack de Apple.

Debug and profile agentic app experiences with Instruments
Cómo depurar y perfilar experiencias agénticas con Instruments. Porque cuando algo falla en un agente, necesitas saber dónde y por qué.

Meet the Evaluations framework
En un mundo probabilístico, los tests unitarios no bastan. Métricas cuantitativas y cualitativas, jueces de modelos, estadísticas agregadas para asegurar que las features de AI funcionan de manera fiable.

Create robust evaluations for agentic apps
La capa avanzada de evaluaciones: flujos con tool calling, condiciones dinámicas, generación de datos sintéticos, jueces y validación de datasets. El trabajo real detrás de que un agente se comporte correctamente.

Improve your prompts by hill-climbing with Evaluations
Usar el ciclo de evaluación para mejorar prompts de manera iterativa. El cierre del bloque de evaluaciones.

Build AI-powered scripts with the fm CLI and Python SDK
Scripts con el CLI de Foundation Models y el SDK de Python. Automatización y prototipado fuera del entorno Swift.

Bloque 4 — Siri y App Intents

El puente entre la app y la inteligencia del sistema. Voy de lo conceptual a lo práctico.

Announcing Apple’s next big step for Siri and iPhone
El gran anuncio del nuevo Siri. El contexto imprescindible antes de entrar en los videos técnicos de integración.

Discover new capabilities in the App Intents framework
ValueRepresentation, RelevantEntities, EntityCollection, SyncableEntity, tipos de parámetro más ricos y long-running intents. Las novedades del framework base.

Explore advanced App Intents features for Siri and Apple Intelligence
Técnicas avanzadas para que Siri interaccione con la app de manera natural: descubrimiento de contenido, indexación semántica, búsqueda estructurada y conexión con notificaciones y Now Playing.

Build intelligent Siri experiences with App Schemas
Adoptar App Schemas para que la gente haga preguntas sobre datos de la app y tome acciones mediante lenguaje natural. Ejemplo práctico con eventos de calendario y Spotlight.

Code-along: Make your app available to Siri
El code-along de todo lo anterior: integrar App Intents en una app de calendario real, crear entidades, activar acciones de Siri y personalizar los snippets de respuesta.

Validate your App Intents adoption with AppIntentsTesting
AppIntentsTesting: validar los intents con la misma infraestructura que usan Siri, Shortcuts y Spotlight. Ejecutar intents, inspeccionar resultados, testear entities y queries sin automatización de UI. El cierre del bloque — probar lo que has integrado.

Bloque 5 — Core AI y ML

Para quien quiere ir más allá de los frameworks de alto nivel y entrar en la capa de modelos.

Meet Core AI
El nuevo framework para despliegue de modelos de AI en el dispositivo: ecosistema completo desde Python para conversión y optimización hasta la API Swift para inferencia. Integración profunda con Xcode y compilación ahead-of-time.

Integrate on-device AI models into your app using Core AI
Colección de modelos open source optimizados para Apple silicon — Qwen, Mistral, SAM3 — y cómo integrarlos con pocas líneas de código. Compilación AOT y especialización on-device.

Dive into Core AI model authoring and optimization
Autoría y optimización de modelos con herramientas Python de Core AI. La capa profunda para quien quiere controlar el pipeline completo.

Optimize custom machine learning operations with Metal tensors
La Metal Tensor API y la librería MPP Tensor Ops. Crear operaciones portátiles que aprovechen los Neural Accelerators de M5 y A19, construir kernels custom para apps Core AI y trabajar con formatos cuantizados. La capa baja para empujar el rendimiento al máximo.

Explore numerical computing in Swift with MLX
MLX para computación numérica en Swift. Las primitivas sobre las que se construye todo lo demás en ML.

Explore distributed inference and training with MLX
Inferencia y entrenamiento distribuidos con MLX. Escalar a múltiples Macs.

Run local agentic AI on the Mac using MLX
Agentes de AI corriendo localmente con privacidad, baja latencia y sin conexión. OpenCode, integración con Xcode y técnicas para escalar entre Macs.

Build with the new Apple Foundation Model on Private Cloud Compute
Usar el nuevo modelo de Apple en Private Cloud Compute. El extremo del espectro: cuando el dispositivo no es suficiente pero la privacidad sigue siendo prioritaria.

Bloque 6 — Networking, servicios e infraestructura

Tres videos que cubren la capa de comunicación y runtime: del cliente al servicio, y de la infraestructura que los corre.

Build real-time apps and services with gRPC and Swift
gRPC Swift para experiencias en tiempo real: el framework RPC open source con streaming bidireccional, construido sobre Swift concurrency. Desde la definición del servicio en Protobuf hasta el despliegue en producción. Los mensajes Protobuf son un 50% más pequeños que JSON y el runtime es moderno y seguro.

Discover container machines
Máquinas contenedor en Apple platforms. Infraestructura para desarrollo y despliegue de servicios Swift.

Expand the capabilities of your Virtualization app
Capacidades nuevas en macOS 27 para apps de Virtualization. Automatización del setup de huéspedes macOS en el primer arranque, passthrough de accesorios USB, topologías de red custom y port forwarding.

Bloque 7 — Diseño y accesibilidad

La capa que no se ve pero que define si una app es buena o no.

Principles of great design
Los principios fundamentales del diseño de apps Apple. El marco conceptual antes de entrar en APIs concretas.

Communicate your brand identity on iOS
Expresar la identidad de marca en iOS con las nuevas herramientas de personalización visual.

Design intuitive search experiences
Diseñar búsquedas que la gente entienda y use. Patrones y antipatrones.

Craft clear names for features and labels in your app
Nomenclatura de features y labels. Uno de esos videos que parece menor y que acaba siendo de los más prácticos.

Refine accessibility for custom controls
Accesibilidad en controles personalizados. Cómo hacer que lo que construyes funcione para todo el mundo.

Modernize your AppKit app
Modernizar AppKit a las convenciones actuales de macOS. Input con control events y gesture recognizers más allá de tracking loops, navegación por teclado, restauración de estado, y nuevas APIs de corner concentricity para encajar con la estética macOS.

Bloque 8 — Integración con el sistema

Las APIs que ponen mi app dentro del sistema: superficies como Live Activities, widgets, Lock Screen o CarPlay; integración con apps nativas (Workouts), accesorios Bluetooth, y atajos. Si la app vive más allá de su propia ventana, este bloque es relevante.

Live Activities essentials
Fundamentos de Live Activities: dónde aparecen, el nuevo estilo de Dynamic Island en landscape, cómo estructurar contenido y datos, y cómo dispararlas en tiempo real con ActivityKit y push notifications. La base si voy a usar esta API.

WidgetKit foundations
Los tipos de widget, qué los hace memorables, y cómo mantenerlos al día. Personalización vía App Intents y estilos dinámicos. Si la app necesita vivir fuera de su icono, empieza aquí.

Create live communication experiences
LiveCommunicationKit transforma apps de comunicación real-time en experiencias integradas. UI de conversación nativa, presentación a pantalla completa en Lock Screen, multitasking con Dynamic Island. Conversaciones entrantes, salientes y de grupo.

Rev up your CarPlay app
Nuevas features para apps de audio, navegación y conversación por voz en CarPlay. Apps de video para reproducir contenido en vehículos compatibles cuando están aparcados. Thumbnails, info de media y controles por voz.

Deliver workout insights with HealthKit workout zones
HealthKit con workout insights —zonas de frecuencia cardiaca y de potencia en ciclismo. Zonas built-in o personalizadas, zona actual y tiempo en cada zona para guiar durante y después del entrenamiento.

Find your accessory with Bluetooth Channel Sounding
Channel Sounding añade distancia y dirección a accesorios Bluetooth. Nuevas APIs de Nearby Interaction y Core Bluetooth y los cambios necesarios en el accesorio. Consumo optimizado sin perder respuesta.

What’s new in Shortcuts
Construir atajos con el contenido de la app, nuevas automatizaciones del sistema, y la feature Use Model para refinar cómo se presenta una App Entity a los LLMs. Atajos que almacenan información rica sincronizada entre dispositivos.

LLM search using Core Spotlight
Convertir la búsqueda básica en un sistema RAG con SpotlightSearchTool y LanguageModelSession. Integración con Core Spotlight, hidratación por delegate, PipelineStages para tareas como análisis de sentimiento. Búsqueda contextual real sobre el índice del sistema.

Bloque 9 — Seguridad y administración

Cinco videos que importan más que nunca este año. Con toda la AI añadida, dar por hecho que la integridad de la app, la inyección de prompts o la manipulación del usuario no son problema tuyo es un riesgo. Y para apps que viven en entornos gestionados —educación, empresa, flota— también la postura administrativa importa.

Secure your app: mitigate risks to agentic features
Evaluar amenazas de inyección indirecta de prompts: data exfiltration, acciones no deseadas. Salvaguardas del sistema y buenas prácticas con App Intents y Foundation Models —confirmaciones de usuario, diseño seguro de prompts, autenticación. Obligatorio si tengo features agénticas.

Secure your apps with App Attest
App Attest contra modificación no autorizada y fraude. Cómo los atacantes spoofean datos y saltan checks, y cómo defenderse. Generar y gestionar claves en el Secure Enclave, validar attestations y assertions, y usar la fraud metric para detectar abuso.

Meet Trust Insights
Trust Insights usa ML preservando la privacidad para detectar cuándo alguien podría estar siendo manipulado a acciones de riesgo. Integración, interpretación de señales y diseño de intervenciones que protejan respetando la privacidad.

What’s new in managing Apple devices
Updates a declarative device management, Apple Business y Apple School Manager. Streamline de despliegue, refuerzo de seguridad y mejora de la experiencia de la flota gestionada.

What’s new in assessment on macOS
Automatic Assessment Configuration en macOS para apps de educación. APIs para crear entornos de examen seguros y configurables que incorporan más features del sistema. Prechecks automáticos y controles de accesibilidad para una experiencia de examen fiable.

Bloque 10 — visionOS, RealityKit y contenido espacial

El bloque más extenso del catálogo. Lo veo solo si trabajo con Vision Pro o si quiero experimentar con escenas espaciales. Si no es mi área, lo dejo para más adelante.

Build next-generation experiences with visionOS 27
El overview de visionOS 27: las distintas vías para construir experiencias —tools nativas de Apple, streaming inmersivo desde Mac o PC, third-party engines, port de apps iOS. Avances en creación de contenido 3D, immersive media y object tracking. El video con el que arrancar el bloque.

Explore advances in RealityKit
Las novedades de RealityKit: simulaciones interactivas de tela, NavMesh pathfinding, iluminación mixed reality, reverb meshes personalizables para audio espacial. Mejor sombreado, character rendering y soporte para Gaussian splatting.

Design immersive environments for visionOS apps and the spatial web
Crear entornos fotorrealistas para apps visionOS, webs y experiencias SharePlay. Principios de diseño, captura de referencias, preparación de assets CG de alta fidelidad y efectos en tiempo real como movimiento e iluminación.

Iterate your spatial scenes faster with Reality Composer Pro 3
Las novedades de Reality Composer Pro 3: contenido, VFX, iluminación e interactividad sin salir del editor. Features asistidas por AI integradas en el flujo. La herramienta donde vivirás si haces contenido espacial.

Extend Reality Composer Pro 3 functionality with Xcode
Plugins específicos del proyecto en Reality Composer Pro 3: componentes custom, sistemas custom, nodos propios de ScriptGraph. Control completo del workflow de autoría espacial.

Discover the Spatial Preview framework
El nuevo Spatial Preview framework envía contenido desde Mac directo a visionOS. Live-syncing y edición bidireccional entre plataformas. La API SpatialPreview, device discovery, integración 2D/3D y nuevas capacidades de Quick Look.

Explore enhancements to visionOS object tracking
Avances en object tracking y accesorios espaciales. Trackear objetos en movimiento y handheld, nuevas clases de accesorios espaciales soportadas, y cómo construir accesorios custom para abrir modelos de interacción únicos.

Collaborate on structured 3D models in visionOS
Modelos 3D estructurados en visionOS: preparación USDZ, manipulación de entidades dentro de ensamblajes jerárquicos, inspección con un plano de corte transversal. Animaciones tipo exploded-view para diseño y colaboración en Vision Pro.

Discover USDKit and what’s new in OpenUSD
USDKit en Swift, la nueva API de preview espacial, web espacial mejorado. Updates al estándar OpenUSD: accesibilidad, Gaussian splats, geometría comprimida. Tools de edición y rendering USD ampliadas en Preview para Mac.

Use foveated streaming to bring immersive content to visionOS
Foveated streaming: escenas renderizadas remotamente a Vision Pro en máxima fidelidad. Combina capacidades nativas con streaming third-party de forma inalámbrica, demostrado con una escena OpenXR y NVIDIA CloudXR. Foveated dinámico sin comprometer la privacidad.

Explore immersive website environments in visionOS
La nueva Immersive API en JavaScript transporta visitantes de tu web a entornos virtuales en Vision Pro. Transiciones desde un model element inline, video docking, optimización a escala real. Pocas líneas de código corriendo en la web.

Supercharge your spatial workflows with Reality Composer Pro 3
Interactividad rica y efectos visuales completos dentro de Reality Composer Pro: Shader Graph para materiales, Animation Graph para blending de animaciones esqueléticas, Compute Graph para partículas. Script Graph para interactividad, Sequencer para eventos y Behavior Trees para NPCs.

Build live production tools for Apple Immersive Video
Producción en directo de Apple Immersive Video. Empaquetar video inmersivo, audio espacial y metadata de escena para transporte sobre IP con el estándar SMPTE 2110. Immersive Media Support, Video Toolbox y AVFoundation para flujos en tiempo real.

Bloque 11 — Juegos y Metal

Si trabajo en un juego, este bloque es parada obligada. Si no, lo veo por curiosidad porque hay piezas de rendimiento que aplican también a apps no-juego.

Bringing Cyberpunk 2077 to Mac
Cómo CD PROJEKT RED llevó Cyberpunk 2077 a Mac aprovechando hardware, software y tools de Apple. Técnicas aplicables a otros juegos. El preset For this Mac que optimiza settings automáticamente para balancear fidelidad visual y framerate en toda la línea Mac.

Speedrun your game port with agentic coding
Las nuevas skills agénticas del Game Porting Toolkit 4 aceleran el port. Adoptar Metal 4, integrar MetalFX, tune del juego para hardware Apple. Agentes que diagnostican issues de GPU rendering autónomamente.

Make your game great with touch
Controles touch convincentes para juegos. Insights de devs indie a AAA, buenas prácticas, y cómo aprovechar el Touch Controller framework y Metal para rendimiento óptimo.

Design no-code games with Reality Composer Pro 3
ScriptGraph en Reality Composer Pro 3 para contenido 3D no-code. Nodos visuales para animaciones, momentos interactivos, e integración con SwiftUI para añadir bocadillos y UI a la experiencia.

Build real-time neural rendering pipelines with Metal
ML integrado en el pipeline de rendering con Metal 4. MetalFX neural denoising con insights de Maxon Redshift Live. Entrenar y desplegar un neural tone mapper inline con el ML command encoder, y la nueva tensor API para redes pequeñas dentro de tus shaders.

Find and fix performance issues in your Metal games
Caza de problemas de rendimiento con tools de Metal: Game Performance Overview en Instruments, traces en background con metalperftrace y Control Center, y la nueva StateReporting API para correlar métricas con el estado runtime del juego. Horas de telemetría convertidas en insights accionables.

Bloque 12 — Cámara, fotografía e imagen

Para apps con cámara o procesamiento de imagen. Algunos videos son muy específicos (RAW, Center Stage), otros aplican incluso si solo despliego un preview.

What’s new in image understanding
Vision framework y Foundation Models actualizados. La nueva request tap-to-segment para segmentar imágenes, Vision en watchOS, y soporte de imágenes en el Apple Foundation Model combinado con OCR, escaneo de barcodes y tools propias.

Best practices for integrating visual intelligence in your app
Cómo Visual Intelligence transforma el descubrimiento de contenido. Definir entidades, procesar imágenes, manejar múltiples tipos de resultado. Optimización de velocidad y relevancia, e intents para acciones directas como abrir o reproducir contenido con un tap.

Build a responsive camera app that launches quickly
Optimizar la secuencia completa de arranque de la cámara —desde el startup hasta el primer frame de preview. Nuevas APIs para lanzamientos más rápidos, rendering fluido y rendimiento sostenido. Para que la gente nunca se pierda el momento.

Implement high resolution photo capture
Captura de fotos en alta resolución con AVFoundation. Las tres opciones —RAW, exposure-bracketed, fully processed— y cuándo usar cada una. Configurar captura de 24MP y 48MP en cámaras Main, Tele y Ultra Wide. Deferred photo processing para que la app responda incluso con disparos rápidos.

Enhance RAW image processing with Core Image
La versión 9 de las APIs RAW de Core Image: más nitidez, color más definido, Apple Neural Engine para rendimiento. CIRAWFilter para editar exposición, ruido, sharpness y contraste. Nuevas CIImageProcessor APIs con control fino sobre tile sizing y buffers.

Support the Center Stage front camera in your iOS app
Center Stage con AVCapture APIs en la cámara frontal de iPhone 17, 17 Pro y Air. Zoom y rotate, framing flexible para selfies y videos, todos en el encuadre en fotos de grupo. Integración en videollamadas con auto-framing y estabilización en tiempo real.

Create high quality images using Image Playground
Generación de imágenes con Image Playground. Modelo generativo en Private Cloud Compute, imágenes en casi cualquier estilo incluyendo fotorrealista, dimensiones específicas, y modificación mediante lenguaje natural y touch.

Bloque 13 — Web y Safari

Para web devs: las novedades de WebKit y nuevas piezas de CSS y HTML que Safari estrena este año.

What’s new in WebKit for Safari 27
El overview de WebKit y Safari 27: Grid Lanes, Customizable Select, HTML Model, Immersive Environments, lo último de Web Extensions. Más de 1.000 mejoras del engine para hacer la web más fiable.

Get started with the HTML Model Element
El model element trae contenido 3D interactivo a webs en iOS, iPadOS, macOS y visionOS. Tools para crear y optimizar assets 3D, features del model element, y hacia dónde van los web standards en 3D.

Create web extensions for Safari
Construir y probar web extensions de Safari desde cero —sin Xcode. Content blocking, modificación de páginas, native messaging y el permissions mode trabajando juntos para una experiencia potente y respetuosa con la privacidad.

Learn CSS Grid Lanes
Grid Lanes para layouts web adaptables con elementos de formas variadas. CSS limpio y flexible, y flow-tolerance para refinar accesibilidad sin perder maleabilidad.

Rediscover the HTML select element
Control total del estilo en select menus web. Nuevo valor CSS appearance y nuevos pseudo-elementos, contenido rico dentro de options con nuevas posibilidades HTML. Selects a medida del design system sin renunciar a accesibilidad ni robustez.

Bloque 14 — StoreKit, App Store, suscripciones y Wallet

Para todo lo que toca monetización y App Store Connect. Si vendo algo en mi app, este bloque importa.

What’s new in Apple In-App Purchase
Las nuevas suscripciones mensuales con compromiso a 12 meses como opción más asequible. Configurar y testear con App Store Connect, StoreKit APIs y Xcode testing. Mejoras en redención de offer codes y en la experiencia de App Review.

Enhance your presence on the App Store
Reimaginar el marketing en el App Store usando imágenes y videos en nuevos lugares. Placements visuales nuevos en product page, resultados de búsqueda y campañas de Apple Ads. El nuevo Asset Library centraliza assets y un tool permite ver la product page antes de publicarla.

What’s new in Wallet
Nuevos estilos de pase para diseños ricos. Nuevos formatos de barcode y una API flexible de pass actions. Pass Designer y Pass Builder simplifican diseñar, personalizar y distribuir pases a escala.

Explore Retention Messaging in App Store Connect
Retention Messaging para alcanzar suscriptores antes de que cancelen. Configurar en App Store Connect, añadir subscription offers, y usar la API para mensajería en tiempo real y alternativas que animen a quedarse.

Unlock in-game content with StoreKit and Background Assets
In-App Purchases nativas en Unity con el nuevo StoreKit plug-in. Reducción del tamaño de descarga con Background Assets plug-in entregando packs por idioma. Y un Steam Asset Converter para migrar builds existentes.

Offer subscriptions to groups and organizations
Group Purchases: un suscriptor compra varios asientos e invita a otros desde la app. Volume Purchasing vía Apple Business y Apple School Manager pone tus suscripciones delante de compradores enterprise y educación que ya compran apps a escala.

Bloque 15 — Música, audio y subtítulos

Para apps con contenido multimedia. Hay un framework nuevo este año (Music Understanding) que merece atención incluso si no haces apps de música.

Meet the Music Understanding framework
Nuevo framework Music Understanding que analiza audio en seis dimensiones, on-device: clave, ritmo, estructura, pace, actividad instrumental y loudness. Y un sample app, Music Understanding Lab, para visualizar resultados.

Integrate MusicKit into your app
Apple Music dentro de tu app con MusicKit. Autorización, suscripción, selección de música, control de playback y compartir canciones entre storefronts. Nuevo Music Picker para navegar el catálogo y librerías personales. Diferencias entre SystemMusicPlayer y ApplicationMusicPlayer.

Discover generated subtitles and subtitle styles
Subtítulos generados on-device que transcriben o traducen desde otro idioma. Caption style preview para personalizar y previsualizar durante el playback. Implementación con AVKit, AVPlayerLayer y Media Accessibility.

Meet the Now Playing framework
Nuevo framework Swift Now Playing que conecta el playback de tu app con las superficies del sistema: Lock Screen, Control Center, Dynamic Island, CarPlay. Publicar estado, responder a comandos vía API observable, y remote playback sessions para representar media en dispositivos externos.

Bloque 16 — Accesibilidad, lectura y texto

La capa del texto y la lectura. Aquí no es solo APIs nuevas — es cómo encaja la app con las preferencias de cada persona.

Enhance the accessibility of your reading app
Experiencias de lectura robustas para VoiceOver y Speak Screen. Selección de texto intuitiva, navegación clara entre líneas y párrafos, y lectura continua entre elementos y entre páginas.

Prepare your tvOS apps for Dynamic Type
Dynamic Type en tvOS: implementar escalado de fuentes, adaptar layouts para tamaños grandes, optimizar grids y carousels media-focused. Para que cualquier tamaño de texto siga siendo cómodo.

Elevate your app’s text experience with TextKit
Combinar la conveniencia de los text views built-in con el control de TextKit. Nuevas APIs para extender UITextView y NSTextView con comportamientos custom como números de línea o secciones colapsables. Arquitectura TextKit, caching y políticas de reuse para text attachments.

Unwrap PaperKit
Aplicaciones canvas-based con PaperKit. APIs nuevas del data model para acceder, crear y modificar elementos de markup. Controles custom, anotaciones, y buenas prácticas para integrar un canvas creativo completo.

Read between the strokes with PencilKit
Reconocimiento de escritura a mano con la misma tecnología detrás de Freeform y Notes. Reconocimiento en muchos alfabetos e idiomas, y nuevas capacidades para integrar PencilKit en más tipos de apps.

Bloque 17 — Group Labs

Las Group Labs eran sesiones de Q&A en directo con ingenieros y diseñadores de Apple durante la semana del evento. Apple las mantiene en el catálogo aunque la sesión interactiva ya pasara, así que sirven como referencia rápida del área en la que esté trabajando. Las descripciones oficiales son prácticamente la misma boilerplate, así que las agrupo por tema con una línea de contexto.

Núcleo del lenguaje y frameworks principales
- Swift Group Lab — Q&A sobre los anuncios de Swift de la semana.
- SwiftUI Group Lab y SwiftUI Group Lab (segunda tanda) — Dos sesiones de Q&A sobre los anuncios de SwiftUI.
- SwiftUI for Beginners Group Lab — Q&A para arrancar con SwiftUI desde cero.
- SwiftData Group Lab — Q&A sobre los anuncios de SwiftData.
Xcode, rendimiento y plataformas
- Xcode Tips and Tricks Group Lab — Q&A para sacarle el máximo a Xcode.
- Power and Performance Group Lab — Q&A sobre los anuncios de potencia y rendimiento.
- visionOS Group Lab — Q&A sobre los anuncios de visionOS.
- watchOS Group Lab — Q&A sobre los anuncios de watchOS.
- Safari and Web Technologies Group Lab — Q&A sobre los anuncios de Safari y tecnologías web.
Inteligencia, ML y AI
- Apple Intelligence Group Lab — Q&A sobre los anuncios de Apple Intelligence.
- Machine Learning & AI Group Lab — Q&A sobre los anuncios de ML y AI.
- Coding Intelligence for Beginners Group Lab — Q&A para arrancar con coding intelligence.
- Coding Intelligence, Machine Learning & AI Group Lab — Q&A combinado sobre coding intelligence, ML y AI.
Plataforma, distribución y diseño
- Accessibility Technologies Group Lab — Q&A sobre los anuncios de accesibilidad.
- Privacy and Security Group Lab — Q&A sobre los anuncios de privacidad y seguridad.
- App Store Connect Group Lab — Q&A sobre los anuncios de App Store Connect.
- Camera and Photo Technologies Group Lab — Q&A sobre los anuncios de cámara y fotografía.
- Icon Composer for Beginners Group Lab — Q&A para arrancar con Icon Composer.

Mi Resultado 🎯

Con este orden me ahorro el caos del catálogo y empiezo a ver resultados desde la primera semana.

Mi secuencia resumida:

Bloque 0 — Las presentaciones
Bloque 1 — Swift y herramientas
Bloque 2 — SwiftUI y persistencia
Bloque 3 — Apple Intelligence y Foundation Models
Bloque 4 — Siri y App Intents
Bloque 5 — Core AI y ML
Bloque 6 — Networking, servicios e infraestructura
Bloque 7 — Diseño y accesibilidad
Bloque 8 — Integración con el sistema
Bloque 9 — Seguridad y administración
Bloque 10 — visionOS, RealityKit y contenido espacial
Bloque 11 — Juegos y Metal
Bloque 12 — Cámara, fotografía e imagen
Bloque 13 — Web y Safari
Bloque 14 — StoreKit, App Store, suscripciones y Wallet
Bloque 15 — Música, audio y subtítulos
Bloque 16 — Accesibilidad, lectura y texto
Bloque 17 — Group Labs

Si llevas años viendo el WWDC sabrás que el catálogo nunca caduca — los videos están disponibles todo el año en developer.apple.com. Junio es para las novedades, el resto del año para profundizar. Como conté en WWDC 26, las sesiones técnicas son el plato fuerte — y ahora ya tengo mi propia checklist por la que ir tachando.

Keep coding, keep running 🏃‍♂️

Claude Voice

2026-06-10T00:00:00Z

Mi Problema 🤔

Tengo un problema con la expresión oral que me ha acompañado toda la vida: cuando hablo, las ideas se me amontonan. Mi cabeza va más rápido que mi voz. Empiezo a decir algo, aparece otra idea relacionada, luego otra, y antes de terminar la primera frase ya he perdido el hilo. El resultado es que me expreso peor de lo que pienso.

Escribiendo, en cambio, tengo tiempo. Escribir es lento por naturaleza, y esa lentitud me obliga a ordenar. Mientras el dedo busca la letra, el pensamiento se asienta. Por eso desde que uso Claude Code intensivamente, siempre he trabajado con texto. El teclado es mi capa de filtro natural.

Eso funcionó bien hasta que dejó de funcionar.

En una carrera de monte tuve un accidente. Caída tonta, consecuencias no tan tontas, semanas de recuperación, y lo que más me dolió en ese momento: poca movilidad para teclear con normalidad. De golpe, mi método de trabajo preferido quedó bloqueado.

Las opciones eran dos: o usaba la voz o asumía que iba a trabajar a un ritmo absurdamente lento. No era una elección filosófica sobre los modos de comunicación con la IA. Era pura necesidad.

Mi Solución 🧩

Empecé a usar la voz con Claude Code a la fuerza, sin romantizar el proceso. Los primeros días fueron exactamente tan malos como esperaba. Frases cortadas, ideas que llegaban en el orden equivocado, contexto que se perdía por el camino. El modelo respondía bien, pero yo le estaba dando material mediocre.

Lo que descubrí enseguida es que el problema no era la herramienta de transcripción, sino yo. No sabía estructurar un pensamiento para verbalizar antes de verbalizar. Con el teclado me corrijo sobre la marcha sin darme cuenta. Con la voz, el error sale y ya está.

Así que cambié el enfoque. En lugar de intentar improvisar, empecé a preparar mentalmente lo que iba a decir antes de hablar. No guiones, solo un segundo de silencio para ordenar:

¿Cuál es el contexto que el modelo necesita?
¿Qué quiero que haga exactamente?
¿Qué restricciones hay que mencionar?

Ese segundo de pausa fue el cambio más grande. Es exactamente lo que hago con el teclado de forma inconsciente, pero con la voz tengo que hacerlo de forma consciente y explícita.

La otra cosa que aprendí es que la voz favorece la brevedad. Cuando escribo, tiendo a añadir matices. Cuando hablo, voy al grano porque mantener una frase larga en la cabeza es agotador. Y resulta que Claude responde igual de bien a prompts concisos que a prompts detallados, siempre que el contexto esté claro.

Lo que terminé haciendo fue una especie de protocolo informal para las sesiones de voz:

Empezar por el qué antes del cómo
Una idea por turno, sin encadenar peticiones
Si la respuesta no es lo que esperaba, reformular desde cero en lugar de corregir encima

Con ese esquema, las sesiones empezaron a funcionar. No perfectas, pero funcionales.

Mi Resultado 🎯

Hay situaciones en las que la voz gana con claridad. Cuando estoy pensando en voz alta sobre una arquitectura, cuando quiero explorar varias opciones antes de escribir código, cuando necesito describir un comportamiento que es más fácil de narrar que de especificar. El teclado sigue siendo mi modo principal, pero la voz ya no es el último recurso.

Lo que cambió fue que aprendí a estructurar mejor antes de hablar. Y eso, curiosamente, mejoró también cómo escribo los prompts. El hábito de la pausa, de ordenar antes de emitir, se transfirió.

El accidente me forzó a entrenar una habilidad que nunca habría entrenado voluntariamente. No porque no supiera que existía, sino porque tenía una alternativa cómoda que usaba siempre. Cuando la alternativa desaparece, te sorprendes de lo que eres capaz de aprender.

Si trabajas con modelos de lenguaje de forma habitual y nunca has probado la voz, no hace falta que te rompas nada para intentarlo. Una semana con restricción voluntaria al teclado es suficiente para ver si hay algo ahí que vale la pena. A mí me costó un accidente descubrirlo. Tú tienes ventaja.

Keep coding, keep running 🏃‍♂️

WWDC 26

2026-06-03T00:00:00Z

Mi Problema 🤔

Cada junio escucho a la gente hablar del gran estreno de la temporada. La peli del verano, la nueva temporada de tal serie, la secuela que llevaban años esperando. Y yo asiento y pienso en lo mío: dentro de unos días llega el WWDC.

Mi problema es que es muy difícil explicar esa sensación a alguien fuera del entorno de desarrollo de Apple. Decir que llevas semanas con el calendario marcado, que te tomas el día del Keynote como una festividad, que se te disparan los nervios según se acerca la hora — dicho sin contexto, suena raro. Para quien no programa en Swift, una keynote de dos horas hablando de APIs es lo más alejado que existe de un estreno de cine.

No es frikismo sin más. El WWDC tiene algo que no tiene ningún estreno: lo que anuncian afecta directamente a mi trabajo, a las decisiones que tomé hace seis meses y que ahora van a tener respuesta oficial. Cuando se apagan las luces de mi sala particular, no soy un espectador más — soy el público objetivo.

Mi Solución 🧩

Dejé de intentar justificarlo. El WWDC es mi estreno del año, y lo disfruto más que cualquier película o serie. Me lo paso como un niño.

La semana previa

Empieza antes del lunes. Los rumores están en máximos, la comunidad está en modo especulación total, y yo llevo días pensando en qué van a anunciar y cómo va a afectar a lo que tengo entre manos. Es la misma energía que la semana antes de un estreno muy esperado, con una diferencia fundamental: el resultado me importa de verdad — como alguien a quien lo anunciado le cambia el trabajo.

El Keynote como ritual

En España, el Keynote me toca a las 19:00. La hora perfecta — cierro el día de trabajo, cena pronto, y a partir de ahí solo existe el Keynote.

Mi ritual incluye un montaje de pantallas que parecería absurdo desde fuera. En la principal, el stream oficial de Apple. En una segunda, un grupo de locos haciendo comentarios en directo — comentan cada slide, predicen lo siguiente, reaccionan en tiempo real. Y en una tercera, voy siguiendo X, blogs técnicos y los Slack y Discord de desarrolladores: matices que se escapan en los slides y primeros análisis sobre el impacto real.

Lo que más me gusta es que el Keynote mezcla dos cosas que raramente van juntas: la emoción del espectáculo y la información técnica que me cambia el trabajo. Cada feature la proceso en dos niveles a la vez — espectador que disfruta y desarrollador que ya piensa en cómo integrarlo.

Y luego están los momentos de “¡sí!” — cuando anuncian algo que llevabas tiempo pidiendo. El año pasado, con las mejoras en Swift Concurrency, me levanté del sofá. Literalmente.

Las sesiones son el verdadero contenido

El Keynote es el aperitivo. Las sesiones técnicas son el plato fuerte, y duran semanas.

Reviso el catálogo como quien revisa la cartelera de un festival de cine. Con más de cien sesiones, seleccionar y priorizar es ya una actividad en sí misma. Y no caducan: Apple las mantiene en developer.apple.com indefinidamente. Junio es para las novedades, y el resto del año para profundizar en las que dejé pendientes.

Esto conecta con Swift Pills: conocimiento denso que merece consumirse con calma. Y con Apple Coding Speed: la velocidad de comprensión que entrenas es lo que te permite sacar partido de cada sesión.

Las betas como parque de juegos

El día del Keynote se abren las betas. A partir de ahí empieza el juego: instalar, compilar contra el nuevo SDK, ver qué se rompe, explorar las APIs antes de que tengan documentación completa. Es acceso anticipado, pero el juego soy yo desarrollando — y lo que descubro puede cambiar decisiones de diseño que llevo meses madurando.

La comunidad en modo WWDC

La conversación técnica de desarrolladores de Apple se dispara. Todo el mundo tiene algo que comentar, algo que ha descubierto, algún detalle que ha cambiado cómo veía un problema.

Las conferencias del ecosistema — como las que sigo en Conferences 25 — tienen esa energía, pero el WWDC la lleva al extremo: es el momento del año en que toda la comunidad mira lo mismo al mismo tiempo.

Mi Resultado 🎯

Ya no intento explicarlo. Acepto que el WWDC es mi evento del año y lo disfruto sin complejos.

Lo que me da cada junio:

Anticipación genuina — el evento que afecta directamente a mi trabajo
El Keynote como espectáculo — dos horas en modo doble: espectador y desarrollador
Sesiones técnicas que duran meses — material denso que consumo con calma el resto del año
Las betas como laboratorio — acceso anticipado a las nuevas APIs antes que nadie
La comunidad en su pico — la conversación técnica más rica del año
Respuestas a problemas que tienes encima de la mesa — satisfacción sin equivalente

Si tienes un evento del año que te hace sentir como un niño, no lo justifiques. Disfrútalo. El mío es el WWDC, y ya tengo ganas del próximo.

Keep coding, keep running 🏃‍♂️

Swift Pills

2026-05-27T00:00:00Z

Mi Problema 🤔

Estar al día con Swift es una de esas cosas que siempre tengo en la lista y que casi nunca consigo tachar. Cada WWDC trae cosas nuevas, el lenguaje evoluciona, la comunidad publica sin parar, y yo mientras tanto estoy con el proyecto, con las reuniones, con la vida. La información existe — el problema es encontrar el hueco para entrarle.

Y es que casi todo el contenido técnico viene en formatos grandes: vídeos de cincuenta minutos, sesiones enteras de WWDC, artículos kilométricos, libros. Todo eso pide tiempo y cabeza, y en mi día a día no siempre tengo ninguna de las dos. Lo que acaba pasando es que voy guardando enlaces “para cuando tenga un rato” — y ese rato no llega.

Mi Solución 🧩

El blog de Arturo Rivas cambia la forma de consumir contenido sobre Swift. Lo que él publica son píldoras de conocimiento: artículos cortos, de unos cinco minutos de lectura, donde te cuenta una cosa concreta y se va. Sin rodeos, sin relleno, sin “antes de empezar permítanme contextualizar”.

Y lo que más me ha enganchado es que la mayoría de las veces son píldoras sobre cosas que ni siquiera te habías parado a considerar. Detalles del lenguaje, comportamientos sutiles, APIs que estaban ahí desde hace versiones y que nunca te habías cruzado con ellas. Cosas que cuando las lees piensas “anda, esto no lo sabía” — y a partir de ahí ya no se te olvidan.

Cinco minutos cambian la ecuación

Que sean píldoras de cinco minutos no es un detalle menor — es lo que hace que funcione. No necesito reservar un hueco, no necesito ponerme en modo estudio, no necesito ni siquiera estar en el ordenador. Las leo entre tareas, mientras espera un build, con el café de la mañana. El aprendizaje deja de competir con el trabajo y se cuela en los márgenes del día.

Y como cada píldora va a una sola cosa, la retención es brutal. Cuando un artículo es largo necesito procesarlo a fondo, sentarme a estudiarlo y darle varias vueltas para que se quede. Cuando leo una píldora sobre, por ejemplo, cómo funciona @discardableResult o un detalle de Sendable que no había visto, ese concepto entra directamente. Era el único foco durante esos cinco minutos, y mi cabeza lo trata como tal.

Cosas que ni habías considerado

Esto para mí es lo más valioso del blog. Arturo no escribe sobre “qué es Swift” ni sobre cosas que ya están en cualquier tutorial. Escribe sobre rincones del lenguaje, sobre comportamientos que tienen su porqué pero que normalmente no te paras a investigar, sobre APIs que se quedan tapadas por las grandes novedades de cada año.

Es ese tipo de conocimiento que no buscas activamente porque ni sabes que existe — pero que cuando lo tienes, te cambia la forma de leer y escribir código. Te das cuenta de que hay un patrón mejor, una herramienta que llevaba tiempo disponible, un detalle que explica por qué algo se comporta como se comporta.

Encaja en mi flujo sin pedir permiso

Empecé a tratar las píldoras como parte natural del día, no como tarea aparte. Cinco minutos antes de entrar en faena, otros cinco entre dos reuniones, mientras Xcode compila algo pesado. Sin la sensación de “ahora tengo que aprender” — simplemente dejando que entren cuando hay hueco.

El contraste con los formatos largos es brutal. Para un vídeo de WWDC necesito planificarlo, sentarme, tener atención plena. Para una píldora, simplemente la abro cuando aparece la ocasión. Y resulta que las ocasiones son muchas más de las que pensaba.

Esto conecta con algo que ya conté en Apple Coding Speed: la velocidad de comprensión no se entrena solo en formaciones largas. También se entrena en la exposición constante a conceptos bien explicados — y las píldoras son justo eso, entrenamiento continuo que sucede entre sesiones más estructuradas.

Mi Resultado 🎯

Si trabajas con Swift y se te están acumulando los enlaces “para cuando tenga un rato”, el problema probablemente no es la cantidad de contenido — es el formato. Pásate por blog.arturorivas.com y prueba el modelo de las píldoras durante una semana.

Lo que yo he sacado en limpio:

Aprendo cosas que ni buscaba — la mayoría de las píldoras tocan detalles que no habría buscado por mi cuenta, y son las que más me han aportado
El conocimiento entra sin esfuerzo — cinco minutos caben en cualquier hueco, así que el aprendizaje deja de depender de planificación
Se me queda lo que leo — un solo concepto por píldora hace que la retención sea mucho más alta que con artículos largos
Reconozco patrones más rápido — cuando me cruzo con una API o un patrón que vi en una píldora, lo identifico sin tener que buscarlo
Se acabó la deuda de “tengo que leer esto” — el contenido de bajo umbral se consume en el momento, no se aplaza

Si quieres medicina de la nueva, la tienes en píldoras de conocimiento aquí. Cinco minutos, una idea, una cosa que probablemente no habías considerado. Difícilmente vas a encontrar mejor relación entre tiempo invertido y aprendizaje que se queda.

Keep coding, keep running 🏃‍♂️

Apple Coding Speed

2026-05-20T00:00:00Z

Mi Problema 🤔

Cuando decidí especializarme en el ecosistema de Apple, buscaba una formación cercana con un perfil muy concreto: rigurosa, profesional, estructurada, y con una comunidad técnica activa detrás. No otra introducción a SwiftUI, sino el ecosistema completo — Swift Concurrency, server-side, accesibilidad, agentes con IA — al nivel de la documentación oficial.

Esa búsqueda me llevó a Apple Coding Academy, un referente en formación especializada en desarrollo nativo con tecnologías de Apple. Y, una vez dentro, apareció una pregunta más interesante que la que me había llevado allí: ¿qué me da una formación estructurada de Apple Coding Academy que no me daría leer la documentación por mi cuenta?

La respuesta tardó más de lo esperado en llegar, y cuando llegó no fue lo que anticipaba.

Mi Solución 🧩

Lo que me dieron las formaciones de Apple Coding Academy no fue el conocimiento. Fue la velocidad.

No velocidad de ejecución — eso es un subproducto. Velocidad de comprensión. Velocidad de análisis. Velocidad para llegar al núcleo de un problema antes de que se expanda. Y esa velocidad, una vez que la tienes, se transfiere a todo.

Lo que realmente entrenas en Apple Coding Academy

Cuando entras en un programa estructurado de Apple Coding Academy — ya sea el Swift Developer Program, el Swift Agentic Engineering Program, o cualquiera de sus formaciones — lo primero que notas es el ritmo. Es alto. Los conceptos se acumulan rápido porque hay una curva diseñada, un orden que maximiza la retención.

El resultado es que después de varias formaciones, cuando encuentro una API nueva en Swift, no la proceso igual que antes. El patrón de reconocimiento es más rápido. Veo la firma del método, identifico los protocolos que implementa, infiero el comportamiento antes de leer la documentación. No es intuición — es velocidad entrenada.

Velocidad de comprensión

Lo primero que cambia es cómo lees código. Antes de las formaciones, leer un archivo de Swift desconocido era un proceso secuencial: línea a línea, buscando referencias, construyendo el modelo mental despacio.

Después de suficientes horas de formación, la lectura se aproxima al escaneo. Identificas los patrones — async/await, composición de protocolos, la estructura de un actor — antes de procesar el detalle. El tiempo de comprensión se desploma.

Eso importa más de lo que parece. Ahora, con el uso de la IA, paso más tiempo leyendo código que escribiéndolo. Si la velocidad de lectura y entendimiento sube, el tiempo de entrega baja sin que la calidad cambie.

Velocidad de análisis

Lo segundo que cambia es cómo analizo problemas. Las formaciones de Apple Coding Academy tienen una característica que al principio me resultó incómoda: los problemas no vienen bien definidos. Tienes un objetivo, un conjunto de herramientas, y la expectativa de que seas tú quien trace el camino.

Eso entrena algo específico: separar lo que importa de lo que no importa antes de empezar a trabajar. Identificar el punto de fricción real, no el síntoma superficial.

En mi día a día, ese entrenamiento se traduce en que cuando aparece un bug o una decisión de arquitectura, no salto directamente a resolver lo visible. Primero analizo. El análisis es más rápido porque tengo más contexto entrenado. La solución llega antes y con menos iteraciones.

Velocidad de desarrollo

Lo tercero que cambia es la ejecución. Cuando comprensión y análisis son más rápidos, el desarrollo lo es también — no porque escriba más rápido, sino porque, con el uso de la IA, escribo menos código a mano y dedico ese tiempo a revisar y dirigir lo que el modelo propone. Menos código de exploración, menos prototipos descartados, menos refactorizaciones de cosas que nunca deberían haberse escrito así.

Las formaciones de Apple Coding Academy llevan esto en su ADN: la filosofía de diseño de Apple premia la claridad y la economía. Menos superficie para el mismo comportamiento. Eso lo asimilas aunque nadie te lo explique de forma explícita — lo absorbes del ecosistema.

Las formaciones que he hecho en Apple Coding Academy

He recorrido varias etapas dentro del catálogo de Apple Coding Academy. El Bootcamp me dio los fundamentos del ecosistema: tipos, gestión de memoria, Swift Concurrency, composición de protocolos, integración con frameworks nativos. Cinco meses de inmersión que cubren el camino completo hasta un perfil profesional de desarrollo Apple.

Después llegaron formaciones más específicas: módulos de server-side con Swift, de accesibilidad, y del rediseño visual con Liquid Glass. Cada módulo apunta a una capa distinta del stack y exige un nivel de profundidad que rara vez alcanzo solo leyendo.

Más recientemente, el Swift Agentic Engineering Program — sesenta horas centradas en desarrollo de agentes con IA, MCP, Spec Driven Development y Foundation Model Framework. Una formación que no existe en la documentación oficial porque combina piezas que aún se están definiendo en el ecosistema.

Cada capa añadió algo diferente. Los fundamentos me dieron el vocabulario. Las formaciones de servidor me dieron la perspectiva de qué pasa cuando el código está en producción bajo carga real. Las de diseño de sistema me enseñaron a pensar en seams — los puntos donde el comportamiento puede variar sin que lo que está detrás cambie. Las de agentes me dieron el marco para integrar IA en flujos de desarrollo de forma rigurosa.

Lo que tienen en común es que todas me forzaron a salir de mi zona de confort a una velocidad que yo solo no habría mantenido. Eso es lo que no consigo con la documentación autodidacta: el ritmo externo.

El efecto compuesto

Lo interesante de esta velocidad es que se compone. No sumas horas de formación de forma lineal — las capas se potencian entre sí.

La comprensión rápida acelera el análisis porque procesas más contexto en menos tiempo. El análisis rápido acelera el desarrollo porque llegas al problema real antes. Y el desarrollo más limpio reduce el tiempo de mantenimiento futuro.

El retorno no está en los primeros meses. Está en el año tres, cuando miras atrás y constatas que el nivel de decisiones que tomas en cinco minutos antes te llevaba una tarde.

Esto conecta directamente con lo que exploro en Claude Code: la IA amplifica lo que ya sabes. Si tu comprensión del ecosistema es profunda, las sugerencias del modelo son más útiles porque sabes evaluarlas. Si es superficial, el modelo te entrega código que compila pero no entiendes. La formación hace que la IA sea mejor herramienta, no al revés. Esa es justo la apuesta del Swift Agentic Engineering Program de Apple Coding Academy: entrenar el criterio antes de delegar en el modelo.

Mi Resultado 🎯

La respuesta a la pregunta que me hice — qué me da una formación de Apple Coding Academy que no me daría la documentación sola — es esta: el ritmo. La presión diseñada. El entorno que fuerza la conexión rápida de piezas.

La documentación te da el qué. La formación te entrena el cómo y, sobre todo, la velocidad con la que llegas al por qué.

Lo que noto en mi trabajo ahora:

Diagnóstico más rápido — identifico el problema real antes de tocar código
Menos iteraciones — las decisiones de diseño llegan antes de escribir la primera línea
Lectura de código más eficiente — proceso archivos desconocidos sin recorrer línea a línea
Criterio más sólido — sé cuándo un patrón es correcto para el contexto y cuándo es solo familiar
Mejor uso de la IA — evalúo las sugerencias del modelo porque entiendo el ecosistema con profundidad

Keep coding, keep running 🏃‍♂️

Save Tokens

2026-05-13T00:00:00Z

Mi Problema 🤔

Trabajo con Claude Code a diario y empecé a notar un patrón que me llamó la atención: cada vez que una skill o una conversación necesitaba ejecutar algo en el shell, la IA gastaba tokens antes de ejecutar nada. Razonaba sobre qué comando construir, lo redactaba, lo lanzaba, leía el output y luego lo interpretaba para seguir trabajando.

En una operación aislada, ese coste se nota poco. El problema real aparece en cuanto hay repetición. Una skill que recorre varios archivos, una conversación que reorganiza directorios, un flujo que necesita hacer la misma operación con argumentos distintos — todo eso multiplica el coste del razonamiento por cada iteración. Cada vuelta del bucle vuelve a construir un comando que, en el fondo, es idéntico al de la vuelta anterior salvo por un parámetro.

Y aquí la clave: ese razonamiento es trabajo determinista disfrazado de razonamiento. No estoy pidiéndole a la IA que decida nada — solo que vuelva a escribir un comando que ya escribió antes. Es exactamente el tipo de tarea que un script resuelve mejor que un modelo.

Mi Solución 🧩

La idea es sencilla: si una skill o un flujo necesita ejecutar lógica de shell, esa lógica no debería vivir en la cabeza de la IA — debería vivir en un .sh que la IA invoca con una sola línea.

El cambio mental

El instinto natural cuando configuras una skill es describir paso a paso lo que la IA tiene que hacer:

Lista los archivos del directorio, filtra los que terminan en .json, lee cada uno, extrae el campo version, encuentra el mayor, y devuélvelo.

Esa descripción obliga a la IA a construir cada comando, ejecutarlo, interpretar la salida y encadenar el siguiente paso. En su lugar, la instrucción debería ser:

Ejecuta la script latest-version /ruta.

La diferencia es que todo el razonamiento sobre cómo se hace la operación deja de ocurrir en cada invocación. Ocurre una sola vez, cuando escribes el script. A partir de ahí, la IA solo necesita saber qué ejecutar y qué formato recibir.

Por qué los bucles son el caso crítico

El ahorro se nota incluso en operaciones puntuales, pero se vuelve enorme cuando la skill itera. Sin script, cada vuelta del bucle paga el coste de razonar y construir el comando. Con script, la IA lanza una sola invocación y recibe el agregado completo.

La regla práctica que aplico: si la operación se puede agregar en un único paso de shell, debería hacerlo el script — no la IA iterando externamente.

Estructura que uso en mis skills

Cada skill mía sigue la misma forma: un SKILL.md corto que describe el contrato, y una carpeta scripts/ con la lógica empaquetada.

~/.claude/skills/
└── mi-skill/
    ├── SKILL.md          ← instrucciones para la IA (qué ejecutar, qué esperar)
    └── scripts/
        ├── operacion-a.zsh
        └── operacion-b.zsh

Cada vez que la skill necesita una capacidad nueva, añado un script en lugar de añadir instrucciones bash inline. La skill gana funcionalidad sin engordar el contexto que la IA tiene que procesar en cada invocación.

Uso .zsh porque trabajo en macOS, donde es el shell por defecto desde Catalina y puedo aprovechar features que bash no tiene. El patrón funciona exactamente igual con .sh y bash. Elige la que case con tu entorno.

Y un detalle importante: los scripts los escribo con ayuda de la propia IA, una sola vez. Ese razonamiento — el de diseñar el comando correcto, manejar los edge cases, devolver el JSON adecuado — ocurre durante la creación del script. Después, ese trabajo queda cristalizado en el archivo y no se vuelve a pagar.

Mi Resultado 🎯

El cambio es directamente observable en cuanto separas la lógica determinista del razonamiento. La IA pasa de construir comandos a consumirlos. De interpretar salidas variables a leer JSON estructurado. De iterar externamente a recibir el agregado completo en una llamada.

Los beneficios concretos que estoy viendo:

Menos tokens por invocación — el razonamiento sobre cómo hacer la operación ocurre una sola vez, al escribir el script, no cada vez que la skill se ejecuta
Consistencia — el script siempre devuelve el mismo formato; la IA no interpreta salidas variables en cada ejecución
Mantenibilidad — cuando cambia la lógica, edito el script en un sitio; el SKILL.md no se toca
Escalabilidad en bucles — el script agrega antes de devolver; una llamada sustituye a N iteraciones
Skills más simples — el SKILL.md describe qué hacer, no cómo; la complejidad operacional vive en los scripts

El patrón se aplica a cualquier skill o flujo que tenga que operar sobre el sistema de archivos, procesar texto estructurado o ejecutar lógica repetitiva. Si te encuentras describiendo en el SKILL.md una secuencia de comandos bash que la IA debería construir y ejecutar, esa secuencia probablemente debería ser un script.

Como exploré en el artículo sobre Claude Code, la clave no es darle más capacidad de razonamiento a la IA para que resuelva más cosas — es estructurar el trabajo para que solo razone donde aporta valor. Lo determinista lo resuelve un script. Lo creativo y contextual lo resuelve la IA. Cada uno en su sitio.

Keep coding, keep running 🏃‍♂️

UUID v7

2026-05-06T00:00:00Z

Mi Problema 🤔

En mi proyecto uso PostgreSQL como base de datos y UUID como identificador en todos mis modelos. Es el estándar habitual: universal, sin colisiones, seguro. Pero me encontré con un problema cuando mis tablas empezaron a crecer.

UUID v4 es completamente aleatorio. Esto significa que cada nuevo registro se inserta en una posición aleatoria dentro del índice B-Tree. El índice se fragmenta, las páginas se dividen, y el rendimiento de escritura degrada progresivamente. En tablas con millones de registros, el impacto es real.

La solución existe desde hace tiempo en bases de datos como MongoDB con ObjectID o en sistemas que usan ULID: embeber el timestamp en el identificador para que los registros nuevos se inserten siempre al final del índice.

UUID v7, definido en el RFC 9562, trae exactamente eso al estándar UUID. PostgreSQL 18 ya incluye la función nativa uuidv7(). Pero Swift — y por extensión Fluent — sigue generando UUID v4 por defecto con UUID().

Si el identificador lo genera mi aplicación antes de persistirlo, estoy perdiendo las ventajas de v7 aunque mi base de datos ya lo soporte.

Mi Solución 🧩

Decidí crear una extensión sobre UUID que implementa la generación de UUID v7 directamente en Swift, siguiendo la especificación del RFC 9562.

Estado monotónico

Lo primero que necesito es un estado compartido que garantice que dos UUIDs generados en el mismo milisegundo sean distintos y estén ordenados. Uso un Mutex del framework Synchronization para hacerlo thread-safe sin recurrir a DispatchQueue ni actor:

import Foundation
import Synchronization

private let v7State = Mutex(V7State())

private struct V7State: Sendable {
    var lastTimestamp: UInt64 = 0
    var sequence: UInt16 = 0
}

La generación del UUID

La extensión principal implementa el método estático v7() que genera un UUID conforme al RFC 9562:

extension UUID {
    public static func v7() -> UUID {
        var bytes = (
            UInt8(0), UInt8(0), UInt8(0), UInt8(0),
            UInt8(0), UInt8(0), UInt8(0), UInt8(0),
            UInt8(0), UInt8(0), UInt8(0), UInt8(0),
            UInt8(0), UInt8(0), UInt8(0), UInt8(0)
        )

        let (timestamp, seq) = v7State.withLock { state -> (UInt64, UInt16) in
            var now = UInt64(Date().timeIntervalSince1970 * 1000)

            if now == state.lastTimestamp {
                if state.sequence >= 0x0FFF {
                    while now == state.lastTimestamp {
                        now = UInt64(Date().timeIntervalSince1970 * 1000)
                    }
                    state.lastTimestamp = now
                    state.sequence = UInt16.random(in: 0...0x0FFF)
                } else {
                    state.sequence += 1
                }
            } else {
                state.lastTimestamp = now
                state.sequence = UInt16.random(in: 0...0x0FFF)
            }

            return (now, state.sequence)
        }

        // Bytes 0–5: 48-bit timestamp (big-endian)
        bytes.0 = UInt8(truncatingIfNeeded: timestamp >> 40)
        bytes.1 = UInt8(truncatingIfNeeded: timestamp >> 32)
        bytes.2 = UInt8(truncatingIfNeeded: timestamp >> 24)
        bytes.3 = UInt8(truncatingIfNeeded: timestamp >> 16)
        bytes.4 = UInt8(truncatingIfNeeded: timestamp >> 8)
        bytes.5 = UInt8(truncatingIfNeeded: timestamp)

        // Byte 6: version (0x7_) | top 4 bits of sequence
        bytes.6 = 0x70 | UInt8(seq >> 8)

        // Byte 7: lower 8 bits of sequence
        bytes.7 = UInt8(truncatingIfNeeded: seq)

        // Bytes 8–15: random, then set variant
        var random: UInt64 = 0
        withUnsafeMutableBytes(of: &random) { buf in
            _ = SecRandomCopyBytes(kSecRandomDefault, buf.count, buf.baseAddress!)
        }
        bytes.8  = UInt8(truncatingIfNeeded: random >> 56)
        bytes.9  = UInt8(truncatingIfNeeded: random >> 48)
        bytes.10 = UInt8(truncatingIfNeeded: random >> 40)
        bytes.11 = UInt8(truncatingIfNeeded: random >> 32)
        bytes.12 = UInt8(truncatingIfNeeded: random >> 24)
        bytes.13 = UInt8(truncatingIfNeeded: random >> 16)
        bytes.14 = UInt8(truncatingIfNeeded: random >> 8)
        bytes.15 = UInt8(truncatingIfNeeded: random)

        // Byte 8: variant 0b10xx_xxxx
        bytes.8 = (bytes.8 & 0x3F) | 0x80

        return UUID(uuid: bytes)
    }
}

La estructura del UUID generado respeta la especificación del RFC 9562:

Bytes 0–5 (48 bits): timestamp en milisegundos desde epoch, en big-endian. Esto es lo que garantiza el orden cronológico.
Byte 6 (nibble alto): versión 0x7 — identifica el UUID como v7.
Bytes 6–7 (12 bits inferiores): contador de secuencia. Garantiza monotonicidad dentro del mismo milisegundo.
Bytes 8–15 (64 bits): aleatorios generados con SecRandomCopyBytes, con los dos bits superiores del byte 8 forzados a 0b10 para marcar el variante RFC 4122.

La lógica monotónica dentro del withLock funciona así: cuando dos llamadas ocurren en el mismo milisegundo, el contador se incrementa. Si el contador alcanza el máximo (0x0FFF, es decir 4095 UUIDs en un solo milisegundo), la implementación espera activamente al siguiente milisegundo antes de continuar — nunca genera dos UUIDs idénticos.

Utilidades de inspección

Además de la generación, añadí dos propiedades para poder inspeccionar cualquier UUID: una que verifica si es v7 y otra que extrae el timestamp embebido:

extension UUID {
    public var isV7: Bool {
        (uuid.6 >> 4) == 0x07 && (uuid.8 >> 6) == 0x02
    }

    public var v7Timestamp: Date? {
        guard isV7 else { return nil }

        let ms = UInt64(uuid.0) << 40
            | UInt64(uuid.1) << 32
            | UInt64(uuid.2) << 24
            | UInt64(uuid.3) << 16
            | UInt64(uuid.4) << 8
            | UInt64(uuid.5)

        return Date(timeIntervalSince1970: Double(ms) / 1000.0)
    }
}

isV7 comprueba que el nibble alto del byte 6 sea 0x07 (versión 7) y que los dos bits superiores del byte 8 sean 0b10 (variante RFC 4122). v7Timestamp reconstruye los 48 bits del timestamp desde los bytes 0–5 y los convierte en un Date.

Mi Resultado 🎯

La adopción es inmediata. En cualquier modelo Fluent, me basta con sustituir UUID() por UUID.v7() en el inicializador:

// Antes
self.id = UUID()

// Después
self.id = UUID.v7()

El tipo en base de datos no cambia — sigue siendo UUID. Fluent no necesita ninguna modificación. El cambio es completamente transparente para el ORM.

Los beneficios que he obtenido son directos:

Índices ordenados — los nuevos registros se insertan siempre al final del B-Tree, eliminando la fragmentación
Ordenación cronológica nativa — ORDER BY id equivale a ORDER BY created_at sin columna extra
Timestamp embebido — puedo extraer cuándo se creó un registro directamente del UUID con v7Timestamp
Compatible hacia atrás — el formato sigue siendo UUID estándar; cualquier sistema que acepte UUID v4 acepta v7
Thread-safe — funciona correctamente desde múltiples hilos concurrentes gracias al Mutex

let id = UUID.v7()

print(id.isV7)          // true
print(id.v7Timestamp!)  // la fecha de creación embebida en el UUID

Y si ya estás en PostgreSQL 18, la función nativa uuidv7() genera UUIDs con la misma estructura. Los UUIDs generados desde Swift y desde PostgreSQL son intercambiables y comparables entre sí.

El cambio de UUID() a UUID.v7() es de una línea. Las ventajas, permanentes.

Keep coding, keep running 🏃‍♂️

SIGBUS

2026-04-29T00:00:00Z

Mi Problema 🤔

Estoy escribiendo tests con Swift Testing, el stack nativo de Apple. Comparo dos modelos con #expect(a == b) y verifico errores con #expect(throws: MyError.self) — la API que la propia librería ofrece de serie. Lanzo los tests. Y mi binario muere con esto:

*** Signal 10: Backtracing from 0x18a3c4e8c... done ***
Process terminated by signal 10 (SIGBUS)
Stack trace:
  ...
  _swift_buildDemanglingForMetadata
  ...
  swift_testing.Issue.record(...)

SIGBUS. No es un fallo de aserción. Es el runtime de Swift rompiéndose dentro del propio test runner. Y solo pasa cuando un test falla — si todos pasan, no me entero del problema.

El patrón es muy concreto. El runtime crashea cuando uso #expect(==) sobre enums con valores asociados, o cuando uso #expect(throws:) sobre un tipo de error que es un enum con valores asociados. En cuanto el test falla, swift-testing intenta construir el mensaje de error pidiéndole al runtime que reconstruya los metadatos de tipo de los valores que comparó. Y ahí truena: _swift_buildDemanglingForMetadata, signal 10, fin.

Es el bug swiftlang/swift#76608, abierto desde septiembre de 2024 y reproducible en Swift 6.3.1 sobre macOS 26 — tanto en debug como en release.

Lo curioso es que el camino feliz no toca nunca este bug. Si la comparación pasa, no hay mensaje de error que formatear, no hay Mirror, no hay SIGBUS. El bug solo aparece justo cuando más necesitas el output del test: cuando algo falla. Y no podía mover una pieza hasta resolverlo.

Mi Solución 🧩

La pista clave es dónde crashea swift-testing: en el camino del failure message, formateando los valores. Si yo hago la comparación por mi cuenta y le paso al reporter solamente un Bool, swift-testing no tiene nada que reconstruir. No hay metadata que reflejar. El espejo no se rompe porque no se llega a usar.

El truco que evita el SIGBUS cabe en dos líneas:

let isEqual = actual == expected
#expect(isEqual)

Esa es toda la idea. La igualdad la calculo yo, swift-testing solo recibe un Bool ya resuelto. Sin valores que reflejar, no hay Mirror, no hay SIGBUS. El precio es perder los valores en el mensaje de fallo — pero eso lo recupero formateando el texto a mano antes de pasarlo a Issue.record.

A partir de ahí monté un paquete TestKit con tres helpers que aplican esa misma idea para los tres casos en los que tropezaba con el bug:

expectEqual(actual, expected) — comparación de cualquier Equatable: structs, modelos, enums con valores asociados. Sustituye a #expect(a == b) en todos los tests del monorepo.
expectThrows(E.self) { … } — verifica que un closure lanza un error del tipo esperado. Hace do/catch a mano y comprueba con catch is E — solo el tipo, nunca el valor. Cubre lo que #expect(throws:) intentaba dar de serie. Tiene overload sync y async.
expectEqualLines(actual, expected) — diff línea a línea para verificar SQL generado y otros snapshots inline. La comparación también se reduce a Bool antes de tocar el reporter.

Tres helpers, una sola idea: calcular el resultado fuera del macro, pasar solo el booleano. Cuando algún día Swift 6.4 cierre el issue 76608, basta con sustituir el cuerpo de los helpers por #expect directos y la suite ni se entera.

Hay un detalle adicional para que los mensajes de fallo sigan siendo legibles: conformé los tipos de error y schema a CustomStringConvertible con un switch estático sobre los casos — nunca interpolando (self), porque eso volvería a invocar Mirror y reabriría la trampa.

Mi Resultado 🎯

Mi suite de tests vuelve a correr sin SIGBUS y con mensajes de error suficientemente legibles. La regla que aplico ahora en todo el monorepo:

expectEqual(a, b) para cualquier comparación entre structs, enums o modelos
expectThrows(E.self) { … } para verificar el tipo de error lanzado
#expect(…) directo solo cuando el argumento ya es Bool, nil o contains — ahí no hay metadata de valores que reflejar y el bug no se dispara

Los beneficios:

Suite que no crashea — los fallos cuentan como fallos, no como abortos del proceso
Stack mínimo — solo dependo de Testing y del propio toolchain de Swift
Mensajes propios — controlo cómo se imprime cada lado al fallar, gracias a CustomStringConvertible
Aislamiento del bug del runtime — cuando Swift 6.4 lo solucione, basta con cambiar el cuerpo de los helpers y la suite ni se entera

La lección que me llevo: cuando una herramienta del runtime se rompe en el camino del error, la solución no es renunciar al lenguaje, es no dejar que la herramienta entre por ese camino. Hago yo la comparación, le paso un booleano al reporter, y el mirror se queda intacto.

Keep coding, keep running 🏃‍♂️

Two Bigs

2026-04-22T00:00:00Z

Mi Problema 🤔

Consumo mucho contenido técnico. Podcasts, directos, newsletters, artículos. Y con el tiempo he desarrollado un filtro que no puedo desactivar: detecto en los primeros treinta segundos si la persona que habla siente pasión por lo que está contando o simplemente está repitiendo lo que ha leído.

Y la mayoría de las veces es lo segundo.

No hablo de calidad técnica. Hay contenido bien producido, bien estructurado, con buenos títulos, que me aburre profundamente. Porque detrás no hay nadie que se emocione con lo que dice. Es contenido fabricado para existir, no porque alguien necesitara contarlo.

Cuando no hay pasión, pierdo el interés en menos de un minuto. Me da igual lo relevante que sea el tema. Si quien habla no vibra con lo que cuenta, yo tampoco. Y no es una decisión consciente — es una reacción física. Mi cerebro desconecta y ya no hay forma de volver.

Mi Solución 🧩

Siempre estoy en búsqueda activa de contenido dentro de mis temas de interés. Tecnología, desarrollo, IA, Apple, etc… Y siempre doy una oportunidad a lo que encuentro, porque sé lo que cuesta crear. Detrás de cada vídeo, cada podcast, cada artículo hay horas de trabajo, de preparación, de decisiones. Eso merece al menos un intento honesto por mi parte.

Pero no tengo todo el tiempo del mundo, así que de manera natural he acabado aplicando tres filtros.

Pasión. Si en los primeros segundos no noto que a quien habla le importa lo que está contando, mi atención se apaga sola. Sin pasión no hay atención.
Educación y respeto. Quiero aprender de alguien que argumenta sin atacar y discrepa sin despreciar. La pasión sin respeto es ruido.
Satisfacción. Que al terminar sienta que me llevo algo. Una idea nueva, una perspectiva que no tenía. Si no, no vuelvo.

Mi Resultado 🎯

Estos filtros me han ido dejando una lista corta de favoritos. Y en esa lista están Julio César Fernández y Oliver Nabani.

Cuando los astros se juntan y estos dos salen en un directo Un futuro sin apps, me pasa algo que no me pasa con nadie más. Disfruto como un niño. Me río a carcajadas. Les hablo a la pantalla. Rebobino para apuntarme en papel algo que han dicho de pasada y que quiero investigar después. Me estoy meando pero no paro la reproducción porque no quiero perderme ni una frase.

Y siempre, siempre, al terminar pienso lo mismo: “pero si solo han estado quince minutos, cada vez los hacen más cortos”. Miro el reloj. Casi tres horas. No me he enterado de que pasaba el tiempo.

Eso es pasión. Eso es lo que busco. Eso es lo que estos dos transmiten cada vez que se ponen delante de una cámara juntos.

Dos grandes. Dos pasiones. Dos amigos. Y los demás somos sus invitados.

Keep coding, keep running 🏃‍♂️

Astro to Saga

2026-04-15T00:00:00Z

Mi Problema 🤔

Mi portfolio funcionaba sobre Astro con Bun. Todo iba bien. Rápido, cómodo, sin quejas técnicas.

Pero había algo que no encajaba. Cada vez que abría el proyecto me encontraba con un package.json, un tailwind.config, un astro.config, y una carpeta node_modules con cientos de dependencias que ni sabía que existían. Esa sensación de perder el control sobre lo que hay dentro de tu propio proyecto me incomoda. Me gusta saber qué ejecuta mi código y por qué está ahí. Ya había eliminado Tailwind en una migración previa a vanilla CSS, pero el resto del ecosistema JavaScript seguía ahí.

Y al final, soy desarrollador Swift. Mi día a día es Swift. Y sin embargo, para generar mi propio portfolio dependía de un ecosistema completamente ajeno. Si alguien entraba en mi repositorio, no veía a un desarrollador Swift. Veía un proyecto JavaScript más.

La pregunta era sencilla: si confío en Swift para todo lo demás, ¿por qué no confío en Swift para esto?

Mi Solución 🧩

Me paré a pensar qué necesitaba realmente. Mi portfolio no es una aplicación web. No tiene estado ni interactividad compleja. Es un conjunto de páginas HTML estáticas generadas a partir de Markdown. No necesito React, ni Vue, ni hidratación. Necesito algo que lea Markdown, lo transforme en HTML y lo escriba en disco.

Encontré Saga, un generador de sitios estáticos en Swift. Deliberadamente minimalista: lee archivos, aplica transformaciones, escribe HTML. Lo que no incluye, lo decides tú. Además incluye hot reload para desarrollo, algo que no esperaba encontrar en un proyecto tan pequeño. Esa filosofía me convenció más que cualquier feature list.

Ventajas	Desventajas
Todo el stack en Swift — un solo lenguaje, sin cambio de contexto	Ecosistema pequeño — si algo no existe, lo construyes tú
HTML verificado por el compilador gracias al DSL tipado	Curva de aprendizaje con la sintaxis del DSL
Pipeline de imágenes nativo sin dependencias externas	Pipeline de imágenes solo funciona en macOS
Node eliminado del entorno local	Comunidad y documentación limitadas
Control total sobre cada dependencia del proyecto	Más trabajo inicial para funcionalidades que en otros frameworks vienen de serie

La reflexión de fondo

La decisión no fue técnica. Fue sobre coherencia. Quiero que si alguien visita mi repositorio, vea Swift. No digo que Astro sea malo — es excelente. Pero mi portfolio es mi tarjeta de presentación, y esa tarjeta tiene que hablar de mí.

Mi Resultado 🎯

El sitio que lees ahora mismo está generado con Saga, compilado con Swift, y desplegado sobre Cloudflare Pages sin que Node haya intervenido en mi máquina.

Lo que me sorprendió no fue el resultado técnico. Fue la sensación de coherencia. Abrir mi portfolio y ver que todo, desde la primera línea hasta el último deploy, es Swift me produce una tranquilidad difícil de explicar.

Si eres desarrollador Swift y tu portfolio corre sobre Node, no digo que debas cambiar. Digo que merece la pena preguntarse por qué. Al final, la herramienta que eliges para presentarte dice algo sobre ti. Yo elegí la que me representa.

Keep coding, keep running 🏃‍♂️

OnlyDNS

2026-04-08T00:00:00Z

Mi Problema 🤔

En el artículo anterior hablé de cómo La Liga bloqueaba mi web durante los partidos. Gente intentando visitar mi portfolio y mi blog se encontraba con que la página no cargaba, simplemente porque mi dominio pasaba por la infraestructura de Cloudflare, y La Liga bloqueaba rangos enteros de IPs de Cloudflare para frenar las retransmisiones ilegales.

Lo sabía. Lo documenté. Y me quedé ahí.

Durante meses no hice nada para solucionarlo. No por pereza ni por pensar que fuese complicado — sino por enfado. Mi web funcionaba perfectamente, era La Liga la que aplicaba bloqueos indiscriminados y la dejaba inaccesible. No era culpa mía. Así que me planté: no tenía por qué ser yo quien moviese ficha.

Así que no hice nada. Durante meses.

Lo que pasa es que tenía el proxy de Cloudflare activo — la famosa nube naranja. Mi web está alojada en Cloudflare Pages, así que todo está dentro del ecosistema de Cloudflare. Pero con el proxy activado, el tráfico pasa por la capa de CDN/proxy de Cloudflare, que usa unos rangos de IPs compartidas. Y esos rangos son precisamente los que La Liga bloqueaba.

Mi Solución 🧩

La solución es desactivar el proxy de Cloudflare y pasar al modo Solo DNS — la nube gris.

Con la nube naranja activa, Cloudflare es un “centro comercial”: todos los visitantes entran por la puerta de su proxy/CDN, que usa rangos de IPs compartidas con miles de sitios. Son esas IPs las que La Liga bloquea en masa para frenar las retransmisiones ilegales — y mi web queda como daño colateral.

Con la nube gris, Cloudflare pasa a ser solo un “director de tráfico”: resuelve el DNS y apunta directamente a Cloudflare Pages. Mi web sigue alojada en Cloudflare, pero el tráfico llega a través de los rangos de IPs de Pages — que son distintos a los del proxy y que La Liga no tiene en su lista de bloqueo.

El proceso en el panel de Cloudflare es este:

Entrar en el panel de Cloudflare y navegar a DNS > Registros (Records).
Buscar los registros que apuntan a la web — normalmente un registro A o CNAME con el nombre del dominio.
En la columna Estado del proxy, hacer clic en el interruptor con la nube naranja para convertirla en una nube gris (Solo DNS).
Guardar los cambios.

El cambio propaga en minutos. A partir de ese momento, el tráfico llega por una ruta distinta dentro de Cloudflare — una que no está en el punto de mira de los bloqueos de La Liga.

Como mi web es estática y sigue alojada en Cloudflare Pages, no noto prácticamente ninguna diferencia de velocidad. Pierdo algunas funciones de la capa proxy — como el firewall a nivel de CDN o la caché en sus edge nodes — pero para una web estática de portfolio esas ventajas son marginales comparadas con el beneficio de que la web funcione para todo el mundo durante los partidos.

Mi Resultado 🎯

Mi web ya carga durante los partidos de La Liga. Cualquier persona que intente visitar mi portfolio o blog mientras suena el himno de la Champions no se va a encontrar con una pantalla en blanco.

Cinco minutos. Un clic. Meses de problema resuelto.

La lección que me llevo no es técnica — es pragmática. Tuviese razón o no, mi problema o lo solucionaba yo o no lo iba a solucionar nadie. Y creo que tengo razón: mi web no tiene por qué ser daño colateral de los bloqueos de La Liga. Gracias, La Liga.

Keep coding, keep running 🏃‍♂️

My First Macro

2026-04-01T00:00:00Z

Mi Problema 🤔

En mi proyecto tengo decenas de modelos Fluent, y hay un bloque de código que se me repite en absolutamente todos ellos:

public static let space: String? = "sales"

@ID() public var id: UUID?
public init() {}

@Timestamp(.createdAt, on: .create) public var createdAt: Date?
@Timestamp(.updatedAt, on: .update) public var updatedAt: Date?
@Timestamp(.deletedAt, on: .delete) public var deletedAt: Date?

Siempre el mismo bloque. En cada modelo. Sin excepción.

El espacio de nombres cambia, pero la estructura es idéntica. Con cada modelo nuevo, copio y pego, ajusto el espacio y espero no olvidarme de nada. Con 30 modelos, ese boilerplate se convierte en ruido que me dificulta leer lo que realmente importa: la lógica del modelo.

Mi solución en Swift para este tipo de problemas es una macro.

Mi Solución 🧩

Una macro de Swift puede generar miembros nuevos en una clase o struct en tiempo de compilación. Exactamente lo que necesito. El resultado que busco es escribir esto:

@FluentModel(.sales)
public final class ProductModel: Model {
    public static let schema = "products"

    @Field(.name) public var name: String
}

Y que el compilador inyecte automáticamente space, id, init() y los tres timestamps. Sin escribirlos. Sin mantenerlos.

Estructura del paquete

Las macros en Swift requieren dos targets separados: la interfaz pública (lo que consumo como desarrollador) y el plugin (la implementación que ejecuta el compilador). En mi caso, ambos viven en el mismo paquete Macros:

Macros — declara la macro y el enum DatabaseSpace
MacrosPlugin — implementa la expansión con SwiftSyntax

DatabaseSpace — los espacios como tipos

Antes de definir la macro, necesito modelar los espacios de nombres disponibles. En lugar de usar strings sueltos, decidí que el enum DatabaseSpace los haga exhaustivos y seguros en tiempo de compilación:

public enum DatabaseSpace: String, CaseIterable, Sendable {
    case sales, warehouse
}

Esto permite escribir @FluentModel(.sales) en lugar de @FluentModel(“sales”). Si el espacio no existe, el compilador lo dice antes de ejecutar nada.

La declaración del macro

La interfaz pública de la macro es sorprendentemente compacta:

@attached(member, names: named(space), named(id), named(init), named(createdAt), named(updatedAt), named(deletedAt))
public macro FluentModel(_ space: DatabaseSpace? = nil) = #externalMacro(
    module: "MacrosPlugin",
    type: "FluentModelMacro"
)

El atributo @attached(member, names:) le dice al compilador dos cosas: que esta macro añade miembros a la declaración donde se aplica, y cuáles son los nombres exactos que va a generar. Declarar los nombres es obligatorio — Swift los necesita para resolver el árbol de símbolos antes de expandir la macro.

La implementación — FluentModelMacro

La implementación conforma el protocolo MemberMacro y devuelve un array de DeclSyntax — fragmentos de código Swift que el compilador inserta en el modelo:

import SwiftSyntax
import SwiftSyntaxMacros

public struct FluentModelMacro: MemberMacro {
    public static func expansion(
        of node: AttributeSyntax,
        providingMembersOf declaration: some DeclGroupSyntax,
        conformingTo protocols: [TypeSyntax],
        in context: some MacroExpansionContext
    ) throws -> [DeclSyntax] {
        [
            spaceDecl(from: node),
            "@ID() public var id: UUID?",
            "public init() {}",
            "@Timestamp(.createdAt, on: .create) public var createdAt: Date?",
            "@Timestamp(.updatedAt, on: .update) public var updatedAt: Date?",
            "@Timestamp(.deletedAt, on: .delete) public var deletedAt: Date?",
        ]
    }

    private static func spaceDecl(from node: AttributeSyntax) -> DeclSyntax {
        let value = node.arguments?.as(LabeledExprListSyntax.self)?
            .first?.expression.as(MemberAccessExprSyntax.self)
            .map { "\"\($0.declName.baseName.text)\"" } ?? "nil"
        return "public static let space: String? = \(raw: value)"
    }
}

El método expansion devuelve directamente el array de declaraciones, sin variables intermedias. Cada elemento es código Swift literal que el compilador inyecta tal cual en el modelo.

La clave está en spaceDecl, que encapsula toda la lógica de extracción y generación en un solo método. Navega el árbol sintáctico del atributo con SwiftSyntax usando optional chaining: accede a los argumentos como LabeledExprListSyntax, toma la primera expresión, la castea a MemberAccessExprSyntax (porque el argumento es un caso de enum como .sales) y con .map lo convierte en un string entrecomillado. Si cualquier paso de la cadena falla, el operador ?? devuelve “nil”. Finalmente, \(raw:) interpola el valor directamente en el DeclSyntax.

Por último, necesito un CompilerPlugin que registre la macro — es el punto de entrada que el compilador carga para saber qué macros están disponibles:

import SwiftCompilerPlugin
import SwiftSyntaxMacros

@main
struct MacrosPlugin: CompilerPlugin {
    let providingMacros: [Macro.Type] = [
        FluentModelMacro.self,
    ]
}

Mi Resultado 🎯

Con la macro instalada, cada modelo queda limpio y sin ruido:

@FluentModel(.sales)
public final class ProductModel: Model {
    public static let schema = "products"

    @Field(.name) public var name: String
    @OptionalField(.description) public var description: String?
}

El compilador expande @FluentModel(.sales) y genera automáticamente:

public static let space: String? = "sales"
@ID() public var id: UUID?
public init() {}
@Timestamp(.createdAt, on: .create) public var createdAt: Date?
@Timestamp(.updatedAt, on: .update) public var updatedAt: Date?
@Timestamp(.deletedAt, on: .delete) public var deletedAt: Date?

Y si un modelo no pertenece a ningún espacio de nombres — como las vistas — simplemente se omite el argumento:

@FluentModel()
public final class OrderSummaryModel: Model {
    public static let schema = "order_summaries"
}

En ese caso, space se genera como nil y Fluent ignora el prefijo de esquema.

Los beneficios en números: 32 modelos con la macro aplicada. 6 líneas eliminadas por modelo. Más de 190 líneas de boilerplate que ya no existen en el repositorio y que nunca más habrá que mantener.

Keep coding, keep running 🏃‍♂️

DB Admin vs Dev

2026-03-23T00:00:00Z

El problema 🤔

En muchos proyectos he visto cómo el código de la aplicación termina haciendo cosas que no le corresponden: crear roles, configurar parámetros del servidor de base de datos, gestionar permisos a nivel de instancia. Todo mezclado en el mismo sitio, como si fuera una sola responsabilidad.

Pero no lo es. La base de datos tiene dos mundos distintos: la administración 🛡️ y el desarrollo 💻.

Mezclarlos es uno de los errores más comunes, y también uno de los más costosos 💸. Un desarrollador que configura la instancia desde su código está cruzando una frontera que no le corresponde. Y un administrador que intenta decidir qué tablas o esquemas usa la aplicación está haciendo lo mismo desde el otro lado.

La idea 🧩

La separación es conceptualmente limpia: la administración pertenece al servidor, el desarrollo pertenece al código.

El territorio del administrador 🛡️

El administrador gestiona la instancia de la base de datos. Su trabajo incluye:

🔧 Configuración del servidor — parámetros de rendimiento, extensiones a nivel de instancia, ajustes que requieren reinicio
👤 Roles y credenciales — crear usuarios, asignar contraseñas seguras, definir quién puede conectarse
🗄️ Bases de datos — crearlas, establecer timeouts, revocar accesos por defecto

Todo esto es infraestructura 🔐. Son decisiones que se toman una vez, las ejecuta alguien con permisos de superusuario, y no tienen nada que ver con la lógica de negocio. Lo ideal es que vivan como scripts SQL versionados en el repositorio, pero separados del código de la aplicación.

El territorio del desarrollador 💻

El desarrollador gestiona la estructura de datos de la aplicación: esquemas, tablas, índices, vistas, y todo lo que necesita existir para que la aplicación funcione.

Esta responsabilidad se expresa a través de migraciones ✨ — piezas de código versionadas, reversibles y revisables como cualquier otro cambio. Da igual si usas Swift, Python, Go o TypeScript: el principio es el mismo. La estructura de datos de tu aplicación debe poder reproducirse automáticamente en cualquier entorno 🔄.

La zona gris: ¿admin o desarrollo? 🤷

Hay casos que parecen ambiguos. Los roles de base de datos son un buen ejemplo. El rol en sí — con su contraseña y permisos de conexión — es un concepto de infraestructura. Lo crea el administrador 🛡️.

Pero los permisos sobre tablas concretas — qué puede leer, qué puede escribir, sobre qué esquema — eso depende del desarrollador 💻. La tabla tiene que existir antes de que pueda tener permisos, así que esos permisos van en las migraciones, no en scripts de infraestructura.

La regla que yo aplico es sencilla: si el objeto existe antes que la aplicación, es administración. Si su existencia depende de que la aplicación lo cree, es desarrollo ✅.

El resultado 🎯

Cuando aplicas esta separación, el proceso de puesta en marcha queda claro y reproducible:

🛡️ El administrador prepara la instancia → servidor configurado, roles creados, base de datos lista
💻 El desarrollador ejecuta las migraciones → esquemas, tablas y permisos de aplicación aplicados automáticamente

Cada capa tiene su herramienta. El administrador no toca el código de la aplicación. El desarrollador no necesita credenciales de superusuario 🔒. Nadie pisa el territorio del otro.

Esta separación también facilita el trabajo en equipo 🤝: los scripts de administración los ejecuta quien tiene acceso al servidor, una sola vez. Las migraciones las ejecuta cualquier desarrollador del equipo en su entorno local, tantas veces como necesite.

La base de datos no es solo tuya como desarrollador. Pero la estructura de datos de tu aplicación, sí. 🏗️

Keep coding, keep running 🏃‍♂️

Migrate Spaces

2026-03-14T00:00:00Z

🧩 Problema

En el artículo anterior sobre Esquemas y Espacios vimos cómo asignar un espacio de nombres a un modelo usando la propiedad space. Muchos me preguntasteis lo mismo: ¿cómo se crean esos espacios en la base de datos? 🤔

La respuesta más habitual era hacerlo a mano, ejecutando un CREATE SCHEMA en la consola de PostgreSQL antes de lanzar las migraciones. Funciona, pero rompe algo fundamental: si la base de datos no existe o el entorno es nuevo, el proceso falla antes de llegar a las migraciones reales 💥.

El otro problema es que administrar espacios de nombres a mano no escala. En cuanto tienes varios entornos (desarrollo, staging, producción) o un equipo, mantener esa sincronía manual se convierte en una fuente de errores silenciosos 😬.

💡 Solución

La solución es convertir la creación de espacios de nombres en una migración más. De esta forma, se ejecuta automáticamente en el orden correcto, es reversible y está versionada junto al resto del código ✅.

La clave está en combinar FluentKit con SQLKit. FluentKit gestiona el ciclo de vida de las migraciones, pero para ejecutar SQL arbitrario necesitamos acceder al driver subyacente mediante el protocolo SQLDatabase. Para mantener el código organizado, encapsulamos los espacios de nombres en un enum con una acción que determina si se crean o se eliminan:

import FluentKit
import SQLKit

enum SRSchema: String, CaseIterable {
    case account, ai, device, location, sport, task, view

    enum Action {
        case create, drop
    }

    static func execute(_ action: Action, on db: Database) async throws {
        let sql = db as! any SQLDatabase
        let template: (String) -> String =
            switch action {
            case .create: { "CREATE SCHEMA IF NOT EXISTS \($0)" }
            case .drop: { "DROP SCHEMA IF EXISTS \($0) RESTRICT" }
            }
        for schema in allCases {
            try await sql.raw("\(unsafeRaw: template(schema.rawValue))").run()
        }
    }
}

struct SchemasMigration: AsyncMigration {
    func prepare(on db: Database) async throws {
        try await SRSchema.execute(.create, on: db)
    }

    func revert(on db: Database) async throws {
        try await SRSchema.execute(.drop, on: db)
    }
}

Algunos detalles importantes 📋:

SRSchema como CaseIterable: al iterar sobre allCases, nos aseguramos de que todos los espacios definidos se crean sin tener que listarlos manualmente en la migración. Añadir un nuevo espacio solo requiere agregar un caso al enum 🔄.
Action: el enum interno modela las dos operaciones posibles (create y drop), lo que permite reutilizar el mismo método execute tanto en el prepare como en el revert de la migración ♻️.
Switch expression: se usa una switch expression de Swift para seleccionar el template SQL según la acción. Cada rama devuelve un closure que genera la sentencia correspondiente, manteniendo la lógica compacta y legible 🧹.
CREATE SCHEMA IF NOT EXISTS: hace que la migración sea idempotente. Si el esquema ya existe, no falla, simplemente continúa 🛡️.
DROP SCHEMA … RESTRICT: en el revert, el modificador RESTRICT impide eliminar un esquema que contenga tablas. Es una red de seguridad que evita pérdidas accidentales de datos al revertir 🔒.
unsafeRaw: se usa para interpolar el nombre del schema directamente en el SQL. Es seguro aquí porque el valor proviene de un enum propio, nunca de input externo ⚠️.

📊 Resultado

Esta migración debe ser la primera en registrarse ☝️. Antes de crear cualquier tabla, los espacios de nombres tienen que existir. En el runner de migraciones, el orden queda así:

fluent.migrations.add(
    SchemasMigration()
)

Al ejecutar las migraciones en un entorno nuevo, el proceso completo es automático ⚡:

Y si en algún momento necesitas añadir un nuevo dominio, solo añades el caso al enum SRSchema y la próxima vez que se ejecuten las migraciones, el esquema aparece. Sin tocar la base de datos a mano, sin documentación extra que mantener 🎯.

Keep coding, keep running 🏃‍♂️

Tailwind to CSS

2026-03-07T00:00:00Z

🎨 ¿Por Qué Tocar Lo Que Funciona?

Mi portfolio llevaba meses funcionando perfectamente con Tailwind CSS. Todo iba bien. Los estilos estaban en su sitio, los componentes se veían geniales y la web cargaba rápido.

Entonces, ¿por qué cambiar?

Porque funcionar bien y funcionar de la mejor manera posible son cosas distintas. Y cuando te paras a analizar qué hay debajo del capó, a veces descubres que llevas una capa que no necesitas 🧅.

🤔 El Problema con Tailwind (en mi caso)

No me malinterpretéis: Tailwind CSS es una herramienta brutal. Lo he usado en proyectos profesionales y lo seguiré usando donde tenga sentido. Pero en un portfolio personal con Astro, empecé a notar ciertas cosas:

Dependencia innecesaria: 3 paquetes extra (tailwindcss, @tailwindcss/vite, @tailwindcss/typography) para un proyecto que no los necesitaba realmente 📦
Capa de abstracción: Tailwind genera CSS a partir de clases de utilidad. Es una capa entre lo que escribes y lo que el navegador interpreta. En un proyecto pequeño, esa capa suma sin aportar 🧱
Peso extra: El CSS generado incluía utilidades que no siempre aprovechaba al máximo. ~20KB de más que el usuario descargaba sin necesidad 📊
Menor control: Cuando quieres algo muy específico, acabas luchando contra el framework en vez de escribir directamente lo que necesitas ⚔️

💡 La Decisión: Vanilla CSS con Design Tokens

La idea era sencilla: eliminar Tailwind y sustituirlo por CSS vanilla con un sistema de design tokens usando custom properties de CSS.

¿Qué son los design tokens? Son variables CSS que definen tu sistema de diseño:

:root {
  --color-primary: oklch(0.55 0.2 260);
  --color-gray-100: oklch(0.97 0 0);
  --color-gray-900: oklch(0.21 0.006 285.75);

  --text-sm: 0.875rem;
  --text-base: 1rem;
  --text-xl: 1.25rem;

  --spacing: 0.25rem;
  --radius-lg: 0.5rem;

  --shadow-md: 0 4px 6px -1px rgb(0 0 0 / 0.1);
  --transition-colors: color 0.15s, background-color 0.15s, border-color 0.15s;
}

Con esto tienes consistencia en todo el proyecto sin depender de ningún framework. Solo CSS puro que el navegador entiende directamente 🎯.

🔧 La Migración

El proceso fue migrar 38 archivos en un solo commit. Cada componente Astro pasó de usar clases de Tailwind a tener su propio bloque <style> con estilos scoped:

Antes (Tailwind):

<header class="flex items-center justify-between px-6 py-4 bg-white dark:bg-gray-900">
  <nav class="flex gap-4">
    <a class="text-sm font-medium text-gray-700 hover:text-blue-500">Blog</a>
  </nav>
</header>

Después (Vanilla CSS):

<header class="header">
  <nav class="nav">
    <a class="nav-link">Blog</a>
  </nav>
</header>

<style>
  .header {
    display: flex;
    align-items: center;
    justify-content: space-between;
    padding: calc(var(--spacing) * 4) calc(var(--spacing) * 6);
    background-color: var(--color-white);
  }

  :global(.dark) .header {
    background-color: var(--color-gray-900);
  }

  .nav {
    display: flex;
    gap: calc(var(--spacing) * 4);
  }

  .nav-link {
    font-size: var(--text-sm);
    font-weight: 500;
    color: var(--color-gray-700);
    transition: var(--transition-colors);
  }

  .nav-link:hover {
    color: var(--color-blue-500);
  }
</style>

¿Más líneas? Sí. ¿Más claro y mantenible? Absolutamente ✅.

📚 Lo Que Aprendí por el Camino

La migración no fue solo “quitar Tailwind y poner CSS”. Hubo trampas interesantes que vale la pena compartir:

Estilos scoped y <slot>

En Astro, los estilos dentro de <style> son scoped por defecto. Esto significa que cada componente recibe un atributo único (data-astro-cid-*) y los estilos solo afectan a ese componente.

El problema: el contenido que llega por <slot> no recibe ese atributo. Si un componente padre intenta estilizar lo que viene por slot, los estilos no se aplican 😱.

La solución: usar :global() para los selectores que afectan a contenido slotted:

.container :global(a) {
  color: var(--color-primary);
  text-decoration: underline;
}

opacity vs transparencia de fondo

Con Tailwind usaba clases como bg-opacity-70. Al migrar, el primer instinto fue usar la propiedad opacity. Error: opacity afecta al elemento entero, incluidos sus hijos 👶.

La solución correcta: color-mix() para transparencia solo en el fondo:

.modal-overlay {
  /* MAL: afecta a todo */
  opacity: 0.7;

  /* BIEN: solo el fondo es transparente */
  background-color: color-mix(in oklab, var(--color-gray-900) 70%, transparent);
}

📊 Los Resultados

Los números hablan por sí solos:

~20KB menos de CSS entregado al navegador 📉
3 dependencias eliminadas del package.json 🗑️
0 capas de abstracción entre tu código y el navegador 🎯
Build más rápido al no necesitar el procesamiento de Tailwind ⚡
Control total sobre cada línea de CSS que se genera 🎛️

El package.json pasó de tener tailwindcss, @tailwindcss/vite y @tailwindcss/typography a no tener ninguna dependencia de estilos. Solo CSS puro.

Y lo mejor: se eliminó el archivo tailwind.config.mjs por completo. Una configuración menos que mantener 🧹.

🏗️ La Arquitectura Final

El sistema de estilos quedó organizado en 4 archivos CSS:

Archivo	Responsabilidad
design-tokens.css	Colores, tipografía, espaciado, sombras, transiciones
base-reset.css	Reset CSS mínimo y utilidades como .sr-only
prose.css	Tipografía para contenido del blog con soporte dark mode
layout.css	Clases de layout globales (.bodyLayout, .mainLayout)

Todo importado desde un único global.css. Limpio, predecible y sin magia negra 🧙‍♂️.

💭 Reflexión Final

Migrar de Tailwind CSS a vanilla CSS no es para todos ni para todos los proyectos. En equipos grandes o proyectos con muchos desarrolladores, Tailwind sigue siendo una opción fantástica por su consistencia y velocidad de desarrollo.

Pero en un proyecto personal como un portfolio con Astro, donde el rendimiento importa y el control total es un lujo que puedes permitirte, quitarte esa capa de abstracción es liberador 🕊️. De hecho, acabé llevando esta filosofía aún más lejos y migré todo el portfolio de Astro a Swift — cuento la historia completa en Astro to Saga.

Es como pintar un cuadro: puedes usar plantillas y herramientas que te guíen, o puedes coger el pincel y crear exactamente lo que tienes en mente. Ambas opciones son válidas. Pero cuando el lienzo es tuyo, pintar a mano tiene su encanto 🎨.

Keep coding, keep running 🏃‍♂️

Cupertino MCP

2026-02-11T00:00:00Z

🍎 El Problema de la Documentación de Apple

Si desarrollas para iOS, macOS o cualquier plataforma de Apple, conoces el drill perfecto:

Estás programando tranquilamente 💻
Necesitas consultar cómo funciona algo en SwiftUI 🤔
Abres Safari / tu navegador favorito 🌐
Buscas en Google / DuckDuckGo 🔍
Entras a la documentación oficial de Apple 📚
Lees, entiendes, vuelves a tu IDE 🔄
Repites el proceso 47 veces al día 😵

O peor aún: le preguntas a tu IA favorita y te da información desactualizada o directamente alucinada porque su conocimiento no está actualizado con las últimas versiones de Swift o SwiftUI 🤖❌.

¿Y si te dijera que hay una forma mejor?

💡 Cupertino MCP: La Solución

Cupertino MCP es una herramienta que indexa localmente toda la documentación de Apple y la pone disponible para tu IA mediante el Model Context Protocol (MCP).

Traducido a cristiano: es como darle a tu IA (Claude, en mi caso) un acceso directo y verificado a toda la documentación oficial de Apple 🎯.

¿Cuánta documentación estamos hablando?

📄 302,424+ páginas de documentación oficial

🧰 307 frameworks indexados

📦 9,699 paquetes Swift catalogados

💾 606 proyectos de código de ejemplo de Apple

📱 Human Interface Guidelines completas

📖 Swift Evolution proposals (~400 propuestas)

🏛️ Apple Archive guides (documentación legacy pero valiosa)

Todo esto, disponible offline, sin necesidad de internet, y sin riesgo de alucinaciones de la IA 🛡️.

🎯 Precisión Absoluta

Cuando Claude me responde sobre APIs de Apple, ya no adivina. Busca en la documentación oficial real y me da información 100% verificada.

Nada de: “Creo que en SwiftUI 6 se usa así…” ❌

Ahora es: “Según la documentación oficial de SwiftUI 6…” ✅

⚡ Velocidad de Desarrollo

Antes:

Pregunta → Espera respuesta → Duda → Abrir Safari →
Buscar en Google → Leer docs → Volver al IDE → Implementar

Ahora:

Pregunta → Respuesta con documentación oficial → Implementar

Ahorro brutal de tiempo en cada consulta 🏎️.

📊 Búsqueda Súper Potente

Cupertino usa SQLite FTS5 con ranking BM25. En cristiano: búsquedas ultra-rápidas (menos de 100ms) con resultados relevantes ordenados por importancia.

Puedes filtrar por:

Framework específico 🧰
Versión de plataforma (iOS 17, macOS 14, etc.) 📱
Tipo de documentación (API, ejemplos, guías) 📚
Búsqueda en código de ejemplo 💻

🧠 Aprendizaje Contextualizado

No solo obtengo la API correcta, también obtengo:

Ejemplos de código reales de Apple 📝
Mejores prácticas documentadas 👍
Patrones de diseño oficiales 🎨
Alternativas y deprecaciones ⚠️

Es como tener un mentor de Apple dentro de Claude 🍎🤝🤖.

💭 Reflexión Final

Cupertino MCP es un ejemplo perfecto de cómo las herramientas de IA se vuelven realmente útiles cuando tienen acceso a información verificada y actualizada.

No se trata de darle más poder a la IA para que “adivine mejor”. Se trata de conectarla con fuentes fiables para que te dé respuestas precisas.

Si desarrollas para ecosistemas de Apple, Cupertino MCP es una inversión de 5 minutos (instalación) que te ahorrará horas cada semana. Y si usas Claude Code como yo, la experiencia se vuelve aún mejor 💎.

¿Lo recomiendo? Absolutamente. Es obligatorio si desarrollas con Swift, SwiftUI o cualquier framework de Apple 🍎.

¿Es para todo el mundo? Solo si desarrollas para plataformas Apple. Si trabajas con otras tecnologías, busca herramientas similares (seguro hay equivalentes para Android, web, etc.) 🔍.

Keep coding, keep running 🏃‍♂️

Which AI

2026-02-04T00:00:00Z

🎭 Déjà Vu: Los Frameworks Web 2.0

¿Recuerdan aquella época dorada donde cada semana aparecía un nuevo framework web?

Uno más moderno, más rápido, más potente, más bonito… Uno que venía a “matar” a todos los anteriores y que iba a convertirse en el único framework que necesitarías usar jamás 💀.

Spoiler: ninguno mató a nadie, y ahora tenemos más frameworks que nunca 😂.

Pues bien, bienvenidos a la era de las IAs: el mismo concepto, pero con esteroides 🚀.

📱 La Fatiga de las Notificaciones

Imagina la escena: estás tranquilamente programando con tu IA de confianza, flujo de trabajo perfecto, productividad al máximo… y de repente:

📢 Notificación: ”¡Nueva IA revolucionaria lanzada!”

🎥 Video: “Cómo usarla en 10 minutos”

📝 Tutorial: “Integrala en tu workflow HOY”

💡 Thread: “Por qué deberías cambiarte ahora mismo”

Y aquí viene lo más divertido: el creador de contenido que hace 1 hora tenía un video explicando “Por qué la antigua IA es el futuro”, ahora tiene otro video sobre “Por qué la nueva IA es mejor que todo” 🎪.

No los culpo, eh. Es su trabajo mantenerse actualizados y crear contenido relevante. Pero como consumidor… es agotador 😅.

🏃‍♂️ La Carrera Imposible

Si ya es complicado seguir las actualizaciones diarias de la IA que estás usando (y créeme, son muchísimas actualizaciones), imagínate ponerte a:

Probar cada nueva IA que sale ✅
Aprender su interfaz y peculiaridades 📚
Integrarla en tu workflow 🔧
Compararla con las que ya usas ⚖️
Decidir si vale la pena el cambio 🤔

Resultado: Misión imposible 🎯.

Y no me malinterpreten: me encanta tener opciones. De hecho, es maravilloso que exista tanta competencia e innovación. Más opciones = más mejor 👍🏻.

🚫 Mi Línea Roja

Ahora bien, hay algo en lo que soy tajante:

Jamás usaré una IA que requiera permisos totales desde el principio 🔒.

Nada de “Dame acceso completo a tu máquina y confía en mí”. Eso no va conmigo.

Mi filosofía es clara:

📋 Dime qué vas a hacer (o planifícalo)
👀 Yo reviso los cambios
✅ Yo apruebo (o no apruebo)
🚀 Entonces procedes

No al libre albedrío de la IA con permisos de administrador. Control total es mi mantra, como ya conté en mi artículo sobre Claude Code 💪.

🌐 Ya No Es Solo un Modelo

Y aquí está lo realmente fascinante: la IA ya no es simplemente “un modelo” o “una app” que instalas y usas.

Ahora tenemos ecosistemas completos 🏗️:

Modelos base + fine-tuned ⚙️
Integraciones con IDEs 💻
Plugins y extensiones 🔌
APIs y SDKs 📡
Plataformas de orquestación 🎼
Herramientas especializadas 🛠️

Es increíble la velocidad a la que todo esto está evolucionando. Lo que era ciencia ficción hace 2 años, ahora es tu asistente de código diario 🤖.

🎢 Viviendo una Época Increíble

Al final del día, creo que estamos viviendo algo histórico 🎊:

🥊 Batalla de los IDEs: VSCode vs. Cursor vs. WindSurf vs. Zed vs…

⚔️ Batalla de los Frameworks: React vs. Vue vs. Svelte vs. Solid vs…

🤖 Batalla de las IAs: Claude vs. ChatGPT vs. Gemini vs. Copilot vs…

Es agotador intentar seguirlo todo, lo admito. A mí personalmente me resulta imposible 🙃.

Pero también es emocionante. Cada día hay algo nuevo que aprender, algo que probar, algo que te hace replantear cómo trabajas.

🎯 Reflexión Final

La moraleja de todo esto es simple:

No necesitas usar todo. De verdad, no lo necesitas 🙅‍♂️.

Encuentra las herramientas que funcionen para ti, aprende a usarlas bien, mantente actualizado con sus novedades, y está bien que de vez en cuando explores alternativas.

Pero no te vuelvas loco intentando estar en todas las olas a la vez. Elige tu tabla de surf 🏄‍♂️, aprende a usarla bien, y disfruta del viaje.

Y si un día decides cambiar de tabla, pues adelante. Pero que sea una decisión consciente, no una reacción al FOMO (Fear Of Missing Out) creado por 47 notificaciones simultáneas 😂.

Feliz coding (con la IA que prefieras) 🚀

Keep coding, keep running 🏃‍♂️

Conferences 25

2026-01-28T00:00:00Z

iOSConfSG

📅 15-17 de enero

📍 Singapur, 🇸🇬

🔗 iosconf

🎥 youtube

AppDevCon

📅 18–21 de marzo

📍 Ámsterdam, 🇳🇱

🔗 appdevcon

🎥 videos

Swift Heroes

📅 8–9 de abril

📍 Turín, 🇮🇹

🔗 swiftheroes

🎥 youtube

try! Swift Tokyo

📅 9–11 de abril

📍 Tokio, 🇯🇵

🔗 tryswift

🎥 youtube

Deep Dish Swift

📅 27–29 de abril

📍 Chicago, 🇺🇸

🔗 deepdishswift

🎥 youtube

iOSKonf

📅 13–15 de mayo

📍 Skopje, 🇲🇰

🔗 ioskonf

🎥 youtube

Swift Craft

📅 19–21 de mayo

📍 Kent, 🇬🇧

🔗 swiftcraft

🎥 youtube

WWDC

📅 9–13 de junio

📍 Cupertino, 🇺🇸

🔗 apple

🎥 youtube

NSSpain

📅 17-19 septiembre

📍 Logroño, 🇪🇸

🔗 nsspain

🎥 youtube

Swift Connection

📅 6–7 de octubre

📍 París, 🇫🇷

🔗 swiftconnection

🎥 youtube

SwiftLeeds

📅 7–8 de octubre

📍 Leeds, 🇬🇧

🔗 swiftleeds

🎥 youtube

Pragma Conference

📅 30–31 de octubre

📍 Bolonia, 🇮🇹

🔗 pragmaconference

🎥 youtube

Do iOS

📅 12-13 de noviembre

📍 Amsterdam, 🇳🇱

🔗 do-ios

🎥 youtube

Keep coding, keep running 🏃‍♂️

Async Concurrent Map

2026-01-21T00:00:00Z

Problema

En aplicaciones backend con Vapor, cuando procesamos grandes volúmenes de datos de forma concurrente, nos enfrentamos a un dilema de optimización:

Procesamiento secuencial con asyncMap: garantiza control sobre los recursos, pero es lento al procesar elementos uno a uno.
Procesamiento totalmente concurrente con concurrentMap: maximiza la velocidad, pero puede saturar recursos al lanzar miles de tareas simultáneas.

Por ejemplo, al procesar 10,000 registros con llamadas a APIs externas:

asyncMap: 10,000 llamadas secuenciales → muy lento pero controlado.
concurrentMap: 10,000 llamadas simultáneas → muy rápido pero puede agotar conexiones/memoria.

Necesitamos una solución que combine ambos enfoques: dividir el trabajo en grupos manejables y procesar cada grupo de forma concurrente, equilibrando velocidad y uso de recursos.

Solución

Extendemos Collection con una función que combina chunking (división en grupos) y procesamiento concurrente, permitiendo configurar el tamaño de los grupos y timeout por chunk.

extension Collection where Element: Sendable {
    func asyncConcurrentMap<T: Sendable>(
        chunkSize: Int? = nil,
        timeout: Double? = nil,
        _ transform: @escaping @Sendable (Element) async throws -> T
    ) async throws -> [T] {
        guard let chunkSize else {
            return try await concurrentMap(transform)
        }

        return try await chunks(ofCount: chunkSize)
            .asyncMap(timeout: timeout) {
                try await $0.concurrentMap(transform)
            }.flatMap { $0 }
    }
}

Puntos clave:

Si no se especifica chunkSize, usa concurrentMap puro (procesamiento totalmente concurrente).
Si se especifica chunkSize, divide la colección en grupos con chunks(ofCount:).
Procesa los chunks secuencialmente con asyncMap (con timeout opcional).
Dentro de cada chunk, procesa los elementos concurrentemente con concurrentMap.
Aplana los resultados con flatMap para devolver un array unificado.

Resultado

// Procesar 10,000 registros en chunks de 100
// 100 tareas concurrentes a la vez, 100 veces
let results = try await records.asyncConcurrentMap(
    chunkSize: 100,
    timeout: 30.0
) { record in
    try await apiClient.process(record)
}

Beneficios de esta aproximación:

⚡ Balance perfecto: combina la velocidad del procesamiento concurrente con el control del procesamiento secuencial por chunks.

🎯 Control de recursos: limita la cantidad de tareas simultáneas al tamaño del chunk, evitando saturación.

⏱️ Timeout por chunk: detecta y maneja chunks problemáticos sin bloquear todo el procesamiento.

🔧 Flexibilidad total: usa chunking cuando lo necesites, o procesamiento concurrente puro cuando no.

📊 Escalabilidad: permite procesar millones de registros ajustando el tamaño del chunk según los recursos disponibles.

Si necesitas ejecución paralela pura, lo cubrí en Concurrent Map. Y si tus chunks secuenciales necesitan rate limiting entre ellos, añadí esa capacidad en Async Map Timeout.

Esta solución es la evolución natural de asyncMap y concurrentMap, combinando lo mejor de ambos mundos para optimizar el procesamiento de datos masivos en aplicaciones backend.

Keep coding, keep running 🏃‍♂️

Async Map Timeout

2026-01-14T00:00:00Z

Problema

En el post sobre AsyncMap vimos cómo procesar colecciones de forma secuencial asíncrona. Sin embargo, al trabajar con APIs externas que implementan rate limiting, nos enfrentamos a un problema crítico:

// Procesar 1000 URLs secuencialmente
let results = try await urls.asyncMap { url in
    try await apiClient.fetch(url)  // ⚠️ 1000 llamadas sin pausa
}
// Error 429: Too Many Requests

Realizar llamadas consecutivas sin pausas puede:

Exceder límites de rate: APIs rechazan con 429 Too Many Requests.
Saturar servicios externos: sobrecarga de conexiones simultáneas.
Desperdiciar recursos: forzar reintentos consume más tiempo y ancho de banda.
Bloqueos temporales: algunas APIs bloquean la IP tras múltiples infracciones.

Necesitamos una forma de controlar el ritmo de las operaciones secuenciales, añadiendo pausas intencionales entre cada procesamiento.

Solución

Actualizamos asyncMap añadiendo un parámetro opcional timeout que introduce una pausa configurable después de procesar cada elemento.

extension Sequence {
    func asyncMap<T>(
        timeout: Double? = nil,
        _ transform: (Element) async throws -> T
    ) async throws -> [T] {
        var results = [T]()
        results.reserveCapacity(underestimatedCount)
        for element in self {
            try await results.append(transform(element))
            if let timeout {
                try await Task.sleep(for: .seconds(timeout))
            }
        }
        return results
    }
}

Cambios clave respecto a la versión original:

✨ Parámetro timeout: Double? = nil opcional y retrocompatible.

⏱️ Si se especifica timeout, añade Task.sleep(for: .seconds(timeout)) después de cada elemento.

🔄 Mantiene el comportamiento original cuando no se especifica timeout (sin pausas).

📊 Permite ajustar dinámicamente el rate limiting según los límites de cada API.

Resultado

// Rate limiting: 1 llamada por segundo
let results = try await urls.asyncMap(timeout: 1.0) {
    try await apiClient.fetch($0)
}

// Rate limiting agresivo: 1 llamada cada 5 segundos
let results = try await endpoints.asyncMap(timeout: 5.0) {
    try await scraper.parse($0)
}

// Sin timeout: comportamiento original (máxima velocidad)
let results = try await localFiles.asyncMap {
    try await processFile($0)
}

Beneficios de esta actualización:

⏱️ Rate limiting configurable: controla el ritmo de llamadas según los límites de cada API.

🛡️ Prevención de bloqueos: evita errores 429 y suspensiones temporales de IP.

🔄 Retrocompatibilidad total: sin timeout funciona exactamente igual que antes.

🎯 Flexibilidad por caso de uso: ajusta el timeout según la tolerancia del servicio externo.

📊 Procesamiento predecible: calcula fácilmente el tiempo total (n elementos × timeout).

Esta actualización convierte asyncMap en una herramienta completa para procesamiento secuencial controlado, ideal para integración con APIs que imponen límites de tasa y necesitan un flujo de peticiones regulado.

Keep coding, keep running 🏃‍♂️

Copy To

2026-01-07T00:00:00Z

Problema

En aplicaciones backend con Vapor, a menudo necesitamos exportar grandes volúmenes de datos desde la base de datos a archivos para diferentes propósitos: backups, análisis offline, integración con sistemas externos, o auditorías de datos.

Usar consultas tradicionales con Fluent para luego serializar los resultados manualmente presenta varios inconvenientes:

Alto consumo de memoria: cargar miles de registros en memoria para procesarlos uno a uno.
Procesamiento lento: serialización manual a CSV requiere iterar y formatear cada registro.
Falta de optimización: no aprovecha las capacidades nativas de exportación del motor de base de datos.
Complejidad innecesaria: gestión manual de formatos, escapado de caracteres y manejo de valores nulos.

Para escenarios de exportación masiva, necesitamos una estrategia que aproveche las capacidades nativas de PostgreSQL para generar archivos de forma eficiente.

Solución

Extendemos Database con una función que ejecuta el comando COPY … TO de PostgreSQL, permitiendo exportar datos directamente desde el schema de la tabla a archivos CSV en el sistema de archivos.

extension Database {
    func exportCSV(
        _ model: any Model.Type,
        file: PathEnum)
        async throws {
        let query = SQLQueryString(
            """
            COPY \"\(unsafeRaw: model.space ?? "public")\".
            \"\(unsafeRaw: model.schema)\"
            TO '\(unsafeRaw: file.rawValue)'
            WITH (FORMAT csv, HEADER true, DELIMITER ',',
            QUOTE '"', ESCAPE '"', NULL '')
            """
        )

        try await self.sqlDatabase
            .raw(query).run()
    }
}

Puntos clave:

Usa COPY … TO de PostgreSQL, el método más eficiente para exportación masiva.
El parámetro model.space soporta schemas personalizados (por defecto “public”).
model.schema obtiene automáticamente el nombre de la tabla del modelo Fluent.
Configuración CSV estándar: headers incluidos, delimitadores y manejo correcto de valores nulos.
Utiliza unsafeRaw para interpolación directa en la query SQL.

Resultado

func exportRegions() async throws {
    try await db.exportCSV(
        LocationRegionModel.self, 
        file: file
    )
}

Beneficios de esta aproximación:

🚀 Performance óptimo: COPY … TO es mucho más rápido que serialización manual.

💾 Eficiencia de recursos: PostgreSQL escribe directamente al archivo sin cargar datos en memoria de la aplicación.

📦 Formato consistente: el motor de base de datos garantiza un CSV válido con escapado correcto.

🔧 Integración nativa: aprovecha capacidades optimizadas del motor PostgreSQL.

📊 Escalabilidad: permite exportar millones de registros sin impacto en el rendimiento de la aplicación.

Esta solución es el complemento perfecto para importCSV, formando un par de funciones que permite movimiento bidireccional de datos entre PostgreSQL y el sistema de archivos de forma eficiente y confiable. Si aún no has visto la parte de importación, explico cómo construirla usando COPY FROM de PostgreSQL en Copy From.

Keep coding, keep running 🏃‍♂️

Copy From

2025-12-31T00:00:00Z

Problema

En aplicaciones backend con Vapor, cuando necesitamos insertar grandes volúmenes de datos en la base de datos (migraciones iniciales, importación de catálogos, carga masiva desde APIs externas), usar .save() en un bucle genera múltiples transacciones individuales.

Esto resulta en:

Alta latencia: cada insert abre/cierra conexión y transaction overhead.
Pobre throughput: no aprovecha las capacidades de inserción masiva del motor de base de datos.
Riesgo de timeout: operaciones lentas que pueden fallar en entornos con límites de tiempo.

Para escenarios de importación masiva (miles o millones de registros), necesitamos una estrategia de bulk insert que aproveche las capacidades nativas de PostgreSQL.

Solución

Extendemos Database con una función que ejecuta el comando COPY de PostgreSQL, permitiendo importar archivos CSV directamente desde el sistema de archivos al schema de la tabla.

extension Database {
    func importCSV(
        _ model: any Model.Type,
        file: PathEnum
        ) async throws {
        let query = SQLQueryString(
            """
            COPY \"\(unsafeRaw: model.space ?? "public")\".
            \"\(unsafeRaw: model.schema)\"
            FROM '\(unsafeRaw: file.rawValue)'
            WITH (FORMAT csv, HEADER true, DELIMITER ',',
            QUOTE '"', ESCAPE '"', NULL '')
            """
        )

        try await self.sqlDatabase
            .raw(query).run()
    }
}

Puntos clave:

Usa COPY de PostgreSQL, el método más rápido para bulk insert desde archivos.
El parámetro model.space soporta schemas personalizados (por defecto “public”).
model.schema obtiene automáticamente el nombre de la tabla del modelo Fluent.
Configuración CSV estándar: headers, delimitadores y manejo de valores nulos.
Utiliza unsafeRaw para interpolación directa en la query SQL.

Resultado

private func importRegions() async throws {
    try await db.importCSV(
        RegionModel.self,
        file: .LocationFile("regions", .csv)
    )
}

Beneficios de esta aproximación:

🚀 Performance extremo: COPY es hasta 10-100x más rápido que inserts individuales.

📦 Transacción atómica: toda la importación ocurre en una sola operación, garantizando consistencia.

💾 Eficiencia de recursos: minimiza el uso de memoria y conexiones de base de datos.

🔧 Integración nativa: aprovecha capacidades optimizadas del motor PostgreSQL.

📊 Escalabilidad: permite importar millones de registros sin degradación significativa.

Notas

Esta implementación utiliza COPY … FROM con archivos del sistema. Actualmente existe una issue abierta en Vapor para implementar soporte nativo de COPY … FROM STDIN, que permitiría realizar bulk inserts directamente desde memoria sin necesidad de archivos intermedios.

Estoy vigilando esta issue de manera activa para integrar esta funcionalidad cuando esté disponible, lo que proporcionará una API aún más flexible y eficiente para operaciones de importación masiva.

Si también necesitas la operación inversa — exportar datos de PostgreSQL a archivos CSV — lo cubrí en Copy To.

Keep coding, keep running 🏃‍♂️

Swift Package

2025-12-24T00:00:00Z

El dilema de las dependencias rotas

Cuando trabajas con Swift Package Manager (SPM), eventualmente te encontrarás con un error de compilación que parece no tener sentido. Has intentado compilar varias veces, has reiniciado Xcode, pero el error persiste. La solución muchas veces está en limpiar correctamente las cachés y artefactos de SPM, pero ¿qué comando usar?

Existen múltiples formas de “limpiar” en SPM, cada una con un propósito específico. Usar el comando equivocado puede no resolver tu problema o, peor aún, forzarte a descargar gigabytes de dependencias nuevamente.

Los cuatro caminos para limpiar

SPM ofrece tres comandos oficiales más una alternativa manual. Cada uno afecta diferentes partes del sistema:

Comando	Elimina .build local	Elimina Package.resolved	Elimina caché global
swift package clean	❌ (solo binarios compilados)	❌	❌
swift package reset	✅ (completo)	✅	❌
swift package purge-cache	❌	❌	✅
rm -rf .build	✅ (completo)	❌	❌

Swift package clean

swift package clean

Qué hace:
Elimina únicamente los binarios compilados finales dentro de la carpeta .build, pero mantiene dependencias descargadas y archivos intermedios.

Cuándo usarlo:

Después de cambiar configuraciones de compilación
Para forzar una recompilación completa sin re-descargar dependencias
Cuando los binarios están corruptos pero las fuentes están bien

💡 No descarga dependencias nuevamente ni resuelve problemas de caché de paquetes.

Swift package reset

swift package reset

Qué hace:
Elimina completamente la carpeta .build (incluyendo dependencias descargadas) y el archivo Package.resolved.

Cuándo usarlo:

Cuando hay conflictos en las versiones de dependencias
Después de cambios importantes en Package.swift
Para resolver errores de “dependencia no encontrada”
Cuando Package.resolved está desactualizado o corrupto

⚠️ La próxima compilación descargará y resolverá todas las dependencias desde cero. Esto puede tardar varios minutos dependiendo de la cantidad de paquetes.

Swift package purge-cache

swift package purge-cache

💡 Disponible desde Swift 5.7 en adelante.

Qué hace:
Elimina la caché global de paquetes ubicada en:

~/Library/Caches/org.swift.swiftpm/

Esta caché contiene repositorios clonados y artefactos binarios compartidos entre todos tus proyectos.

Cuándo usarlo:

Cuando múltiples proyectos tienen el mismo problema
Después de actualizar Xcode o herramientas de Swift
Para liberar espacio en disco (puede ocupar varios GB)
Cuando sospechas que la caché global está corrupta

⚠️ Todos tus proyectos tendrán que re-descargar dependencias comunes.

rm -rf .build

rm -rf .build

Qué hace:
Elimina manualmente la carpeta .build completa, similar a reset pero sin tocar Package.resolved. Es menos agresivo que reset porque no re-resuelve dependencias.

Cuándo usarlo:

Para limpiar artefactos de compilación manteniendo la resolución de versiones
En scripts de CI/CD donde quieres control total
Cuando swift package reset no está disponible

💡 Preserva Package.resolved, lo que significa que las versiones de dependencias no se re-resolverán.

Estrategia de resolución de problemas

Nivel 1: Limpieza ligera

swift package clean

💡 Prueba primero lo menos invasivo. Resuelve el 30% de los problemas.

Nivel 2: Reset completo del proyecto

swift package reset

💡 Si el nivel 1 falla. Resuelve el 60% de los problemas restantes.

Nivel 3: Purgar caché global

swift package purge-cache
swift package reset

💡 Para problemas persistentes o que afectan múltiples proyectos.

Nivel 4: Nuclear

rm -rf .build
rm Package.resolved
swift package purge-cache

💡 Última opción. Borrón y cuenta nueva total.

Casos de uso reales

Escenario 1: Error después de actualizar Xcode

swift package purge-cache
swift package reset

💡 Las herramientas de compilación cambiaron y la caché puede tener artefactos incompatibles.

Escenario 2: Conflicto de versiones de dependencias

swift package reset

💡 Necesitas re-resolver todas las dependencias con las nuevas restricciones.

Escenario 3: Espacio en disco lleno

swift package purge-cache

💡 La caché global puede crecer hasta varios GB sin que lo notes.

Escenario 4: CI/CD builds

rm -rf .build

💡 En entornos de integración continua, quieres builds limpios pero reproducibles con Package.resolved versionado.

Entendiendo los componentes

.build (local)

Artefactos de compilación del proyecto actual
Dependencias descargadas específicas del proyecto
Archivos intermedios de compilación

Package.resolved

“Lockfile” que fija versiones exactas de dependencias
Garantiza builds reproducibles
Debe versionarse en Git para proyectos compartidos

Caché global

Compartida entre todos tus proyectos Swift
Contiene clones de repositorios de dependencias
Artefactos binarios pre-compilados
Puede alcanzar varios GB con el tiempo

Mejores prácticas

✅ Versiona Package.resolved en Git para garantizar que todo el equipo use las mismas versiones

✅ Usa reset después de cambios en Package.swift para asegurar una resolución limpia

✅ Purga la caché periódicamente si trabajas con muchos proyectos

✅ En CI/CD, mantén Package.resolved pero elimina .build para builds limpios

❌ No ignores .build en .gitignore - ya está ignorado por defecto

❌ No borres Package.resolved a menos que realmente necesites re-resolver versiones

Conclusión

Entender la diferencia entre estos comandos te ahorra tiempo y frustración. No todos los problemas de compilación necesitan una limpieza nuclear:

clean → Solo binarios compilados
reset → Proyecto completo + Package.resolved
purge-cache → Caché global compartida
rm -rf → Control manual quirúrgico

La próxima vez que SPM te muestre un error extraño, ya sabes exactamente qué herramienta usar.

Keep coding, keep running 🏃‍♂️

Subprocess

2025-12-17T00:00:00Z

Problema

Al trabajar con procesos externos en aplicaciones Swift, la clase tradicional Process presenta varias limitaciones importantes:

Gestión manual de recursos: Requiere configuración explícita de URLs ejecutables, argumentos y manejo de salidas
Falta de soporte async/await: Utiliza métodos síncronos que bloquean el hilo de ejecución
Manejo complejo de errores: Dificulta la captura y procesamiento de errores del proceso hijo
Configuración verbosa: Cada ejecución requiere múltiples líneas de configuración repetitiva

En el código anterior, necesitaba ejecutar Ghostscript para convertir archivos PDF a imágenes PNG, pero la implementación con Process resulta extensa y poco elegante.

func _PDFToImages(
    _ fileName: PathEnum
) async throws {
    let process = Process()

    process.executableURL = URL(
        fileURLWithPath: "/opt/homebrew/bin/gs"
    )

    process.arguments = [
        "-dNOPAUSE", "-dBATCH",
        "-dQUIET", "-sDEVICE=png16m",
        "-r300",
        "-sOutputFile=\(fileName.rawValue)-%d.png",
        fileName.rawValue.appending(".pdf"),
    ]

    try process.run()
    process.waitUntilExit()
}

Solución

La nueva librería Subprocess de Apple proporciona una API moderna y robusta para la ejecución de procesos en Swift. Esta librería multiplataforma ofrece soporte nativo para async/await y gestión automática de recursos.

Características principales:

✅ API nativa async/await para operaciones no bloqueantes.

✅ Gestión automática de recursos y limpieza de procesos.

✅ Control granular de salidas (stdout, stderr).

✅ Verificación de estado de terminación integrada.

✅ Sintaxis concisa y expresiva.

La implementación modernizada utiliza la función run de Subprocess:

func _PDFToImages(
    _ fileName: PathEnum
) async throws {
    let result = try await run(
        .path(.init("/opt/homebrew/bin/gs")),
        arguments: [
            "-dNOPAUSE", "-dBATCH",
            "-dQUIET", "-sDEVICE=png16m",
            "-r300",
            "-sOutputFile=\(fileName.rawValue)-%d.png",
            fileName.rawValue.appending(".pdf"),
        ],
        output: .discarded,
        error: .string(limit: .max)
    )

    try guardAndLogError(
        result.terminationStatus == .exited(0),
        message: result.standardError,
        status: .internalServerError
    )
}

Parámetros clave:

.path: Especifica el ejecutable de forma directa
output: .discarded: Descarta la salida estándar ya que no necesitamos procesarla
error: .string(limit: .max): Captura errores como string para logging
result.terminationStatus: Verifica que el proceso terminó exitosamente

Resultado

La migración a Subprocess transforma el código de gestión de procesos en una solución más limpia, segura y eficiente:

Beneficios obtenidos:

🚀 Rendimiento mejorado con operaciones asíncronas reales.

🔒 Mejor manejo de errores con captura integrada de stderr.

📝 Código más legible con menos configuración manual.

⚡ Integración perfecta con el ecosistema moderno de Swift concurrency.

La nueva implementación no solo reduce la complejidad sino que también mejora la robustez del sistema al proporcionar mejor visibilidad de errores y un manejo más elegante de la ejecución asíncrona en aplicaciones Vapor.

Nota sobre DYLD_LIBRARY_PATH

En versiones anteriores de Swift, existía un problema conocido con la variable de entorno DYLD_LIBRARY_PATH al ejecutar procesos externos. Debido a las restricciones de System Integrity Protection (SIP) de macOS, esta variable era eliminada automáticamente al lanzar subprocesos, lo que causaba errores de “Library not loaded” en ciertos casos.

La solución temporal requería configurar manualmente las rutas de las librerías usando install_name_tool con @rpath, o bien establecer la variable DYLD_LIBRARY_PATH en su lugar.

¡Buenas noticias! 🎉 Este problema ha sido resuelto en las versiones más recientes de Swift. La librería Subprocess maneja correctamente las variables de entorno del sistema, incluida DYLD_LIBRARY_PATH, sin necesidad de configuraciones adicionales.

Keep coding, keep running 🏃‍♂️

Json Snake Case

2025-12-11T00:00:00Z

Problema

Cuando integramos APIs REST, es muy común que las claves JSON vengan en snake_case (por ejemplo, first_name) mientras que en Swift modelamos las propiedades en camelCase (firstName).
Si no configuramos nada, nos toca escribir CodingKeys a mano en cada modelo o aceptar errores de decodificación.

Buscamos una forma centralizada y reutilizable de:

Decodificar JSON sin CodingKeys manuales.
Codificar nuestros modelos al enviar datos.
Mantener el mismo comportamiento tanto en apps iOS/macOS (URLSession) como en Vapor (req/res content).

Solución

Creamos extensiones de JSONDecoder y JSONEncoder que exponen constructores de conveniencia y atajos estáticos snakeCase.
Ventajas:

Cero boilerplate en los modelos: evita CodingKeys repetitivas.
Nombre autoexplicativo al usarlas: JSONDecoder.snakeCase / JSONEncoder.snakeCase.
Consistencia en todo el proyecto (cliente y servidor).

extension JSONDecoder {
    convenience init(keyDecodingStrategy: KeyDecodingStrategy) {
        self.init()
        self.keyDecodingStrategy = keyDecodingStrategy
    }

    static var snakeCase: JSONDecoder {
        .init(keyDecodingStrategy: .convertFromSnakeCase)
    }
}

extension JSONEncoder {
    convenience init(keyEncodingStrategy: KeyEncodingStrategy) {
        self.init()
        self.keyEncodingStrategy = keyEncodingStrategy
    }

    static var snakeCase: JSONEncoder {
        .init(keyEncodingStrategy: .convertToSnakeCase)
    }
}

Nota: si un modelo necesita un nombre de clave específico, puedes seguir usando CodingKeys localmente; la estrategia snake_case actuará como valor por defecto.

Resultado

Ejemplos de uso

// iOS / macOS: leer datos
let data: Data = ...
let user = try JSONDecoder.snakeCase
    .decode(UserDTO.self, from: data)

// iOS / macOS: enviar datos
let body = CreateUserDTO(firstName: "Ada", lastName: "Lovelace")
request.httpBody = try JSONEncoder.snakeCase.encode(body)

// Vapor
let input = try req.content
    .decode(CreateUserDTO.self, using: JSONDecoder.snakeCase)

Con estos atajos obtenemos:

Menos errores y mayor legibilidad: las propiedades permanecen en camelCase idiomático Swift.
Interoperabilidad inmediata con APIs legacy en snake_case.
Configuración única y reutilizable en todo el proyecto (tests incluidos).

Esto estandariza cómo serializamos/parseamos JSON sin sacrificar claridad ni control fino cuando hace falta.

Keep coding, keep running 🏃‍♂️

Array to dictionary

2025-12-03T00:00:00Z

Problema

Al trabajar con listas de modelos (por ejemplo, resultados, eventos o usuarios), a menudo necesitamos acceso O(1) por identificador para búsquedas, merges o deduplicación.

Sin embargo, en muchos dominios el id puede ser opcional (UUID?) hasta que el backend lo asigne. Si construimos un diccionario directamente, aparecen dos fricciones:

Hay que filtrar los elementos sin ID para evitar entradas inválidas.
Debemos garantizar unicidad de las claves o el constructor de Dictionary(uniqueKeysWithValues:) fallará en tiempo de ejecución si hay duplicados.

Solución

Extendemos Array (cuando sus elementos son Identifiable con ID == UUID?) para exponer toDictionary().
La función usa compactMap para descartar elementos sin ID y construye el diccionario con Dictionary(uniqueKeysWithValues:).

Precondición: los IDs existentes deben ser únicos en la colección. Si esperas colisiones, considera una variante con Dictionary(_, uniquingKeysWith:) para resolver duplicados.

extension Array where Element: Identifiable, Element.ID == UUID? {
    func toDictionary() -> [UUID: Element] {
        Dictionary(uniqueKeysWithValues: self.compactMap {
            guard let id = $0.id else { return nil }
            return (id, $0) }
        )
    }
}

Notas:

Los elementos con id == nil no se incluyen.
El acceso por clave es O(1) y simplifica merges/joins en memoria.

Resultado

Un helper pequeño y claro para pasar de un array a un mapa por ID:

Más rápido de consultar O(1).
Más seguro: evita insertar elementos sin identificador.
Más expresivo y reutilizable en servicios y view models.

Keep coding, keep running 🏃‍♂️

Schedule Queues

2025-11-26T00:00:00Z

Problema

Cuando usamos Vapor Queues para planificar trabajos, la API típica es:

app.queues
    .schedule(MyJob()).hourly().at(0)

Esto planifica cada hora. Si queremos ejecutarlo cada N minutos (p. ej., cada 5, 10 o 15), tenemos que registrar manualmente varios .at(…), lo que acaba en código repetitivo, propenso a errores (minutos duplicados/olvidados) y poco legible.

Solución

Extraemos un helper sobre Application.Queues que registra el mismo ScheduledJob múltiples veces dentro de la hora usando un stride con paso minutes. Así, con una sola llamada expresamos: “ejecútalo cada N minutos”.

extension Application.Queues {
    func scheduleEvery(
        _ job: ScheduledJob, 
        minutes: Int
    ) {
        for minuteOffset in stride(
            from: 0, 
            to: 60, 
            by: minutes
        ) {
            schedule(job).hourly()
                .at(.init(integerLiteral: minuteOffset))
        }
    }
}

Puntos clave:

Usa stride(from: 0, to: 60, by: minutes) para generar los offsets de minuto dentro de la hora.
Por cada offset se registra hourly().at(…), evitando duplicar lógica.
Si minutes no divide 60, la última ejecución será el mayor múltiplo < 60 (p. ej., minutes = 7 ⇒ 0, 7, 14, …, 56).

Resultado

Ejemplo de uso:

func configure(_ app: Application) throws {
    app.queues.scheduleEvery(MyJob(), minutes: 5)
}

Una API concisa y autoexpresiva para tareas periódicas cortas:

Menos boilerplate: una sola llamada registra todos los disparos.
Menos errores: sin listas manuales de .at(…) ni minutos duplicados.
Legible y testeable: el patrón es evidente y fácil de verificar.

Keep coding, keep running 🏃‍♂️

Async Task List

2025-11-20T00:00:00Z

Problema

En sistemas distribuidos con microservicios, un proceso complejo puede generar dificultades de control y fiabilidad. Una solución es dividirlo en tareas atómicas, lo que permite un control más granular del flujo, mejorar la observabilidad, asegurar la idempotencia y facilitar la recuperación ante fallos.

El reto es diseñar un patrón que permita una degradación controlada, de modo que el fallo de una tarea no afecte al flujo completo, garantizando resiliencia y tolerancia a fallos en entornos de producción.

Solución

Crear un task executor que orquesta tareas asíncronas.
La función execute envuelve cada tarea, gestiona errores con do-catch como circuit breaker, actualiza el estado en caso de éxito, registra y persiste los fallos, y asegura una transacción atómica para mantener la consistencia de datos.

func execute(
    status: StatusEnum,
    process: ProcessModel,
    _ work: () async throws -> ProcessModel
) async throws {
    do {
        let job = try await work()
        process.setStatus(job.status)
    } catch {
        process.setError(type: status, message: "\(error)")
    }
    try await repo.updateProcess(process)
}

Resultado

Esta implementación ofrece una abstracción de alto nivel que permite una orquestación precisa de procesos asíncronos complejos con garantías de atomicidad y durabilidad.

🎯 Separation of Concerns: cada tarea aísla su contexto de ejecución y su gestión de errores.

🔄 Workflow Orchestration: posibilita encadenar tareas mediante el pipeline pattern.

📊 Observability: genera un audit trail completo para depuración y monitorización.

⚡ Performance: mantiene alta concurrencia sin comprometer la consistencia de datos.

🛡️ Resilience: incorpora fail-fast y recovery patterns automáticos.

try await execute(status: .loadImages, process: process) {
    // Your implementation
}

Keep coding, keep running 🏃‍♂️

Multi-Step Process

2025-11-12T00:00:00Z

Problema

En sistemas distribuidos y procesos de backend, es común que una operación compleja requiera ejecutar múltiples pasos secuenciales con dependencias entre sí: creación de ficheros, subida, generación de respuestas, validación, limpieza, etc.
Controlar este flujo de estados es crítico para:

Garantizar que cada paso se ejecute en el orden correcto.
Permitir la recuperación en caso de error o reinicio del sistema.
Mantener la consistencia de datos incluso si el proceso se interrumpe.

Sin una estrategia clara, el código puede volverse frágil, difícil de escalar y propenso a errores.

Solución

Se implementa una función de gestión de estado por etapas que controla el avance de un ProcessModel a través de su ciclo de vida.
La idea es encapsular la lógica de transición de estado en una única función que evalúa el estado actual y ejecuta la acción correspondiente, hasta que el proceso alcanza su estado final.

El patrón se apoya en un bucle repeat-while que vuelve a evaluar el estado tras cada operación, garantizando que las transiciones ocurran de forma determinista y resiliente.

func checkProcess(
    _ process: ProcessModel
) async throws {
    var process = process
    var status = process.status

    repeat {
        status = process.status
        process = try await checkStatus(process)
    } while status != process.status
}

func checkStatus(
    _ process: ProcessModel
) async throws -> ProcessModel {
    switch process.status {
        case .filesCreated: 
            try await _uploadFiles(process)
        case .filesUploaded: 
            try await _createResponses(process)
        case .responsesCreated, .responsesReasoning: 
            try await _checkResponses(process)
        case .responsesCompleted: 
            try await _deleteFiles(process)
        case .filesDeleted: 
            try await _deleteResponses(process)
        case .responsesDeleted: 
            try await _finishResponses(process)
        case .responsesFinished: 
            try await _deleteProcess(process)
        default: process
    }
}

Claves de la implementación:

Centralización de estados: un único punto de control define todas las transiciones.
Reevaluación continua: el bucle repeat-while permite avanzar automáticamente mientras haya cambios de estado.
Aislamiento de operaciones: cada caso del switch delega en funciones especializadas (_uploadFiles, _createResponses, etc.), manteniendo el código limpio y testeable.

Resultado

Este patrón de gestión de procesos multi‑etapa aporta:

Resiliencia: cada transición es atómica y se puede reintentar si ocurre un fallo.
Escalabilidad: agregar nuevos pasos solo requiere añadir un nuevo caso al switch.
Claridad: el flujo completo del proceso se entiende con una sola lectura.

Ejemplo de aplicación: pipelines de procesamiento de datos, flujos de publicación de contenido, o cualquier proceso de larga duración que requiera control preciso de cada etapa sin comprometer la integridad de los datos.

Keep coding, keep running 🏃‍♂️

Concurrent Map

2025-10-27T00:00:00Z

Problema

Cuando procesamos colecciones en Swift, el método map ejecuta las transformaciones de forma secuencial.
En operaciones intensivas o que implican I/O —como peticiones HTTP, lectura de archivos o consultas de base de datos— esto puede ser un cuello de botella.
El objetivo es aprovechar la concurrencia para ejecutar múltiples transformaciones en paralelo, garantizando seguridad con Sendable y manejo de errores.

Solución

Se crea una extensión de Sequence que añade concurrentMap.
Internamente usa withThrowingTaskGroup, lo que permite:

Lanzar una tarea por cada elemento de la secuencia.
Ejecutar todas las transformaciones en paralelo, respetando el modelo de concurrencia estructurada de Swift.
Propagar automáticamente el primer error que se produzca, cancelando las tareas restantes.

El uso de @Sendable asegura que tanto los elementos como el resultado sean seguros en entornos concurrentes.
De esta manera, cualquier operación asíncrona puede beneficiarse de la ejecución en paralelo sin sacrificar la claridad del código.

extension Sequence where Element: Sendable {
    func concurrentMap<T: Sendable>(
        _ transform: @escaping @Sendable (Element) async throws -> T
    ) async throws -> [T] {
        try await withThrowingTaskGroup(of: T.self) { group in
            for element in self {
                group.addTask {
                    try await transform(element)
                }
            }
            return try await group.reduce(into: []) { 
                $0.append($1) 
            }
        }
    }
}

Resultado

Con concurrentMap se consigue una ganancia de rendimiento significativa en operaciones asíncronas que pueden ejecutarse en paralelo.
El patrón respeta las reglas de concurrencia estructurada de Swift, evita data races y mantiene el mismo estilo declarativo que map, por lo que su adopción en proyectos existentes es sencilla.

Ejemplo de uso:

let urls: [URL] = [...]
let contents = try await urls.concurrentMap {
    try await fetchContent(from: $0)
}

Este enfoque es ideal para peticiones HTTP en lotes, procesamiento de imágenes, lectura masiva de datos o cualquier escenario que requiera máximo paralelismo seguro.

Si necesitas orden garantizado o limitar el consumo de recursos a una tarea a la vez, lo cubrí en Async Map. Y si quieres combinar ambas estrategias — procesamiento concurrente dentro de chunks controlados — lo construí en Async Concurrent Map.

Keep coding, keep running 🏃‍♂️

Async Map

2025-10-20T00:00:00Z

Problema

Cuando procesamos colecciones con transformaciones asíncronas, el método map no sirve porque sus closures no pueden ser async.
Una solución ingenua sería usar un bucle for con await, pero se pierde legibilidad y un manejo de errores homogéneo.
El objetivo es disponer de un map secuencial que acepte funciones async throws, preserve el orden de los elementos y simplifique el flujo de trabajo.

Solución

Se crea una extensión de Sequence que añade asyncMap.
Su ejecución es secuencial dentro de la misma tarea, lo que permite:

Mantener el orden determinista de los resultados.
Limitar el consumo de recursos ejecutando solo una operación a la vez.
Propagar de manera uniforme el primer error que se produzca, deteniendo el proceso.

extension Sequence {
    @inlinable
    func asyncMap<T>(
        _ transform: @escaping @Sendable (Element) async throws -> T
    ) async throws -> [T] {
        var results: [T] = []
        results.reserveCapacity(underestimatedCount)
        for element in self {
            let value = try await transform(element)
            results.append(value)
        }
        return results
    }
}

Resultado

Con asyncMap se obtiene un flujo claro y seguro para transformaciones asíncronas sin paralelismo.
Es especialmente útil cuando:

Necesitamos orden garantizado.
Debemos limitar el consumo de recursos (una tarea en vuelo).
Existe dependencia entre las operaciones.

Si necesitas ejecución en paralelo en lugar de secuencial, exploré ese enfoque en Concurrent Map. Y si tus llamadas secuenciales alcanzan límites de tasa, añadí un mecanismo de timeout en Async Map Timeout.

Ejemplo de uso:

let urls: [URL] = [...]
let contents = try await urls.asyncMap {
    try await fetchContent(from: $0)
}

Keep coding, keep running 🏃‍♂️

Guard and LogError

2025-10-13T00:00:00Z

Problema

En múltiples secciones de mi código necesito ejecutar tres operaciones cada vez que manejo un Optional:

Desempaquetar el contenido del Optional
Registrar un error en el sistema de logs si el valor es nil
Lanzar una excepción cuando el valor no existe

Este patrón se repite frecuentemente, generando código duplicado y reduciendo la mantenibilidad.

Solución

La estrategia consiste en encapsular las tres operaciones en funciones reutilizables que trabajen de forma coordinada.

Función auxiliar: logError

func logError(
    _ message: String, 
    status: HTTPResponseStatus
) throws -> Never {
    self.logMessage(message, level: .error)
    throw Abort(status, reason: message)
}

Esta función ejecuta el registro del error en el sistema de logs y posteriormente termina la ejecución lanzando una excepción Abort. El tipo de retorno Never es fundamental, ya que indica al compilador que esta función nunca retorna normalmente, garantizando que la ejecución se interrumpa completamente.

Función principal: guardAndLogError

func guardAndLogError<T>(
    _ optional: T?,
    message: String,
    status: HTTPResponseStatus = .noContent
) throws -> T {
    guard let optional else {
        try logError(message, status: status)
    }
    return optional
}

Esta función genérica implementa el patrón completo:

Utiliza guard let para desempaquetar el Optional de forma segura
Si el valor es nil, invoca logError() para registrar el fallo y terminar la ejecución
Si contiene un valor, lo retorna exitosamente

La genericidad T permite usar esta función con cualquier tipo de dato opcional.

Resultado

Con esta implementación, una sola línea de código ejecuta las tres operaciones requeridas: desempaquetado seguro, logging de errores y manejo de excepciones.

let fileName = try guardAndLogError(
    fileName, 
    message: "Valor fileName no encontrado"
)

Beneficios

✅ Reducción de código duplicado

✅ Manejo consistente de errores

✅ Logs centralizados y estructurados

✅ Reutilización mediante genericidad

Extensibilidad

Este patrón puede extenderse para casos de uso más específicos:

// Para validaciones booleanas
func guardAndLogError(
    _ condition: Bool, 
    message: String
) throws { ... }

// Para arrays
func guardAndLogError<T>(
    _ optionals: T?..., 
    message: String
) throws -> [T] { ... }

// Para tuplas
func guardAndLogError<T, U>(
    _ first: T?, 
    _ second: U?
    , message: String
) throws -> (T, U) { ... }

Keep coding, keep running 🏃‍♂️

Esquemas y Espacios

2025-10-06T00:00:00Z

Esquema y Espacio de Nombres

Al definir un modelo de datos en Vapor, es posible especificar el schema, que corresponde al nombre de la tabla en la base de datos. Sin embargo, para mantener una arquitectura organizada, es recomendable agrupar las tablas en diferentes espacios de nombres según criterios funcionales, en lugar de concentrarlas todas en el esquema predeterminado. Esta práctica facilita la separación lógica por dominios o módulos de la aplicación.

Implementación

Para asignar una tabla a un espacio de nombres específico, se debe sobrescribir la propiedad estática space en el modelo. Esta propiedad permite definir el namespace donde residirá la tabla, proporcionando una organización más granular de la estructura de base de datos.

public final class LocationCityModel: Model {
    public static let schema = "cities"
    public static let space: String? = "location"

    @ID() public var id: UUID?
    @Field(.name) public var name: String

    public init() { }
}

Consideración

Es fundamental declarar la propiedad space como tipo String? (opcional). Si se declara como String (no opcional), no se sobrescribirá la propiedad heredada del protocolo Model, sino que se creará una nueva propiedad con el mismo nombre. Esto ocasionará que el framework ignore la configuración del espacio de nombres, manteniendo las tablas en el esquema predeterminado sin indicación de error aparente.

Si te preguntas cómo crear estos espacios de nombres automáticamente en la base de datos, explico cómo convertirlo en una migración en Migrate Spaces.

Keep coding, keep running 🏃‍♂️

Índices Parciales

2025-09-29T00:00:00Z

Índices Parciales

Un índice parcial es un índice que se crea únicamente sobre un subconjunto de filas de una tabla, definido mediante una condición WHERE específica. En lugar de indexar todas las filas, el índice solo incluye aquellas que cumplen ciertos criterios, lo que puede mejorar el rendimiento y reducir el espacio utilizado.

En mi caso particular, necesitaba indexar campos en función de si sus valores eran NULL o NOT NULL. Por ejemplo, los siguientes índices parciales en SQL:

CREATE INDEX index_field_null 
ON table(field) 
WHERE field IS NULL;

CREATE INDEX index_field_not_null 
ON table(field) 
WHERE field IS NOT NULL;

También es posible crear índices parciales que involucren múltiples columnas:

CREATE INDEX index_field1_null_field2_null 
ON table(field1, field2) 
WHERE field1 IS NULL AND field2 IS NULL;

CREATE INDEX index_field1_not_null_field2_not_null 
ON table(field1, field2) 
WHERE field1 IS NOT NULL AND field2 IS NOT NULL;

No todas las bases de datos admiten índices parciales, en mi caso particular estoy usando PostgreSQL

Problema

Por defecto, Vapor no ofrece soporte directo para la creación de índices parciales, ya que la generación estándar de índices no contempla la inclusión de una cláusula WHERE en la definición del índice.

El siguiente fragmento de código crea un índice normal, ya sea sobre uno o varios campos, pero no permite especificar una condición para un índice parcial:

try await db.sqlDatabase
    .create($0.key)
    .on(table)
    .colums($0.colums)
    .run()

Este código funciona para crear índices simples, pero carece de la capacidad para agregar un predicado WHERE.

Este fragmento ha sido adaptado por mí; el método .create del constructor original expone más opciones de configuración, pero en este ejemplo muestro una implementación personalizada y simplificada que uso actualmente.

Alternativa

La forma más directa de crear índices parciales es ejecutar sentencias SQL en crudo raw SQL, tal como se mostró en los ejemplos iniciales. Esto implica construir un método para ejecutar en crudo las sentencias CREATE INDEX con la cláusula WHERE correspondiente.

Aunque efectivo, este enfoque pierde la ventaja de la abstracción y seguridad que ofrece Vapor al construir migraciones y esquemas de base de datos mediante código Swift.

Solución

El builder SQLCreateIndexBuilder admite un predicado opcional predicate. Si este no es nil, agrega una cláusula WHERE al índice.

Por ello, extendí este builder para incluir un método where que acepta una lista de columnas y un tipo de índice parcial (por ejemplo, null o not null). Este método construye la expresión lógica adecuada para el predicado y la asigna al índice.

extension SQLCreateIndexBuilder {
    @discardableResult
    func `where`(
        _ columns: [FieldKey],
        _ partialIndex: SQLPartialIndexEnum?
    ) -> Self {
        guard let partialIndex else {
            return self
        }
        let op: SQLBinaryOperator = partialIndex == .null ? .is : .isNot

        let conditions = columns.map {
            self.where($0, op)
        }

        let combined: SQLBinaryExpression = conditions.dropFirst()
            .reduce(conditions[0]) { .init($0, .and, $1) }

        return self.where(combined)
    }

    private func `where`(
        _ column: FieldKey,
        _ binary: SQLBinaryOperator
    ) -> SQLBinaryExpression {
        .init(
            left: SQLIdentifier(column.description),
            op: binary,
            right: SQLLiteral.null
        )
    }

    private func `where`(_ expression: SQLExpression) -> Self {
        self.createIndex.predicate = expression
        return self
    }
}

Este código permite invocar el método where para uno o varios campos, especificando si se desea un índice parcial para valores NULL o NOT NULL. Si no se proporciona un valor para partialIndex, se devuelve el índice sin predicado, comportándose como un índice normal.

La lógica consiste en crear una lista de expresiones binarias SQLBinaryExpression para cada columna, combinándolas con el operador lógico AND y asignando el resultado como predicado del índice.

Resultado

Con esta extensión, ahora puedo crear índices parciales de forma sencilla en Vapor, agregando únicamente una línea al código original:

try await db.sqlDatabase
    .create($0.key)
    .on(table)
    .colums($0.colums)
    .where($0.colums, $0.partial)
    .run()

Donde $0.partial es un valor opcional que indica el tipo de índice parcial deseado null o not null.

Notas finales

Este enfoque está diseñado específicamente para índices parciales basados en la presencia o ausencia de valores NULL en columnas. Sin embargo, la implementación puede adaptarse para soportar otras condiciones y casos de uso más complejos, simplemente modificando la construcción del predicado.

La solución ofrece una forma limpia y reutilizable de crear índices parciales dentro del ecosistema Vapor, manteniendo la coherencia y seguridad del código Swift.

Si además quieres organizar tus tablas en espacios de nombres usando la propiedad space de Fluent, lo cubrí en Esquemas y Espacios.

Keep coding, keep running 🏃‍♂️

Mi primera condición de carrera

2025-09-22T00:00:00Z

De refactor a condición de carrera en Swift

Durante un proceso de refactorización para convertir una funcionalidad previamente secuencial en una concurrente, me encontré con un problema clásico: garantizar la unicidad de los registros cuando múltiples tareas intentan crear eventos al mismo tiempo. Aunque el objetivo era mejorar el rendimiento procesando miles de eventos en paralelo usando Swift, la transición expuso un desafío típico de concurrencia: evitar duplicados y mantener la integridad de los datos bajo acceso simultáneo.

Actor con array

private actor EventsActor {
    private var events: [SportEventModel] = []

    func getOrCreate(
        name: String, 
        cityId: UUID, 
        build: () async throws -> EventModel
    ) async throws -> EventModel {
        if let event = events.first(
            where: { 
                $0.normalizedName == name 
                && $0.$city.id == cityId 
            }
        ) { return event }

        let event = try await build()
        events.append(event)
        return event
    }
}

Ventajas:

Simplicidad.
Seguridad frente a condiciones de carrera.

Desventaja:

Búsqueda ineficiente en grandes volúmenes O(n).

Actor con diccionario

private actor EventsActor {
    private var events: [String: EventModel] = [:]

    func getOrCreate(
        name: String, 
        cityId: UUID, 
        build: () async throws -> EventModel
    ) async throws -> EventModel {
        let key = "\(name)\(cityId.uuidString)"
        if let event = events[key] { 
            return event 
        }
        let event = try await build()
        events[key] = event
        return event
    }
}

Ventajas:

Búsqueda e inserción rápida O(1).
Ideal para grandes volúmenes de datos.

Bug:

Condición de carrera lógica

Condición de carrera lógica

Cuando múltiples tareas concurrentes intentan crear el mismo evento, todas pueden comprobar que no existe y proceder a crearlo al mismo tiempo.
Solo una de las instancias resultantes se almacena, mientras que el resto se convierten en “huérfanas”, lo que provoca inconsistencias y referencias rotas en otras estructuras de datos.

Por ejemplo: dos tareas concurrentes comprueban si un evento existe. Ambas ven que no, ambas lo crean, pero solo una sobrevive en el diccionario; la otra referencia ahora está perdida.

Solución

Para evitar esto, es necesario serializar no solo el acceso sino también la creación por clave:
Si ya hay una creación en curso para esa clave, las tareas concurrentes deben esperar el resultado de la primera, asegurando que todas compartan exactamente el mismo recurso.

private actor EventsActor {
    private var events: [String: EventModel] = [:]
    private var builds: [String: Task<EventModel, Error>] = [:]
    
    func getOrCreate(
        name: String, 
        cityId: UUID, 
        build: @Sendable @escaping () async throws -> EventModel
    ) async throws -> EventModel {
        let key = "\(name)\(cityId.uuidString)"
        if let event = events[key] { 
            return event 
        }

        if let building = builds[key] { 
            return try await building.value 
        }
        
        let buildTask = Task { 
            try await build() 
        }
        builds[key] = buildTask
        
        let event = try await buildTask.value
        events[key] = event
        builds.removeValue(forKey: key)
        return event
    }
}

Lecciones aprendidas

Un actor por sí solo no previene condiciones de carrera lógicas del tipo “check-then-act”.
En escenarios concurrentes, serializar la construcción del recurso por clave es fundamental para mantener la integridad de los datos.
Es esencial probar bajo carga y escenarios concurrentes, no solo en modo secuencial.

Keep coding, keep running 🏃‍♂️

Timestamps en Migraciones

2025-09-15T00:00:00Z

Timestamps

Si eres como yo, cuando diseñas un modelo de base de datos quieres que todas las tablas incluyan siempre tres campos clave:

createdAt: indica cuándo se creó el registro.
updatedAt: refleja la última vez que se actualizó.
deletedAt: marca cuándo se eliminó de forma lógica (sin borrar físicamente el registro).

Problema

Como se puede observar, en cada migración tenemos que escribir manualmente los tres campos de timestamp. Esto no solo es repetitivo, sino que también es propenso a errores si olvidamos algún campo o escribimos mal el tipo de dato.

try await db.schema(model)
    .id()
    .field(.name, .string, .required)
    .field(.createdAt, .datetime, .required)
    .field(.updatedAt, .datetime, .required)
    .field(.deletedAt, .datetime)
    .create()

Solución

La solución es crear una extensión de SchemaBuilder que agregue un método timestamps(). Esta extensión encapsula la lógica repetitiva en un solo lugar, haciendo el código más limpio y mantenible.

extension SchemaBuilder {
    func timestamps() -> Self {
        self.field(.createdAt, .datetime, .required)
            .field(.updatedAt, .datetime, .required)
            .field(.deletedAt, .datetime)
    }
}

Resultado

Ahora nuestras migraciones son mucho más limpias y legibles. Llamando a .timestamps() agregamos los tres campos necesarios. Esto reduce la posibilidad de errores y hace que el código sea más fácil de mantener.

try await db.schema(model)
    .id()
    .field(.name, .string, .required)
    .timestamps()
    .create()

Keep coding, keep running 🏃‍♂️

☁️ Servidor en la nube

2025-09-08T00:00:00Z

☁️ Cloud Server

Cuando trabajas con backend, a no ser que estés trabajando en una red local y no vaya a salir nada de lo que hagas hacia afuera, vas a necesitar sí o sí un servidor en la nube y cuanto antes mejor 🚀.

Trabajar en local está muy bien, pero tener un servidor en la nube es un paso hacia adelante, y es mejor empezar cuanto antes para tener un servidor de desarrollo en la nube.

🔧 Arquitecturas de CPU

Conforme la tecnología avanza, cada vez hay más opciones tanto en proveedores como en tecnología de procesadores 💻:

AMD 🔴:
- ✅ Excelente relación precio/rendimiento
- ✅ Arquitectura x64 madura y estable
- ✅ Amplia compatibilidad con software
- ✅ Ideal para aplicaciones de alto rendimiento
Intel 🔵:
- ✅ Líder histórico en el mercado de servidores
- ✅ Excelente soporte empresarial
- ✅ Optimizaciones específicas para aplicaciones legacy
- ✅ Rendimiento consistente y predecible
ARM 🍃:
- ✅ El último en llegar pero con gran potencial
- ✅ Eficiencia energética superior
- ✅ Mejor precio por núcleo
- ✅ Ideal para microservicios y contenedores
- ✅ Menor consumo = menor costo operativo
- ⚠️ Algunas limitaciones de compatibilidad con software legacy

💰 Free Tier - Oracle Cloud

Yo he optado por Oracle Cloud y el free tier que tiene, el cual te ofrece un servidor ARM, ya que para mí es la opción que mejor se adapta a mis necesidades 🎯.

🖥️ VM.Standard.A1.Flex (Ampere ARM)

⏱️ Hasta 3.000 OCPU-horas al mes

🧠 Hasta 18.000 GB-horas de memoria al mes

🚀 1 servidor con 4 OCPUs + 24 GB RAM funcionando 24/7

🔄 O varias instancias más pequeñas (ejemplo: 4 × 1 OCPU + 6 GB RAM)

💾 Hasta 200 GB combinados entre volúmenes de arranque y bloques

♾️ Gratuito indefinidamente, siempre dentro de los límites del plan

⚠️ Oracle puede reclamar instancias inactivas (sin uso significativo en 7 días)

🌍 Puede haber restricciones regionales por falta de capacidad

💸 100% gratis dentro del plan Always Free

Keep coding, keep running 🏃‍♂️

Claude Code

2025-09-01T00:00:00Z

🤔 ¿Qué es Claude Code para mí?

Para alejarme de lo que habla todo el mundo 😂, voy a contaros sobre inteligencia artificial desde mi experiencia personal.

He integrado Claude Code en mis proyectos, pero para mí es mucho más que una herramienta: es mi asistente digital 👥, un miembro más de mi equipo de desarrollo, una extensión de mis capacidades o, como bien representa la imagen, mi sombra tecnológica 🌑.

No me sustituye ni creo que sustituya a ningún desarrollador en estos momentos. Claude Code es tan bueno como lo seas tú o como sepas utilizarlo 💡.

📋 Mis Reglas de Oro

Tengo cuatro reglas fundamentales que aplico religiosamente con Claude Code:

🔍 Control Total de Cambios

Yo reviso todo antes de implementar cualquier cambio
No tiene permisos para modificar archivos sin mi aprobación
Flujo: Me proporciona el plan → Reviso los cambios → Los entiendo → Los apruebo (o no)
Esta regla es súper importante para mí. Darle permisos ciegos no va con mi filosofía 🚫

📝 Claude.md como Biblia del Proyecto

Trabajo intensamente el archivo CLAUDE.md
Defino qué es el proyecto y establezco guidelines claras
Es mi manera de “entrenar” a Claude sobre mi estilo y preferencias
Resultado: Respuestas más alineadas con mi visión 🎯

⚙️ Configuración Inteligente

Configuro sus settings con rutas de documentación oficial
Cuando hago preguntas sobre tecnologías específicas, utiliza fuentes oficiales
Esto garantiza respuestas más precisas y actualizadas 📚

🚀 Trabajo Colaborativo, No Dependencia

Nunca parto de un IDE vacío
Siempre trabajo sobre una base de código que ya he desarrollado
Mi flujo: Empiezo a crear → Me atascos → Pregunto a Claude
Pregunta recurrente: ”¿Hay una manera más limpia y eficiente de hacer este código?” 🤝

💡 Imaginación sin límite

Y aquí viene lo interesante: Claude Code no es solo para programar 🎨. Puedes usarlo para lo que se te ocurra. Solo hazte esta pregunta:

¿Cómo puedo hacer que esta idea funcione con Claude Code?

Una de las formas más geniales en las que lo uso fuera de programación es con mi consumo de contenido técnico:

Consumo muchísimo contenido de programación:

🎓 Cursos online

💊 Píldoras de conocimiento

🎤 Conferencias y talks

🗣️ Debates técnicos

🎧 Podcasts especializados

🛠️ Talleres prácticos

El problema típico: Estás programando y recuerdas haber visto algo útil en un vídeo, pero… ¿cuál era? ¿En qué minuto? 😅

Mi solución con Claude:

Le pregunto: ”¿Dónde se habla de esto?”
Me devuelve:
- 📹 El vídeo o vídeos específicos
- ⏰ El timestamp exacto donde se menciona
- 📄 Un pequeño resumen del contenido

Resultado: ¡Maravilloso! ✨ Acceso instantáneo a todo mi conocimiento consumido.

🎯 Reflexión Final

Claude Code se ha convertido en mi sombra tecnológica. No es magia, no hace el trabajo por ti, pero si sabes usarlo correctamente, puede potenciar enormemente tu productividad y creatividad.

La clave está en establecer límites claros, mantener el control y usarlo como lo que realmente es: un asistente excepcional que amplifica tus capacidades, no que las reemplaza 🚀.

Keep coding, keep running 🏃‍♂️

Amo Vapor

2025-08-25T00:00:00Z

❤️ Swift del lado servidor

Cuando cursé el Swift Full Stack Bootcamp en Apple Coding Academy, uno de los módulos que se nos impartió fue Swift del lado servidor a través del framework Vapor.

Nada más comenzar con la parte teórica, mi corazón empezó a palpitar con fuerza y simplemente, a mitad de aquella primera clase, ya estaba completamente enamorado.

Así que, si me preguntan “¿Cuál fue tu módulo favorito del Bootcamp?”, sin lugar a dudas diría que este.

👍🏻 ¿Por qué me gusta?

Siempre he pensado que la parte de backend es el cerebro de cualquier aplicación o web.
Es ahí donde está toda la chicha: donde se procesa la información (normalmente desde una base de datos) y se prepara para que el usuario final la reciba de la forma más sencilla y transparente posible.

Que quede claro: no menosprecio el frontend.
De hecho, me parece admirable la gente que crea diseños increíbles: auténticos héroes para mí, porque eso es algo que personalmente me resulta imposible… aunque con SwiftUI me entiendo bastante bien.

🧸 Jugando con Vapor

En próximas entradas del blog iré profundizando mucho más, pero ya puedo contar que me he dedicado a jugar mucho con Vapor:

📦 Paquete individual para configurar distintos servicios

🌐 Servidor gRPC

🗂 Modelo de datos con vistas (incluidas materialized views), índices, permisos por aplicación y esquemas

🧮 Enumerados con migraciones automáticas

🔑 PassKey

📊 Bulk inserts para poblar grandes volúmenes de datos

⏱ Tareas programadas con asincronía

… y mucho más 🚀

A lo largo de distintas entradas del blog contaré un poco de todo.
Eso sí: aunque Vapor y Swift del lado servidor me guste mucho, no todo será sobre backend… habrá espacio para muchos otros temas que me entusiasman.

Keep coding, keep running 🏃‍♂️

¡Gracias, La Liga!

2025-08-18T00:00:00Z

Mi web bloqueada en partidos de La Liga

Si estás intentando visitar mi web durante un partido de La Liga y no carga, no te lo estás imaginando: en realidad, está siendo bloqueada.

En España, La Liga aplica medidas antipiratería muy agresivas, y una de ellas consiste en bloquear el acceso a sitios web alojados en la red de Cloudflare durante los partidos en directo. Desafortunadamente, esto significa que si tu web está alojada en Cloudflare —como la mía— puedes verte afectado aunque no estés emitiendo ni distribuyendo ningún contenido ilegal.

Cloudflare protege y acelera millones de sitios web en todo el mundo, pero debido a la política de La Liga, rangos enteros de IP o nodos CDN pueden ser incluidos en listas negras, lo cual afecta a innumerables webs legítimas.

¿Por qué sucede esto?

La Liga utiliza sistemas automatizados y bloqueos a nivel DNS para restringir el acceso a lo que considera fuentes potenciales de piratería.
Cloudflare es utilizado por todo tipo de sitios, incluidos aquellos que sí albergan retransmisiones ilegales —por lo que sus IPs se marcan.
Como resultado, muchas webs inocentes se bloquean durante los partidos, simplemente por compartir infraestructura.

¿Qué puedes hacer?

Si estás en España y no puedes acceder a mi portfolio durante un partido, vuelve a intentarlo más tarde.
Si te pica la curiosidad, existen herramientas online para comprobar si un dominio está siendo bloqueado.
O puedes usar una VPN para evitar temporalmente la restricción (solo para visitar mi portfolio, claro 😅).

Es un ejemplo frustrante de cómo una aplicación excesiva de medidas digitales puede dañar la web abierta —incluso portfolios pequeños como el mío.

”¡Gracias, La Liga!”

Actualización: Finalmente encontré una solución sencilla para este problema. Si quieres saber cómo lo resolví en 5 minutos, lee Only DNS.

Keep coding, keep running 🏃‍♂️

Mi primer artículo

2025-08-12T00:00:00Z

🚀 ¡Gran actualización en mi sitio web!

Hoy lanzo una importante actualización de mi sitio web personal, que ahora está construido con Astro y Tailwind.

He añadido la posibilidad de escribir artículos — ¡y este es el primero!
A partir de ahora, compartiré mis experiencias, descubrimientos y desafíos diarios como desarrollador Swift.
También puede que comparta algo de mi vida personal.

⚡️ Sin calendario fijo:
Publicaré siempre que tenga algo relevante que compartir — ya sean problemas, soluciones, curiosidades o nuevas tecnologías que esté explorando.

Con esta nueva versión, me puedo centrar únicamente en escribir artículos en Markdown; todo lo demás está completamente automatizado.

Si te interesa Swift, iOS, visionOS, Vapor, desarrollo full-stack con Swift y Web, o simplemente quieres acompañarme en este camino — ¡bienvenido!

Keep coding, keep running 🏃‍♂️