Jorge Calderita's Blog

Model Parts

2026-07-08T00:00:00Z

My Problem 🤔

When I write migrations with Fluent, indexes, foreign keys, and unique constraints are defined inside the migration’s prepare method. They belong to the migration, not to the model.

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()
}

The problem is that this information isn’t readable outside the migration. It’s part of a method that runs once and exposes nothing to the rest of the code. When I want to write an integration test that verifies the migration created the right indexes, where do I get the expected names from? I have to repeat them as strings in the test. And when I want to verify that the foreign keys exist, same thing: hardcoded strings, coupled to whatever lives inside prepare.

My model knows which table it represents. My model knows which fields it has. But it knows nothing about its own database structure: indexes, references, uniqueness. That information belongs to the migration, and the only way to access it is by running it.

My Solution 🧩

My idea is to turn the model into the single source of truth for all the structural metadata of its table. I created a SchemaDescribable protocol that extends Fluent’s Model with three static properties: indexes, foreign keys, and unique constraints.

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

Each kind of constraint has its own type with factory methods that make the declaration readable and safe. I declare the conformance in the database layer, not in the shared model:

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)] }
}

Each model explicitly declares all its B-Tree indexes, its foreign keys, and its unique constraints. Factory methods like .btree, .lower, .references, and .on make the declaration compact and hard to get wrong.

With the definitions in the model, the migration just applies them. An addConstraints(for:) method on SchemaBuilder adds the foreign keys and unique constraints, and createIndexes generates the indexes — all from what the model declares:

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()
    }
}

The migration no longer contains any constraint definition. It only declares the fields and delegates the entire structure of indexes, foreign keys, and uniques to the model through addConstraints(for:) and createIndexes. The MigrationProtocol protocol provides these methods thanks to the typealias ModelType, which connects the migration to its model and gives access to the SchemaDescribable definitions.

My Result 🎯

Now indexes, foreign keys, and unique constraints are properties of the model, not code buried in a migration. Any part of my project can read them.

The most immediate benefit is clean migrations. But the one that pays off down the line is that tests can talk directly to the model — in an upcoming article we’ll see how I use this to write integration tests that verify the database structure without a single hardcoded string.

A single place to read all the structural metadata of each model
Migrations without repetition — addConstraints(for: model) applies everything in one step
Localized changes — adding an index or FK only touches the model’s conformance

The key is recognizing that a model isn’t just a container of fields: it’s also the complete description of its table. SchemaDescribable makes explicit what used to be implicit — and belonged only to the migration.

Keep coding, keep running 🏃‍♂️

AI Status Bar

2026-07-01T00:00:00Z

My Problem 🤔

When I work with Claude Code in the shell, there is information I need to check constantly: how much context I have consumed, what percentage of my usage limits I am at, which git branch is active, which model I am working with. Information that does not change every second, but that I do need at hand to make decisions.

The problem is that getting it has friction. I can ask the AI directly, but that means spending tokens on a question whose answer is completely deterministic. I can also open another terminal session, or launch a background command to check it every so often. But all of those options interrupt the workflow.

What I really needed was something simpler: a line that is always visible, giving me that information without my having to ask for it, without consuming context, and without interrupting what I was doing.

My Solution 🧩

Claude Code has a feature called statusLine that lets you define an external command which runs whenever the session changes: after each assistant response, when a /compact finishes, when the permission mode changes, or when toggling vim mode. The tool calls the script, passes it information about the current session state as JSON over stdin, and displays whatever the script returns on stdout in the bottom bar of the interface.

The configuration lives in settings.json and is a single line:

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

The JSON the script receives over stdin contains all the relevant session information: active model, working directory, context usage percentage, total window size, and the usage limits for the 5-hour and 7-day periods, each with its percentage and reset timestamp.

The script runs on each of those events, with a 300 ms debounce that groups rapid changes. And here is an important detail: if a new event arrives while the script is still running, Claude Code cancels the in-flight execution and launches a new one — a slow script would interrupt itself. That is why I wrote it to be cheap: zsh builtins instead of subprocesses, a single call to jq instead of nine, and helpers that return their result in REPLY to avoid capturing it with $(…) on the hot path.

The first step is to load the zsh date module and extract the nine JSON fields in a single pass. The output of jq is an ordered list of values that I capture positionally with 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")

With that I have the nine variables populated with a single fork of jq. If the effort level did not come in the JSON, I look for it first in the project’s settings.json and, if it is not there either, in the user’s. Then I compute the derived values and build the progress bar with zsh’s native left-padding:

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:: :):-}"

Details that avoid child processes: ${current_dir:t} is the native equivalent of basename, and ${(l:filled::=:):-} builds a left-padded string of = characters with no loops or concatenation.

Then come the color thresholds. In the first version I had two almost identical functions, one for percentages and one for absolute tokens. I unified them into a single one that takes the value and the two thresholds as arguments, and took the chance to have it return the result in REPLY instead of printing it:

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
}

Applying those thresholds:

Green context below 100k tokens — safe zone
Yellow context between 100k and 150k tokens — a signal to consider a /clear
Red context above 150k tokens — time to act

The same for the 5-hour and 7-day usage limits: green below 50%, yellow between 50% and 79%, red from 80% on.

All three functions return in REPLY: this saves me the $(…) and its associated subshell on every call, which reduces the risk of an invocation cancelling itself when events arrive back to back. format_reset draws on the strftime builtin and on $EPOCHSECONDS from the zsh/datetime module, so it does not spin up a date process each time either.

Finally, the composition. The first line always carries the same elements: model, progress bar, context percentage, current tokens over the maximum, and project name. The second is built only from the parts that have data — if there is no 5h limit, no configured effort level, or no git branch, they simply do not appear and the separators adjust:

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"

The expansion ${(pj.$sep.)parts} joins the elements of the parts array with the sep separator — a native zsh join, with no loops or IFS hacks.

An important detail about the reset time: the script formats it as HH:MM if the reset happens within the next 24 hours, and as Day HH:MM if it is later. That way I know at a glance when the limit frees up without doing any math.

My Result 🎯

The result is exactly what I was after: information that is always present without interrupting anything or spending a single token to get it.

What I see at a glance at any moment:

Active model — which version of Claude the current session is using
Context bar — a visual representation of how much context I have consumed
Current tokens over the maximum — for example, 87k/200k, which tells me exactly where I am in the window
5h and 7d usage with reset time — to know whether I am approaching a rate limit and when it frees up
Effort level — visual confirmation that the session has the right level configured
Git branch — which branch I am working on in the active project

What I value most is that this information costs nothing. It is not a question to the AI, not a command I have to remember to run, not an extra window to open. It is text that appears, updates on its own, and fades from focus as soon as I get to work.

The approach also fits well with what I explored in Back to Shell: the shell as a space for composition, where scripts do the deterministic work and the AI does the contextual work. The status bar is the most visible example of that separation — all the formatting and color logic lives in the script, and the AI has no idea it exists.

If you work with Claude Code and have information you check repeatedly, the statusLine is the most efficient way to keep it always at hand. The script can show whatever you need: external API usage, the status of a service, environment variables, anything you want to expose from a shell command.

Keep coding, keep running 🏃‍♂️

Back to Shell

2026-06-24T00:00:00Z

My Problem 🤔

I started programming when the shell wasn’t an option, it was the place. There was no mouse, there were no windows. Just a blinking cursor, waiting for a command. I learned to think in text: input, output, pipe, redirection.

Then came the turn. The industry decided that productivity had the face of a window. Each discipline got its own program, with its own interface and its own learning curve:

Databases — their app with its panel and its tabs
Version control — another window, another way of seeing the same thing
Deployments — another dashboard, another account, other buttons
Observability — another panel, other charts, another subscription

The shell was relegated to “that thing used by people who know a lot” and to the tasks that graphical interfaces hadn’t yet conquered.

I went with the flow. I kept accumulating apps, dashboards and windows until I stopped visiting the shell. I dusted it off less and less often, until it only showed up when there was no other choice.

The problem arrived when I brought AI into my workflow. Not as a search engine or a snippet generator, but as an agent that acts on my environment. And that agent has no mouse. It doesn’t open windows. It works exactly like I did at the beginning: with text, with commands, with the shell.

The question left floating was uncomfortable: had I spent years learning graphical interfaces to do the same thing I was already doing when I started, but with more steps in between?

My Solution 🧩

The solution wasn’t a break. I didn’t slam windows shut or write an anti-interface manifesto. I just stopped resisting going back to the shell when the work led me there naturally.

The change started by observing. When an agent needs to inspect something, it doesn’t look for a pretty view — it writes a command. When it wants to see logs, it reads them with a pipe. It doesn’t care which app I prefer. It only cares about the result.

My first instinct was to correct it: “Wait, I have a graphical tool for that.” But when I stopped, I understood that I was adding friction where there was none. The agent knew what to run. I knew how to read the output. The interface added nothing — it only added steps: open, connect, navigate, find.

So I started doing the same on my own. Where I used to open a window, now I open a shell:

Checking a state — a direct command instead of a panel to load
Transforming data — I chain operations instead of exporting, opening and saving again
Automating a task — I write it once and reuse it anywhere
Reproducing a flow — I copy and paste text instead of explaining clicks

Not out of nostalgia, but because it’s faster and more composable.

That was the real mental shift: commands compose in a way graphical interfaces will never match. A window offers me what its designer imagined I would need. The shell gives me what I decide I need.

And there was something that surprised me: the knowledge was still intact. There was no need to study again. There was only need to dust it off.

My Result 🎯

The result hasn’t been a break with graphical interfaces. I still open windows when they offer something text can’t. But the shell has returned to the center of gravity of my workflow, instead of being the last resort.

What changed concretely:

Speed — a command is almost always faster than navigating to the equivalent option in a GUI
Composability — I can chain operations that no window contemplates in combination
Consistency with AI — we speak the same language; there’s no translation between what the agent runs and what I see
Portability — a command works the same locally, on a server and in CI

But what struck me most was the learning I didn’t have to do. I assumed going back to the shell would demand time and practice. That time had already been invested decades ago: the commands, the pipes, the redirection logic — it was all still there, waiting for an excuse to be used again.

AI didn’t teach me to use the shell. It reminded me that I already knew how.

The cycle that started with a tricycle, went through the rocket of graphical interfaces and returns to the fundamentals isn’t a step backward. It’s a circle that closes better than it opened. Sometimes the future of development isn’t about learning something new, but about rediscovering what we already knew how to do when we started.

Keep coding, keep running 🏃‍♂️

WWDC26 Group Labs

2026-06-17T00:00:00Z

My Problem 🤔

When I published my WWDC26 video guide, I devoted Block 17 to the Group Labs with barely a line of context per session. The reason was simple: Apple’s official descriptions are practically identical to one another —“Join us to dive deeper into WWDC26 with Apple engineers”— and they say nothing useful about what was actually discussed inside.

What I didn’t share back then is that, before writing that block, I had started watching the Group Labs and got a surprise. They are not passive sessions. They are live Q&A rounds between real developers and engineers from the Apple team, and the quality of the questions and answers is very different from that of regular sessions. In ordinary sessions, Apple shows what it wants to show. In the Group Labs, developers ask what they really need to know, and the engineers answer directly.

The problem is that this content is practically invisible. There are no transcripts, no index, no way to search inside the video. If you don’t sit down and watch the whole session, you don’t know what it covers.

I started taking notes. One session, then another, and I ended up with eighteen.

My Solution 🧩

I decided to transcribe and structure the content of each Group Lab: the topics asked about, the exact timecode, the summarized answer and which engineers took part. The goal was to have something searchable, something that would let me jump straight to the minute I care about instead of digging blindly through the video.

Before the list, three examples of what came up inside and that you won’t find in any main session:

In the Swift Group Lab, the language team explained why they would have designed concurrency differently if they were starting today, and what changed in Swift 6.2 to fix the model.
In the SwiftUI Group Lab, the engineers broke down when to use AnyView, how DynamicProperty runs before body, and why conditionals inside lazy containers are an antipattern.
In the Apple Intelligence Group Lab, the team explained the real differences between App Schemas and IndexEntity, and the current limits of video support in Foundation Models.

Here are all the available sessions, with a direct link to the official video:

Language and data

Swift Group Lab — Concurrency, performance, SwiftPM and language features.
SwiftData Group Lab — ResultsObserver, HistoryObserver, the new Codable, CloudKit sync, migrations and concurrency.

SwiftUI

SwiftUI Group Lab - Part 1 — Liquid Glass, data flow, layout performance and AnyView.
SwiftUI Group Lab - Part 2 — ForEach with large collections, NavigationTransition, Liquid Glass on buttons and adaptive layouts.
SwiftUI for Beginners Group Lab — SwiftUI vs cross-platform, @State internals and learning paths.

Tooling and performance

Xcode Tips and Tricks Group Lab — How to get the most out of Xcode 27.
Power and Performance Group Lab — Instrumentation, MetricKit and performance in production.

Platforms and web

visionOS Group Lab — Camera access, immersive debugging, USD export and spatial accessories.
watchOS Group Lab — Foundation Models on Watch, transitioning from iOS and on-device debugging.
Safari and Web Technologies Group Lab — WebKit, CSS Grid Lanes, Web Extensions and more.

Intelligence, ML and AI

Apple Intelligence Group Lab — Foundation Models, App Schemas, Siri and Evaluations.
Machine Learning & AI Group Lab — Foundation Models, Private Cloud Compute, Core AI, MLX and evaluations.
Coding Intelligence for Beginners Group Lab — Slash commands, Xcode versus external agents and context across projects.
Coding Intelligence, Machine Learning & AI Group Lab — Core AI vs Core ML vs MLX, context windows and background inference.

Quality and distribution

Accessibility Technologies Group Lab — VoiceOver, Dynamic Type and accessibility in custom controls.
Privacy and Security Group Lab — App Attest, Trust Insights and secure design of agentic features.
Camera and Photo Technologies Group Lab — AVFoundation, RAW capture and Center Stage.
App Store Connect Group Lab — In-App Purchase, subscriptions and StoreKit.

My Result 🎯

The value of the Group Labs is not in the official descriptions —it’s inside. Developer questions surface the use cases Apple doesn’t cover in the main sessions: the bugs the team acknowledges, the design decisions they explain off the record, the patterns they recommend in practice and not in marketing.

If you already have my video guide as a map of the catalog, the Group Labs are the layer on top: where Apple engineers really talk about what they built.

Keep coding, keep running 🏃‍♂️

WWDC26 Videos

2026-06-11T00:00:00Z

My Problem 🤔

Every year the same ritual: the Monday after the Keynote I open the WWDC26 videos and find more than a hundred sessions. Apple offers filters by topic, platform and framework that you can stack until the catalog fits your needs — a great starting point.

What happens to me is that, even with those filters active, if I don’t set my own order I end up jumping from video to video based on whatever title catches my eye in the moment. I watch a bit of SwiftUI, then I jump to AI, then I move on to tools, and by the end of the day I’ve consumed five disconnected sessions that don’t reinforce each other. Comprehension is shallow because each topic block needs prior context that I don’t have.

For a while I’ve wanted to put together my own scheme over what Apple offers. A path with a sense of direction, that builds knowledge cumulatively, that puts the things providing context for everything else first — and that also works as a checklist to tick off blocks as I progress throughout the year.

This year I’ve done it.

My Solution 🧩

My criterion is simple: first the overall vision, then the language core, then the tooling, and finally the specific areas based on what I use most in my work. Each block prepares the ground for the next.

I leave out only the ASL versions and the recaps (Dub Dub Daily, State of the Union recap). Everything else is in — including Group Labs, which although they were live interactive sessions, Apple keeps them in the catalog, so I leave them at the end as a topic reference.

What follows is the grouping I use, and that I tick off block by block throughout the year. If it works for you, make it your own: what matters is having a path to follow, not that it’s mine.

Block 0 — The presentations

Before any technical session, these videos set the frame for the year. The teaser whets the appetite; Keynote and State of the Union are the ones that matter.

Get ready for WWDC26
The pre-event teaser from WWDC itself. Marginal once you’ve seen the Keynote, but it’s in the catalog.

Keynote
The big announcement of the year. Liquid Glass, Apple Intelligence with the new Siri, Xcode 27 with code agents. Not technical — it’s the why behind everything else.

Platforms State of the Union
The Keynote for developers. Here the technical layer already shows up: what changes on the platforms, what priorities Apple has for this cycle, and what will matter for day-to-day work. This video is the map of the territory.

Block 1 — Swift and tooling

With the year’s context clear, I move into the core. Swift first because everything else is built on top of the language.

What’s new in Swift
Language update: ergonomic improvements, enhanced concurrency, safer high-performance code, Embedded Swift and C and Java interop. The state of the language in 2026.

What’s new in Xcode 27
Updates to the environment: code agents, Device Hub, localization, performance and testing tools. If I’m going to live here, I need to know what’s changed.

Get the most out of Device Hub
Deep tour of Device Hub: how it speeds up the development flow and how to quickly diagnose and reproduce issues with devices and simulators. The natural companion to the previous video.

Xcode, agents, and you
How to fold the Xcode code agents into a real workflow. From the initial prototype to polishing a finished app. The practical side of what was shown in the previous video.

Create UI prototypes using agents in Xcode
Prototyping with agents: techniques to iterate over layouts, generate creative solutions and refine ideas into a polished experience. The creative side of agents in Xcode.

Translate your app using agents in Xcode
How agents translate String Catalogs using the app’s context. Strategies to review the output and adjust localizations. The practical side for a global product.

Build, deliver, and automate with Xcode Cloud
What’s new in Xcode Cloud: simplified onboarding, cloud tests, webhooks and distribution. Fundamentals for anyone using it in CI.

Profile, fix, and verify: Improve app responsiveness with Instruments
A full flow to tackle performance problems: Swift Concurrency instrument, Time Profiler and System Trace. Find the bottleneck, measure the improvement, confirm the fix.

Meet the new MetricKit
MetricKit refreshed with vital performance metrics and actionable diagnostics. Cross-referencing metrics with app state via the StateReporting framework for the complete optimization picture.

Migrate to Swift Testing
Adopt Swift Testing alongside existing XCTests using framework interop. Patterns to introduce the new testing capabilities incrementally. Connects with what I cover in SIGBUS.

Block 2 — SwiftUI and persistence

The UI and data stack. I watch them together because in practice they go hand in hand.

What’s new in SwiftUI
New Document protocol with direct disk access, reorder APIs in lists and grids, toolbar improvements, new presentations, AsyncImage caching and lazy state for Observable. The overview of what’s new in the framework.

What’s new in SwiftData
Persistence of external types with Codable, grouping results into sections for SwiftUI, ModelResultsObserver and HistoryObserver to observe changes outside the view. The updates to Apple’s ORM.

Code-along: Add persistence with SwiftData
Hands on keyboard: adding persistence to an existing app step by step. Defining models, integrating persisted data with SwiftUI, managing app state. The best place to cement what was shown in the previous video.

Code-along: Build powerful drag and drop in SwiftUI
Building Solitaire to explore the new drag and drop capabilities: reorder API, drag containers to move multiple items, and a custom lifecycle. Practical and direct.

Dive into lazy stacks and scrolling with SwiftUI
List and scroll performance in SwiftUI. When to use lazy stacks, how to optimize scroll behavior, which patterns to avoid.

Compose advanced graphics effects with SwiftUI
Advanced graphics effects with SwiftUI. Layer composition, blending modes and visual effects that go beyond the basics.

Use SwiftUI with AppKit and UIKit
Incremental adoption of SwiftUI in existing AppKit or UIKit apps: the Observation framework to update views, integrating SwiftUI components into existing hierarchies, and adding full SwiftUI scenes without changing the architecture.

Modernize your UIKit app
Updating iPhone layouts to work well with iPhone Mirroring and on iPad. New tab and navigation bar APIs, preparing the app for Apple Intelligence, and a skill for the code agent that modernizes the codebase.

Block 3 — Apple Intelligence and Foundation Models

The block I’m most interested in this year. I watch it as a unit because each video builds on the previous one.

What’s new in the Foundation Models framework
Access to Private Cloud Compute, integration with third-party and open source models, vision capabilities, context management APIs, built-in semantic search and primitives for agentic experiences. The overview of Apple’s main AI framework.

Build agentic app experiences with the Foundation Models framework
Dynamic profiles, dynamic instructions, context management and orchestration patterns between local and server models. The advanced layer on top of the previous video.

Bring an LLM provider to the Foundation Models framework
Extending the framework by implementing a LanguageModelExecutor for new models. Interacting with the session transcript, managing state, optimizing the KV cache and supporting custom segment types. The door to integrating your own model into Apple’s stack.

Debug and profile agentic app experiences with Instruments
How to debug and profile agentic experiences with Instruments. Because when something fails in an agent, you need to know where and why.

Meet the Evaluations framework
In a probabilistic world, unit tests aren’t enough. Quantitative and qualitative metrics, model judges, aggregate statistics to ensure AI features work reliably.

Create robust evaluations for agentic apps
The advanced evaluations layer: flows with tool calling, dynamic conditions, synthetic data generation, judges and dataset validation. The real work behind getting an agent to behave correctly.

Improve your prompts by hill-climbing with Evaluations
Using the evaluation loop to improve prompts iteratively. The closing piece of the evaluations block.

Build AI-powered scripts with the fm CLI and Python SDK
Scripts with the Foundation Models CLI and Python SDK. Automation and prototyping outside the Swift environment.

Block 4 — Siri and App Intents

The bridge between the app and the system’s intelligence. I go from the conceptual to the practical.

Announcing Apple’s next big step for Siri and iPhone
The big announcement of the new Siri. The essential context before diving into the technical integration videos.

Discover new capabilities in the App Intents framework
ValueRepresentation, RelevantEntities, EntityCollection, SyncableEntity, richer parameter types and long-running intents. What’s new in the base framework.

Explore advanced App Intents features for Siri and Apple Intelligence
Advanced techniques so Siri can interact with the app naturally: content discovery, semantic indexing, structured search and connection with notifications and Now Playing.

Build intelligent Siri experiences with App Schemas
Adopt App Schemas so people can ask questions about app data and take actions through natural language. Practical example with calendar events and Spotlight.

Code-along: Make your app available to Siri
The code-along of everything above: integrating App Intents into a real calendar app, creating entities, triggering Siri actions and customizing response snippets.

Validate your App Intents adoption with AppIntentsTesting
AppIntentsTesting: validate intents with the same infrastructure used by Siri, Shortcuts and Spotlight. Execute intents, inspect results, test entities and queries without UI automation. The closing piece of the block — test what you’ve integrated.

Block 5 — Core AI and ML

For anyone who wants to go beyond high-level frameworks and step into the model layer.

Meet Core AI
The new framework for deploying AI models on device: a full ecosystem from Python for conversion and optimization to the Swift API for inference. Deep integration with Xcode and ahead-of-time compilation.

Integrate on-device AI models into your app using Core AI
A collection of open source models optimized for Apple silicon — Qwen, Mistral, SAM3 — and how to integrate them in a few lines of code. AOT compilation and on-device specialization.

Dive into Core AI model authoring and optimization
Authoring and optimizing models with the Python tools in Core AI. The deep layer for anyone who wants to control the full pipeline.

Optimize custom machine learning operations with Metal tensors
The Metal Tensor API and the MPP Tensor Ops library. Create portable operations that take advantage of the Neural Accelerators on M5 and A19, build custom kernels for Core AI apps and work with quantized formats. The low-level layer to push performance to the limit.

Explore numerical computing in Swift with MLX
MLX for numerical computing in Swift. The primitives everything else in ML builds on.

Explore distributed inference and training with MLX
Distributed inference and training with MLX. Scale to multiple Macs.

Run local agentic AI on the Mac using MLX
AI agents running locally with privacy, low latency and offline. OpenCode, integration with Xcode and techniques to scale across Macs.

Build with the new Apple Foundation Model on Private Cloud Compute
Using Apple’s new model on Private Cloud Compute. The end of the spectrum: when the device isn’t enough but privacy still comes first.

Block 6 — Networking, services and infrastructure

Three videos that cover the communication and runtime layer: from the client to the service, and the infrastructure that runs them.

Build real-time apps and services with gRPC and Swift
gRPC Swift for real-time experiences: the open source RPC framework with bidirectional streaming, built on Swift concurrency. From the service definition in Protobuf to production deployment. Protobuf messages are 50% smaller than JSON and the runtime is modern and safe.

Discover container machines
Container machines on Apple platforms. Infrastructure for development and deployment of Swift services.

Expand the capabilities of your Virtualization app
New capabilities in macOS 27 for Virtualization apps. Automating macOS guest setup at first boot, USB accessory passthrough, custom network topologies and port forwarding.

Block 7 — Design and accessibility

The layer you don’t see but that defines whether an app is good or not.

Principles of great design
The foundational principles of Apple app design. The conceptual frame before diving into concrete APIs.

Communicate your brand identity on iOS
Express brand identity on iOS with the new visual personalization tools.

Design intuitive search experiences
Designing searches that people understand and use. Patterns and antipatterns.

Craft clear names for features and labels in your app
Naming features and labels. One of those videos that seems minor and ends up being among the most practical.

Refine accessibility for custom controls
Accessibility on custom controls. How to make what you build work for everyone.

Modernize your AppKit app
Modernizing AppKit to current macOS conventions. Input with control events and gesture recognizers beyond tracking loops, keyboard navigation, state restoration, and new corner concentricity APIs to fit the macOS aesthetic.

Block 8 — System integration

The APIs that put my app inside the system: surfaces like Live Activities, widgets, Lock Screen or CarPlay; integration with native apps (Workouts), Bluetooth accessories, and shortcuts. If the app lives beyond its own window, this block is relevant.

Live Activities essentials
Fundamentals of Live Activities: where they show up, the new landscape Dynamic Island style, how to structure content and data, and how to trigger them in real time with ActivityKit and push notifications. The foundation if I’m going to use this API.

WidgetKit foundations
The widget types, what makes them memorable, and how to keep them up to date. Personalization via App Intents and dynamic styles. If the app needs to live outside its icon, start here.

Create live communication experiences
LiveCommunicationKit turns real-time communication apps into integrated experiences. Native conversation UI, full-screen presentation on Lock Screen, multitasking with Dynamic Island. Incoming, outgoing and group conversations.

Rev up your CarPlay app
New features for audio, navigation and voice-driven conversation apps on CarPlay. Video apps to play content in compatible vehicles when parked. Thumbnails, media info and voice controls.

Deliver workout insights with HealthKit workout zones
HealthKit with workout insights — heart-rate zones and cycling power zones. Built-in or custom zones, current zone and time in each zone to guide during and after training.

Find your accessory with Bluetooth Channel Sounding
Channel Sounding adds distance and direction to Bluetooth accessories. New Nearby Interaction and Core Bluetooth APIs and the required changes on the accessory. Optimized power consumption without losing responsiveness.

What’s new in Shortcuts
Building shortcuts with app content, new system automations, and the Use Model feature to refine how an App Entity is presented to LLMs. Shortcuts that store rich information synchronized across devices.

LLM search using Core Spotlight
Turning basic search into a RAG system with SpotlightSearchTool and LanguageModelSession. Integration with Core Spotlight, delegate-based hydration, PipelineStages for tasks like sentiment analysis. Real contextual search over the system index.

Block 9 — Security and administration

Five videos that matter more than ever this year. With all the added AI, assuming that app integrity, prompt injection or user manipulation aren’t your problem is a risk. And for apps living in managed environments — education, enterprise, fleet — the admin posture matters too.

Secure your app: mitigate risks to agentic features
Evaluating threats from indirect prompt injection: data exfiltration, unintended actions. System safeguards and best practices with App Intents and Foundation Models — user confirmations, safe prompt design, authentication. A must if I have agentic features.

Secure your apps with App Attest
App Attest against unauthorized modification and fraud. How attackers spoof data and skip checks, and how to defend. Generating and managing keys in the Secure Enclave, validating attestations and assertions, and using the fraud metric to detect abuse.

Meet Trust Insights
Trust Insights uses privacy-preserving ML to detect when someone might be being manipulated into risky actions. Integration, signal interpretation and designing interventions that protect while respecting privacy.

What’s new in managing Apple devices
Updates to declarative device management, Apple Business and Apple School Manager. Streamlining deployment, strengthening security and improving the managed fleet experience.

What’s new in assessment on macOS
Automatic Assessment Configuration on macOS for education apps. APIs to create secure, configurable exam environments that incorporate more system features. Automatic prechecks and accessibility controls for a reliable exam experience.

Block 10 — visionOS, RealityKit and spatial content

The largest block in the catalog. I only watch it if I’m working with Vision Pro or if I want to experiment with spatial scenes. If it’s not my area, I leave it for later.

Build next-generation experiences with visionOS 27
The visionOS 27 overview: the different paths to build experiences — native Apple tools, immersive streaming from Mac or PC, third-party engines, porting iOS apps. Advances in 3D content creation, immersive media and object tracking. The video to start the block with.

Explore advances in RealityKit
What’s new in RealityKit: interactive cloth simulations, NavMesh pathfinding, mixed reality lighting, customizable reverb meshes for spatial audio. Better shading, character rendering and support for Gaussian splatting.

Design immersive environments for visionOS apps and the spatial web
Creating photorealistic environments for visionOS apps, websites and SharePlay experiences. Design principles, reference capture, high-fidelity CG asset preparation and real-time effects like motion and lighting.

Iterate your spatial scenes faster with Reality Composer Pro 3
What’s new in Reality Composer Pro 3: content, VFX, lighting and interactivity without leaving the editor. AI-assisted features integrated into the flow. The tool you’ll live in if you build spatial content.

Extend Reality Composer Pro 3 functionality with Xcode
Project-specific plugins in Reality Composer Pro 3: custom components, custom systems, custom ScriptGraph nodes. Full control over the spatial authoring workflow.

Discover the Spatial Preview framework
The new Spatial Preview framework sends content from Mac directly to visionOS. Live-syncing and bidirectional editing across platforms. The SpatialPreview API, device discovery, 2D/3D integration and new Quick Look capabilities.

Explore enhancements to visionOS object tracking
Advances in object tracking and spatial accessories. Tracking moving and handheld objects, new supported classes of spatial accessories, and how to build custom accessories to unlock unique interaction models.

Collaborate on structured 3D models in visionOS
Structured 3D models in visionOS: USDZ preparation, manipulating entities within hierarchical assemblies, inspecting with a cross-section cut plane. Exploded-view animations for design and collaboration on Vision Pro.

Discover USDKit and what’s new in OpenUSD
USDKit in Swift, the new spatial preview API, enhanced spatial web. Updates to the OpenUSD standard: accessibility, Gaussian splats, compressed geometry. Expanded USD editing and rendering tools in Preview for Mac.

Use foveated streaming to bring immersive content to visionOS
Foveated streaming: scenes rendered remotely to Vision Pro in maximum fidelity. Combines native capabilities with third-party streaming wirelessly, demonstrated with an OpenXR scene and NVIDIA CloudXR. Dynamic foveated streaming without compromising privacy.

Explore immersive website environments in visionOS
The new Immersive API in JavaScript takes your website visitors into virtual environments on Vision Pro. Transitions from an inline model element, video docking, real-scale optimization. A few lines of code running on the web.

Supercharge your spatial workflows with Reality Composer Pro 3
Rich interactivity and full visual effects inside Reality Composer Pro: Shader Graph for materials, Animation Graph for blending skeletal animations, Compute Graph for particles. Script Graph for interactivity, Sequencer for events and Behavior Trees for NPCs.

Build live production tools for Apple Immersive Video
Live production of Apple Immersive Video. Packaging immersive video, spatial audio and scene metadata for IP transport with the SMPTE 2110 standard. Immersive Media Support, Video Toolbox and AVFoundation for real-time flows.

Block 11 — Games and Metal

If I work on a game, this block is a mandatory stop. If not, I watch it out of curiosity because there are performance pieces that also apply to non-game apps.

Bringing Cyberpunk 2077 to Mac
How CD PROJEKT RED brought Cyberpunk 2077 to Mac taking advantage of Apple hardware, software and tools. Techniques applicable to other games. The For this Mac preset that automatically optimizes settings to balance visual fidelity and framerate across the Mac lineup.

Speedrun your game port with agentic coding
The new agentic skills in Game Porting Toolkit 4 speed up porting. Adopting Metal 4, integrating MetalFX, tuning the game for Apple hardware. Agents that diagnose GPU rendering issues autonomously.

Make your game great with touch
Convincing touch controls for games. Insights from indie to AAA devs, best practices, and how to take advantage of the Touch Controller framework and Metal for optimal performance.

Design no-code games with Reality Composer Pro 3
ScriptGraph in Reality Composer Pro 3 for no-code 3D content. Visual nodes for animations, interactive moments, and integration with SwiftUI to add speech bubbles and UI to the experience.

Build real-time neural rendering pipelines with Metal
ML integrated into the rendering pipeline with Metal 4. MetalFX neural denoising with insights from Maxon Redshift Live. Training and deploying a neural tone mapper inline with the ML command encoder, and the new tensor API for small networks inside your shaders.

Find and fix performance issues in your Metal games
Hunting performance problems with Metal tools: Game Performance Overview in Instruments, background traces with metalperftrace and Control Center, and the new StateReporting API to correlate metrics with the game’s runtime state. Hours of telemetry turned into actionable insights.

Block 12 — Camera, photography and imaging

For apps with camera or image processing. Some videos are very specific (RAW, Center Stage), others apply even if I’m just displaying a preview.

What’s new in image understanding
Updated Vision framework and Foundation Models. The new tap-to-segment request to segment images, Vision on watchOS, and image support in the Apple Foundation Model combined with OCR, barcode scanning and custom tools.

Best practices for integrating visual intelligence in your app
How Visual Intelligence transforms content discovery. Defining entities, processing images, handling multiple result types. Optimizing speed and relevance, and intents for direct actions like opening or playing content with a tap.

Build a responsive camera app that launches quickly
Optimizing the full camera startup sequence — from launch to the first preview frame. New APIs for faster launches, smooth rendering and sustained performance. So people never miss the moment.

Implement high resolution photo capture
High-resolution photo capture with AVFoundation. The three options — RAW, exposure-bracketed, fully processed — and when to use each one. Configuring 24MP and 48MP capture on Main, Tele and Ultra Wide cameras. Deferred photo processing so the app stays responsive even with rapid bursts.

Enhance RAW image processing with Core Image
Version 9 of Core Image’s RAW APIs: sharper detail, more defined color, Apple Neural Engine for performance. CIRAWFilter to edit exposure, noise, sharpness and contrast. New CIImageProcessor APIs with fine control over tile sizing and buffers.

Support the Center Stage front camera in your iOS app
Center Stage with AVCapture APIs on the front camera of iPhone 17, 17 Pro and Air. Zoom and rotate, flexible framing for selfies and videos, everyone framed in group photos. Integration into video calls with auto-framing and real-time stabilization.

Create high quality images using Image Playground
Image generation with Image Playground. Generative model on Private Cloud Compute, images in almost any style including photorealistic, specific dimensions, and modification through natural language and touch.

Block 13 — Web and Safari

For web devs: what’s new in WebKit and the new pieces of CSS and HTML that Safari premieres this year.

What’s new in WebKit for Safari 27
The overview of WebKit and Safari 27: Grid Lanes, Customizable Select, HTML Model, Immersive Environments, the latest in Web Extensions. Over 1,000 engine improvements to make the web more reliable.

Get started with the HTML Model Element
The model element brings interactive 3D content to web pages on iOS, iPadOS, macOS and visionOS. Tools to create and optimize 3D assets, model element features, and where web standards in 3D are heading.

Create web extensions for Safari
Build and test Safari web extensions from scratch — without Xcode. Content blocking, page modification, native messaging and the permissions mode working together for a powerful, privacy-respecting experience.

Learn CSS Grid Lanes
Grid Lanes for adaptable web layouts with elements of varied shapes. Clean and flexible CSS, plus flow-tolerance to refine accessibility without losing malleability.

Rediscover the HTML select element
Full styling control over select menus on the web. New CSS appearance value and new pseudo-elements, rich content inside options with new HTML possibilities. Selects tailored to the design system without giving up accessibility or robustness.

Block 14 — StoreKit, App Store, subscriptions and Wallet

For everything that touches monetization and App Store Connect. If I sell anything in my app, this block matters.

What’s new in Apple In-App Purchase
The new monthly subscriptions with a 12-month commitment as a more affordable option. Configure and test with App Store Connect, StoreKit APIs and Xcode testing. Improvements to offer code redemption and to the App Review experience.

Enhance your presence on the App Store
Reimagining marketing on the App Store using images and videos in new places. New visual placements on the product page, search results and Apple Ads campaigns. The new Asset Library centralizes assets and a tool lets you preview the product page before publishing.

What’s new in Wallet
New pass styles for rich designs. New barcode formats and a flexible pass actions API. Pass Designer and Pass Builder simplify designing, personalizing and distributing passes at scale.

Explore Retention Messaging in App Store Connect
Retention Messaging to reach subscribers before they cancel. Configure it in App Store Connect, add subscription offers, and use the API for real-time messaging and alternatives that encourage them to stay.

Unlock in-game content with StoreKit and Background Assets
Native In-App Purchases in Unity with the new StoreKit plug-in. Smaller download sizes with the Background Assets plug-in delivering per-language packs. And a Steam Asset Converter to migrate existing builds.

Offer subscriptions to groups and organizations
Group Purchases: one subscriber buys multiple seats and invites others from the app. Volume Purchasing via Apple Business and Apple School Manager puts your subscriptions in front of enterprise and education buyers who already purchase apps at scale.

Block 15 — Music, audio and subtitles

For apps with multimedia content. There’s a new framework this year (Music Understanding) worth attention even if you don’t build music apps.

Meet the Music Understanding framework
The new Music Understanding framework that analyzes audio across six dimensions, on-device: key, rhythm, structure, pace, instrument activity and loudness. Plus a sample app, Music Understanding Lab, to visualize results.

Integrate MusicKit into your app
Apple Music inside your app with MusicKit. Authorization, subscription, music selection, playback control and sharing songs across storefronts. New Music Picker to browse the catalog and personal libraries. Differences between SystemMusicPlayer and ApplicationMusicPlayer.

Discover generated subtitles and subtitle styles
Generated subtitles on-device that transcribe or translate from another language. Caption style preview to customize and preview during playback. Implementation with AVKit, AVPlayerLayer and Media Accessibility.

Meet the Now Playing framework
The new Swift Now Playing framework connects your app’s playback with system surfaces: Lock Screen, Control Center, Dynamic Island, CarPlay. Publish state, respond to commands via an observable API, and remote playback sessions to render media on external devices.

Block 16 — Accessibility, reading and text

The text and reading layer. This isn’t just new APIs — it’s how the app fits with each person’s preferences.

Enhance the accessibility of your reading app
Robust reading experiences for VoiceOver and Speak Screen. Intuitive text selection, clear navigation between lines and paragraphs, and continuous reading across elements and pages.

Prepare your tvOS apps for Dynamic Type
Dynamic Type on tvOS: implementing font scaling, adapting layouts for large sizes, optimizing grids and media-focused carousels. So any text size remains comfortable.

Elevate your app’s text experience with TextKit
Combining the convenience of built-in text views with the control of TextKit. New APIs to extend UITextView and NSTextView with custom behaviors like line numbers or collapsible sections. TextKit architecture, caching and reuse policies for text attachments.

Unwrap PaperKit
Canvas-based applications with PaperKit. New data model APIs to access, create and modify markup elements. Custom controls, annotations, and best practices to integrate a full creative canvas.

Read between the strokes with PencilKit
Handwriting recognition with the same technology behind Freeform and Notes. Recognition across many alphabets and languages, and new capabilities to integrate PencilKit into more types of apps.

Block 17 — Group Labs

The Group Labs were live Q&A sessions with Apple engineers and designers during the event week. Apple keeps them in the catalog even though the interactive session is over, so they serve as a quick reference for whichever area I’m working on. The official descriptions are essentially the same boilerplate, so I group them by topic with a one-line context.

Language core and main frameworks
- Swift Group Lab — Q&A on the week’s Swift announcements.
- SwiftUI Group Lab and SwiftUI Group Lab (second round) — Two Q&A sessions on the SwiftUI announcements.
- SwiftUI for Beginners Group Lab — Q&A to get started with SwiftUI from zero.
- SwiftData Group Lab — Q&A on the SwiftData announcements.
Xcode, performance and platforms
- Xcode Tips and Tricks Group Lab — Q&A to get the most out of Xcode.
- Power and Performance Group Lab — Q&A on the power and performance announcements.
- visionOS Group Lab — Q&A on the visionOS announcements.
- watchOS Group Lab — Q&A on the watchOS announcements.
- Safari and Web Technologies Group Lab — Q&A on the Safari and web technologies announcements.
Intelligence, ML and AI
- Apple Intelligence Group Lab — Q&A on the Apple Intelligence announcements.
- Machine Learning & AI Group Lab — Q&A on the ML and AI announcements.
- Coding Intelligence for Beginners Group Lab — Q&A to get started with coding intelligence.
- Coding Intelligence, Machine Learning & AI Group Lab — Combined Q&A on coding intelligence, ML and AI.
Platform, distribution and design
- Accessibility Technologies Group Lab — Q&A on the accessibility announcements.
- Privacy and Security Group Lab — Q&A on the privacy and security announcements.
- App Store Connect Group Lab — Q&A on the App Store Connect announcements.
- Camera and Photo Technologies Group Lab — Q&A on the camera and photography announcements.
- Icon Composer for Beginners Group Lab — Q&A to get started with Icon Composer.

My Result 🎯

With this order I skip the catalog chaos and start seeing results from the first week.

My summarized sequence:

Block 0 — The presentations
Block 1 — Swift and tooling
Block 2 — SwiftUI and persistence
Block 3 — Apple Intelligence and Foundation Models
Block 4 — Siri and App Intents
Block 5 — Core AI and ML
Block 6 — Networking, services and infrastructure
Block 7 — Design and accessibility
Block 8 — System integration
Block 9 — Security and administration
Block 10 — visionOS, RealityKit and spatial content
Block 11 — Games and Metal
Block 12 — Camera, photography and imaging
Block 13 — Web and Safari
Block 14 — StoreKit, App Store, subscriptions and Wallet
Block 15 — Music, audio and subtitles
Block 16 — Accessibility, reading and text
Block 17 — Group Labs

If you’ve been watching WWDC for years you know the catalog never expires — the videos are available all year at developer.apple.com. June is for the new stuff, the rest of the year for going deep. As I covered in WWDC 26, the technical sessions are the main course — and now I already have my own checklist to tick off as I go.

Keep coding, keep running 🏃‍♂️

Claude Voice

2026-06-10T00:00:00Z

My Problem 🤔

I have a problem with spoken expression that has been with me my whole life: when I talk, ideas pile up on me. My head moves faster than my voice. I start saying something, another related idea pops up, then another, and before I finish the first sentence I’ve already lost the thread. The result is that I express myself worse than I think.

Writing, on the other hand, gives me time. Writing is slow by nature, and that slowness forces me to organize. While my finger searches for the letter, the thought settles. That’s why ever since I started using Claude Code intensively, I’ve always worked with text. The keyboard is my natural filter layer.

That worked well until it stopped working.

I had an accident in a trail race. A silly fall, not-so-silly consequences, weeks of recovery, and what hurt most at the time: little mobility to type normally. All at once, my preferred way of working was blocked.

I had two options: either I used my voice or I accepted that I was going to work at an absurdly slow pace. It wasn’t a philosophical choice about modes of communicating with AI. It was pure necessity.

My Solution 🧩

I started using voice with Claude Code by force, without romanticizing the process. The first few days were exactly as bad as I expected. Cut-off sentences, ideas arriving in the wrong order, context lost along the way. The model responded well, but I was giving it mediocre material.

What I discovered right away is that the problem wasn’t the transcription tool, it was me. I didn’t know how to structure a thought for verbalizing before verbalizing it. With the keyboard I correct myself on the fly without noticing. With voice, the mistake comes out and that’s it.

So I changed my approach. Instead of trying to improvise, I started mentally preparing what I was going to say before speaking. No scripts, just a second of silence to organize:

What context does the model need?
What exactly do I want it to do?
What constraints should I mention?

That second of pause was the biggest change. It’s exactly what I do with the keyboard unconsciously, but with voice I have to do it consciously and explicitly.

The other thing I learned is that voice favors brevity. When I write, I tend to add nuances. When I speak, I get to the point because keeping a long sentence in my head is exhausting. And it turns out Claude responds just as well to concise prompts as to detailed ones, as long as the context is clear.

What I ended up doing was a kind of informal protocol for voice sessions:

Start with the what before the how
One idea per turn, no chaining requests
If the response isn’t what I expected, reformulate from scratch instead of correcting on top

With that schema, the sessions started to work. Not perfect, but functional.

My Result 🎯

There are situations where voice clearly wins. When I’m thinking out loud about an architecture, when I want to explore several options before writing code, when I need to describe a behavior that’s easier to narrate than to specify. The keyboard is still my primary mode, but voice is no longer the last resort.

What changed is that I learned to structure better before speaking. And that, curiously, also improved how I write prompts. The habit of pausing, of organizing before emitting, transferred over.

The accident forced me to train a skill I never would have trained voluntarily. Not because I didn’t know it existed, but because I had a comfortable alternative that I always used. When the alternative disappears, you surprise yourself with what you’re capable of learning.

If you work with language models regularly and have never tried voice, you don’t need to break anything to give it a shot. A week of voluntary keyboard restriction is enough to see if there’s something worthwhile there. It took me an accident to discover it. You have the advantage.

Keep coding, keep running 🏃‍♂️

WWDC 26

2026-06-03T00:00:00Z

My Problem 🤔

Every June I hear people talking about the big premiere of the season. The summer movie, the new season of some show, the sequel they had been waiting on for years. And I nod and think about my own thing: in a few days WWDC arrives.

My problem is that it’s very hard to explain that feeling to someone outside Apple’s development ecosystem. Saying you’ve had the date marked on the calendar for weeks, that you take Keynote day as a holiday, that your nerves go up as the hour approaches — said without context, it sounds odd. For anyone who doesn’t program in Swift, a two-hour keynote talking about APIs is the furthest thing from a movie premiere.

It’s not just nerd stuff. WWDC has something no premiere has: what they announce directly affects my work, the decisions I made six months ago that will now get an official answer. When the lights go down in my private screening room, I’m not just another spectator — I’m the target audience.

My Solution 🧩

I stopped trying to justify it. WWDC is my premiere of the year, and I enjoy it more than any movie or TV show. I have a blast like a kid.

The week before

It starts before Monday. Rumors peak, the community is in full speculation mode, and I’ve spent days thinking about what they’re going to announce and how it will affect what I’m working on. It’s the same energy as the week before a highly anticipated premiere, with one fundamental difference: the outcome actually matters to me — as someone whose job changes based on what’s announced.

The Keynote as a ritual

In Spain, the Keynote hits at 7:00 PM. The perfect hour — I wrap up the workday, early dinner, and from then on only the Keynote exists.

My ritual includes a screen setup that would look absurd from the outside. On the main one, Apple’s official stream. On a second one, a group of nutters doing live commentary — they comment every slide, predict the next, react in real time. And on a third, I follow X, technical blogs, and developer Slacks and Discords: nuances missed in the slides and first analyses of the real impact.

What I love most is that the Keynote mixes two things that rarely go together: the thrill of the show and the technical information that changes my work. I process every feature on two levels at once — spectator enjoying it and developer already thinking about how to integrate it.

And then there are the “yes!” moments — when they announce something you’d been asking for. Last year, with the improvements to Swift Concurrency, I jumped off the couch. Literally.

The sessions are the real content

The Keynote is the appetizer. The technical sessions are the main course, and they last for weeks.

I go through the catalog like someone browsing the lineup of a film festival. With over a hundred sessions, selecting and prioritizing is an activity in itself. And they don’t expire: Apple keeps them on developer.apple.com indefinitely. June is for the new stuff, and the rest of the year is for going deeper into the ones I left for later.

This connects with Swift Pills: dense knowledge that deserves to be consumed at a calm pace. And with Apple Coding Speed: the comprehension speed you train is what lets you get the most out of every session.

The betas as a playground

The day of the Keynote, the betas open up. From there the game begins: install, compile against the new SDK, see what breaks, explore the APIs before they have complete documentation. It’s early access, but I’m the one playing while I develop — and what I discover can shift design decisions I’ve been mulling over for months.

The community in WWDC mode

The technical conversation among Apple developers goes through the roof. Everyone has something to comment on, something they discovered, some detail that changed how they saw a problem.

The conferences in the ecosystem — like the ones I follow in Conferences 25 — have that energy, but WWDC takes it to the extreme: it’s the moment of the year when the entire community looks at the same thing at the same time.

My Result 🎯

I no longer try to explain it. I accept that WWDC is my event of the year and I enjoy it without hang-ups.

What it gives me every June:

Genuine anticipation — the event that directly affects my work
The Keynote as a show — two hours in dual mode: spectator and developer
Technical sessions that last months — dense material I consume calmly the rest of the year
The betas as a lab — early access to the new APIs before anyone else
The community at its peak — the richest technical conversation of the year
Answers to problems sitting on your desk — unmatched satisfaction

If you have an event of the year that makes you feel like a kid, don’t justify it. Enjoy it. Mine is WWDC, and I’m already looking forward to the next one.

Keep coding, keep running 🏃‍♂️

Swift Pills

2026-05-27T00:00:00Z

My Problem 🤔

Keeping up with Swift is one of those things I always have on the list and almost never manage to cross off. Every WWDC brings new stuff, the language evolves, the community publishes non-stop, and meanwhile I’m with the project, with the meetings, with life. The information exists — the problem is finding the gap to get into it.

And almost all the technical content comes in big formats: fifty-minute videos, entire WWDC sessions, mile-long articles, books. All of that demands time and focus, and in my day-to-day I don’t always have either of the two. What ends up happening is that I keep saving links “for when I have a moment” — and that moment never comes.

My Solution 🧩

Arturo Rivas’s blog changes the way you consume content about Swift. What he publishes are knowledge pills: short articles, around five minutes of reading, where he tells you one specific thing and then leaves. No detours, no filler, no “before we begin, allow me to set the context”.

And what’s hooked me the most is that most of the time they’re pills about things you hadn’t even stopped to consider. Language details, subtle behaviors, APIs that had been there for versions and you’d never crossed paths with. Things that when you read them you think “huh, didn’t know that” — and from that point on you don’t forget them.

Five minutes change the equation

That they’re five-minute pills isn’t a minor detail — it’s what makes it work. I don’t need to reserve a slot, I don’t need to switch into study mode, I don’t even need to be at the computer. I read them between tasks, while waiting for a build, with the morning coffee. Learning stops competing with work and slips into the margins of the day.

And since each pill goes to a single thing, retention is brutal. When an article is long I need to process it in depth, sit down to study it and go over it several times so it sticks. When I read a pill about, for example, how @discardableResult works or some detail of Sendable I hadn’t seen, that concept goes in directly. It was the only focus during those five minutes, and my head treats it as such.

Things you hadn’t even considered

This for me is the most valuable thing about the blog. Arturo doesn’t write about “what is Swift” nor about things that are already in any tutorial. He writes about corners of the language, about behaviors that have their reason but that normally you don’t stop to investigate, about APIs that get covered up by each year’s big announcements.

It’s the kind of knowledge you don’t actively look for because you don’t even know it exists — but once you have it, it changes the way you read and write code. You realize there’s a better pattern, a tool that had been available for a while, a detail that explains why something behaves the way it does.

It fits into my flow without asking for permission

I started treating the pills as a natural part of the day, not as a separate task. Five minutes before getting down to business, another five between two meetings, while Xcode compiles something heavy. Without the feeling of “now I have to learn” — just letting them in when there’s a gap.

The contrast with long formats is brutal. For a WWDC video I need to plan it, sit down, have full attention. For a pill, I just open it when the chance appears. And it turns out the chances are far more frequent than I thought.

This connects with something I already covered in Apple Coding Speed: comprehension speed isn’t trained only in long courses. It’s also trained through constant exposure to well-explained concepts — and the pills are exactly that, continuous training that happens between more structured sessions.

My Result 🎯

If you work with Swift and your “for when I have a moment” links are piling up, the problem probably isn’t the amount of content — it’s the format. Drop by blog.arturorivas.com and try the pill model for a week.

What I’ve taken away:

I learn things I wasn’t even looking for — most of the pills touch on details I wouldn’t have searched for on my own, and they’re the ones that have given me the most
Knowledge enters effortlessly — five minutes fit into any gap, so learning stops depending on planning
What I read sticks — a single concept per pill makes retention much higher than with long articles
I recognize patterns faster — when I come across an API or a pattern I saw in a pill, I identify it without having to search for it
No more “I have to read this” debt — low-threshold content gets consumed in the moment, it doesn’t get postponed

If you want medicine of the new kind, you have it in knowledge pills here. Five minutes, one idea, one thing you probably hadn’t considered. You’ll hardly find a better ratio between time invested and learning that sticks.

Keep coding, keep running 🏃‍♂️

Apple Coding Speed

2026-05-20T00:00:00Z

My Problem 🤔

When I decided to specialize in the Apple ecosystem, I was looking for approachable training with a very specific profile: rigorous, professional, structured, and backed by an active technical community. Not another introduction to SwiftUI, but the complete ecosystem — Swift Concurrency, server-side, accessibility, AI agents — at the level of the official documentation.

That search led me to Apple Coding Academy, a benchmark in specialized training for native development with Apple technologies. And, once inside, a more interesting question appeared than the one that had brought me there: what does structured training from Apple Coding Academy give me that reading the documentation on my own would not?

The answer took longer than expected to arrive, and when it did, it was not what I anticipated.

My Solution 🧩

What Apple Coding Academy’s training gave me was not the knowledge. It was the speed.

Not execution speed — that is a byproduct. Speed of comprehension. Speed of analysis. Speed to reach the core of a problem before it expands. And that speed, once you have it, transfers to everything.

What you really train at Apple Coding Academy

When you enter a structured program at Apple Coding Academy — whether the Swift Developer Program, the Swift Agentic Engineering Program, or any of their courses — the first thing you notice is the pace. It is high. Concepts pile up fast because there is a designed curve, an order that maximizes retention.

The result is that after several courses, when I come across a new API in Swift, I do not process it the way I did before. The pattern recognition is faster. I see the method signature, identify the protocols it implements, infer the behavior before reading the documentation. It is not intuition — it is trained speed.

Speed of comprehension

The first thing that changes is how you read code. Before the training, reading an unfamiliar Swift file was a sequential process: line by line, chasing references, building the mental model slowly.

After enough hours of training, reading approaches scanning. You identify the patterns — async/await, protocol composition, the structure of an actor — before processing the detail. Comprehension time collapses.

That matters more than it seems. Now, with the use of AI, I spend more time reading code than writing it. If reading and understanding speed goes up, delivery time goes down without quality changing.

Speed of analysis

The second thing that changes is how I analyze problems. Apple Coding Academy’s training has a trait that I found uncomfortable at first: the problems are not well defined. You have a goal, a set of tools, and the expectation that you are the one who traces the path.

That trains something specific: separating what matters from what does not before you start working. Identifying the real point of friction, not the surface symptom.

In my day to day, that training translates into not jumping straight to fixing what is visible when a bug or an architecture decision appears. First I analyze. The analysis is faster because I have more trained context. The solution arrives sooner and with fewer iterations.

Speed of development

The third thing that changes is execution. When comprehension and analysis are faster, development is too — not because I write faster, but because, with the use of AI, I write less code by hand and spend that time reviewing and steering what the model proposes. Less exploration code, fewer discarded prototypes, fewer refactors of things that should never have been written that way.

Apple Coding Academy’s training carries this in its DNA: Apple’s design philosophy rewards clarity and economy. Less surface for the same behavior. You absorb that even if nobody explains it to you explicitly — you pick it up from the ecosystem.

The courses I have taken at Apple Coding Academy

I have gone through several stages within the Apple Coding Academy catalog. The Bootcamp gave me the fundamentals of the ecosystem: types, memory management, Swift Concurrency, protocol composition, integration with native frameworks. Five months of immersion that cover the full path to a professional Apple development profile.

Then came more specific courses: server-side modules with Swift, accessibility, and the visual redesign with Liquid Glass. Each module targets a different layer of the stack and demands a level of depth I rarely reach on my own by just reading.

More recently, the Swift Agentic Engineering Program — sixty hours focused on developing AI agents, MCP, Spec Driven Development, and the Foundation Model Framework. Training that does not exist in the official documentation because it combines pieces that are still being defined in the ecosystem.

Each layer added something different. The fundamentals gave me the vocabulary. The server courses gave me the perspective of what happens when the code is in production under real load. The system design ones taught me to think in seams — the points where behavior can vary without what is behind it changing. The agent ones gave me the framework to integrate AI into development workflows rigorously.

What they have in common is that they all forced me out of my comfort zone at a speed I would not have sustained alone. That is what I cannot get from self-taught documentation: the external pace.

The compound effect

The interesting thing about this speed is that it compounds. You do not add hours of training linearly — the layers reinforce each other.

Fast comprehension accelerates analysis because you process more context in less time. Fast analysis accelerates development because you reach the real problem sooner. And cleaner development reduces future maintenance time.

The return is not in the first months. It is in year three, when you look back and confirm that the level of decisions you make in five minutes used to take you an afternoon.

This connects directly with what I explore in Claude Code: AI amplifies what you already know. If your understanding of the ecosystem is deep, the model’s suggestions are more useful because you know how to evaluate them. If it is shallow, the model hands you code that compiles but you do not understand. Training makes AI a better tool, not the other way around. That is precisely the bet behind Apple Coding Academy’s Swift Agentic Engineering Program: train the judgment before delegating to the model.

My Result 🎯

The answer to the question I asked myself — what does training from Apple Coding Academy give me that the documentation alone would not — is this: the pace. The designed pressure. The environment that forces the fast connection of pieces.

The documentation gives you the what. The training trains you the how and, above all, the speed with which you reach the why.

What I notice in my work now:

Faster diagnosis — I identify the real problem before touching code
Fewer iterations — design decisions arrive before writing the first line
More efficient code reading — I process unfamiliar files without going line by line
Sounder judgment — I know when a pattern is correct for the context and when it is just familiar
Better use of AI — I evaluate the model’s suggestions because I understand the ecosystem deeply

Keep coding, keep running 🏃‍♂️

Save Tokens

2026-05-13T00:00:00Z

My Problem 🤔

I work with Claude Code every day and started to notice a pattern that caught my attention: every time a skill or a conversation needed to run something in the shell, the AI burned tokens before executing anything. It reasoned about which command to build, drafted it, launched it, read the output, and then interpreted it to keep working.

In a one-off operation, that cost is barely noticeable. The real problem shows up the moment there is repetition. A skill that iterates over several files, a conversation that reorganizes directories, a flow that needs to perform the same operation with different arguments — all of that multiplies the reasoning cost by each iteration. Every loop pass rebuilds a command that, at heart, is identical to the previous one except for a single parameter.

And here is the key point: that reasoning is deterministic work dressed up as reasoning. I am not asking the AI to decide anything — only to rewrite a command it has already written before. It is exactly the kind of task a script solves better than a model.

My Solution 🧩

The idea is simple: if a skill or a flow needs to run shell logic, that logic should not live in the AI’s head — it should live in a .sh file that the AI invokes with a single line.

The mental shift

The natural instinct when configuring a skill is to describe step by step what the AI has to do:

List the files in the directory, filter the ones ending in .json, read each one, extract the version field, find the largest, and return it.

That description forces the AI to build each command, execute it, interpret the output, and chain the next step. Instead, the instruction should be:

Run the script latest-version /path.

The difference is that all the reasoning about how the operation is done stops happening on every invocation. It happens just once, when you write the script. From then on, the AI only needs to know what to run and what format to expect back.

Why loops are the critical case

The savings show up even in one-off operations, but they become huge when the skill iterates. Without a script, every loop pass pays the cost of reasoning and building the command. With a script, the AI fires a single invocation and gets back the full aggregate.

The practical rule I apply: if the operation can be aggregated in a single shell step, the script should do it — not the AI iterating externally.

The structure I use in my skills

Each of my skills follows the same shape: a short SKILL.md describing the contract, and a scripts/ folder with the packaged logic.

~/.claude/skills/
└── my-skill/
    ├── SKILL.md          ← instructions for the AI (what to run, what to expect)
    └── scripts/
        ├── operation-a.zsh
        └── operation-b.zsh

Every time the skill needs a new capability, I add a script instead of adding inline bash instructions. The skill gains functionality without bloating the context the AI has to process on every invocation.

I use .zsh because I work on macOS, where it has been the default shell since Catalina and lets me take advantage of features bash does not have. The pattern works exactly the same with .sh and bash. Pick the one that matches your environment.

And one important detail: I write the scripts with the help of the AI itself, just once. That reasoning — designing the right command, handling the edge cases, returning the proper JSON — happens while creating the script. After that, the work stays crystallized in the file and is never paid for again.

My Result 🎯

The change is directly observable as soon as you separate deterministic logic from reasoning. The AI shifts from building commands to consuming them. From interpreting variable outputs to reading structured JSON. From iterating externally to receiving the full aggregate in a single call.

The concrete benefits I am seeing:

Fewer tokens per invocation — the reasoning about how to perform the operation happens just once, when writing the script, not every time the skill runs
Consistency — the script always returns the same format; the AI does not interpret variable outputs on every execution
Maintainability — when the logic changes, I edit the script in one place; the SKILL.md is not touched
Scalability in loops — the script aggregates before returning; one call replaces N iterations
Simpler skills — the SKILL.md describes what to do, not how; operational complexity lives in the scripts

The pattern applies to any skill or flow that has to operate on the filesystem, process structured text, or run repetitive logic. If you find yourself describing in the SKILL.md a sequence of bash commands the AI should build and execute, that sequence should probably be a script.

As I explored in the article on Claude Code, the key is not to give the AI more reasoning capacity so it solves more things — it is to structure the work so that it only reasons where it adds value. The deterministic part is solved by a script. The creative and contextual part is solved by the AI. Each in its place.

Keep coding, keep running 🏃‍♂️

UUID v7

2026-05-06T00:00:00Z

My Problem 🤔

In my project I use PostgreSQL as the database and UUID as the identifier on every model. It’s the usual standard: universal, collision-free, secure. But I ran into a problem when my tables started to grow.

UUID v4 is fully random. That means each new record is inserted at a random position inside the B-Tree index. The index becomes fragmented, pages split, and write performance degrades progressively. On tables with millions of records, the impact is real.

The solution has existed for a long time in databases like MongoDB with ObjectID or in systems that use ULID: embed the timestamp into the identifier so new records always get inserted at the end of the index.

UUID v7, defined in RFC 9562, brings exactly that to the UUID standard. PostgreSQL 18 already includes the native uuidv7() function. But Swift — and by extension Fluent — still generates UUID v4 by default with UUID().

If the identifier is generated by my application before persisting it, I’m losing the v7 benefits even though my database already supports it.

My Solution 🧩

I decided to create an extension on UUID that implements UUID v7 generation directly in Swift, following the RFC 9562 specification.

Monotonic state

The first thing I need is a shared state that guarantees two UUIDs generated within the same millisecond are distinct and ordered. I use a Mutex from the Synchronization framework to make it thread-safe without resorting to DispatchQueue or actor:

import Foundation
import Synchronization

private let v7State = Mutex(V7State())

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

UUID generation

The main extension implements the static method v7() that generates a UUID compliant with 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)
    }
}

The structure of the generated UUID respects the RFC 9562 specification:

Bytes 0–5 (48 bits): timestamp in milliseconds since epoch, big-endian. This is what guarantees chronological order.
Byte 6 (high nibble): version 0x7 — identifies the UUID as v7.
Bytes 6–7 (lower 12 bits): sequence counter. Guarantees monotonicity within the same millisecond.
Bytes 8–15 (64 bits): random, generated with SecRandomCopyBytes, with the two highest bits of byte 8 forced to 0b10 to mark the RFC 4122 variant.

The monotonic logic inside withLock works like this: when two calls happen in the same millisecond, the counter is incremented. If the counter reaches the maximum (0x0FFF, that is 4095 UUIDs in a single millisecond), the implementation actively waits for the next millisecond before continuing — it never generates two identical UUIDs.

Inspection utilities

In addition to generation, I added two properties to inspect any UUID: one that checks whether it is v7 and another that extracts the embedded timestamp:

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 verifies that the high nibble of byte 6 is 0x07 (version 7) and that the two highest bits of byte 8 are 0b10 (RFC 4122 variant). v7Timestamp reconstructs the 48 bits of the timestamp from bytes 0–5 and converts them into a Date.

My Result 🎯

Adoption is immediate. In any Fluent model, all I have to do is replace UUID() with UUID.v7() in the initializer:

// Before
self.id = UUID()

// After
self.id = UUID.v7()

The database type does not change — it’s still UUID. Fluent needs no modification. The change is completely transparent to the ORM.

The benefits I got are direct:

Ordered indexes — new records are always inserted at the end of the B-Tree, eliminating fragmentation
Native chronological ordering — ORDER BY id is equivalent to ORDER BY created_at without an extra column
Embedded timestamp — I can extract when a record was created directly from the UUID with v7Timestamp
Backward compatible — the format is still standard UUID; any system that accepts UUID v4 accepts v7
Thread-safe — works correctly from multiple concurrent threads thanks to the Mutex

let id = UUID.v7()

print(id.isV7)          // true
print(id.v7Timestamp!)  // the creation date embedded in the UUID

And if you’re already on PostgreSQL 18, the native uuidv7() function generates UUIDs with the same structure. UUIDs generated from Swift and from PostgreSQL are interchangeable and comparable to each other.

The change from UUID() to UUID.v7() is a one-liner. The advantages, permanent.

Keep coding, keep running 🏃‍♂️

SIGBUS

2026-04-29T00:00:00Z

My Problem 🤔

I’m writing tests with Swift Testing, Apple’s native stack. I compare two models with #expect(a == b) and verify errors with #expect(throws: MyError.self) — the API the library ships with out of the box. I run the tests. And my binary dies with this:

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

SIGBUS. It’s not an assertion failure. It’s the Swift runtime breaking inside the test runner itself. And it only happens when a test fails — if everything passes, I never notice the problem.

The pattern is very specific. The runtime crashes when I use #expect(==) on enums with associated values, or when I use #expect(throws:) on an error type that is an enum with associated values. As soon as the test fails, swift-testing tries to build the error message by asking the runtime to reconstruct the type metadata of the values it compared. And there it blows up: _swift_buildDemanglingForMetadata, signal 10, end of story.

It’s bug swiftlang/swift#76608, open since September 2024 and reproducible on Swift 6.3.1 on macOS 26 — both in debug and release.

The curious thing is that the happy path never touches this bug. If the comparison passes, there’s no error message to format, no Mirror, no SIGBUS. The bug only shows up exactly when you need the test output the most: when something fails. And I couldn’t move a single piece forward until I solved it.

My Solution 🧩

The key clue is where swift-testing crashes: on the failure message path, formatting the values. If I do the comparison myself and only pass swift-testing a Bool, there’s nothing for it to reconstruct. No metadata to reflect on. The mirror doesn’t break because it’s never used.

The trick that avoids the SIGBUS fits in two lines:

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

That’s the whole idea. I compute the equality myself, swift-testing only receives an already-resolved Bool. With no values to reflect on, there’s no Mirror, no SIGBUS. The price is losing the values in the failure message — but I get that back by formatting the text by hand before passing it to Issue.record.

From there I built a TestKit package with three helpers that apply the same idea to the three cases where I was tripping over the bug:

expectEqual(actual, expected) — comparison of any Equatable: structs, models, enums with associated values. Replaces #expect(a == b) across every test in the monorepo.
expectThrows(E.self) { … } — verifies that a closure throws an error of the expected type. It does do/catch by hand and checks with catch is E — only the type, never the value. Covers what #expect(throws:) tried to provide out of the box. Has both sync and async overloads.
expectEqualLines(actual, expected) — line-by-line diff for verifying generated SQL and other inline snapshots. The comparison is also reduced to Bool before touching the reporter.

Three helpers, one single idea: compute the result outside the macro, pass only the boolean. When Swift 6.4 eventually closes issue 76608, I just have to swap the body of the helpers for direct #expect calls and the suite won’t even notice.

There’s one extra detail to keep failure messages readable: I conformed the error and schema types to CustomStringConvertible with a static switch over the cases — never interpolating (self), because that would invoke Mirror again and reopen the trap.

My Result 🎯

My test suite runs again without SIGBUS and with reasonably readable failure messages. The rule I now apply across the monorepo:

expectEqual(a, b) for any comparison between structs, enums or models
expectThrows(E.self) { … } to verify the type of error thrown
#expect(…) directly only when the argument is already Bool, nil or contains — there’s no value metadata to reflect on, and the bug is not triggered

The benefits:

A suite that doesn’t crash — failures count as failures, not as process aborts
Minimal stack — I only depend on Testing and Swift’s own toolchain
Custom messages — I control how each side is printed on failure, thanks to CustomStringConvertible
Runtime bug isolation — when Swift 6.4 fixes it, I just swap the body of the helpers and the suite won’t even notice

The lesson I’m taking away: when a runtime tool breaks on the error path, the solution isn’t to give up on the language, it’s to keep the tool from going down that path. I do the comparison myself, I pass a boolean to the reporter, and the mirror stays intact.

Keep coding, keep running 🏃‍♂️

Two Bigs

2026-04-22T00:00:00Z

My Problem 🤔

I consume a lot of tech content. Podcasts, live streams, newsletters, articles. And over time I’ve developed a filter I can’t turn off: within the first thirty seconds I can tell whether the person speaking feels passion for what they’re saying or is simply repeating what they’ve read.

And most of the time, it’s the latter.

I’m not talking about technical quality. There’s content that is well produced, well structured, with great titles, that bores me deeply. Because there’s no one behind it who gets excited about what they’re saying. It’s content manufactured to exist, not because someone needed to tell it.

When there’s no passion, I lose interest in less than a minute. I don’t care how relevant the topic is. If the speaker doesn’t vibrate with what they’re saying, neither do I. And it’s not a conscious decision — it’s a physical reaction. My brain disconnects and there’s no way back.

My Solution 🧩

I’m always actively searching for content within my areas of interest. Technology, development, AI, Apple, and so on. And I always give what I find a chance, because I know what it takes to create. Behind every video, every podcast, every article there are hours of work, preparation, and decisions. That deserves at least an honest try on my part.

But I don’t have all the time in the world, so I’ve naturally ended up applying three filters.

Passion. If in the first few seconds I don’t sense that the speaker cares about what they’re saying, my attention shuts off on its own. No passion, no attention.
Manners and respect. I want to learn from someone who argues without attacking and disagrees without belittling. Passion without respect is noise.
Satisfaction. That when it’s over I feel I’m taking something with me. A new idea, a perspective I didn’t have before. If not, I don’t come back.

My Result 🎯

These filters have left me with a short list of favorites. And on that list are Julio César Fernández and Oliver Nabani.

When the stars align and these two come together for a live stream, Un futuro sin apps, something happens that doesn’t happen with anyone else. I enjoy it like a kid. I laugh out loud. I talk to the screen. I rewind to jot down on paper something they dropped in passing that I want to look into later. I’m bursting to go to the bathroom but I don’t pause the video because I don’t want to miss a single sentence.

And always, always, when it’s over I think the same thing: “they were only on for fifteen minutes, they keep making these shorter.” I check the clock. Almost three hours. I didn’t even notice time passing.

That’s passion. That’s what I’m looking for. That’s what these two transmit every time they sit in front of a camera together.

Two greats. Two passions. Two friends. And the rest of us are their guests.

Keep coding, keep running 🏃‍♂️

Astro to Saga

2026-04-15T00:00:00Z

My Problem 🤔

My portfolio was running on Astro with Bun. Everything worked fine. Fast, comfortable, no technical complaints.

But something didn’t feel right. Every time I opened the project I found a package.json, a tailwind.config, an astro.config, and a node_modules folder with hundreds of dependencies I didn’t even know existed. That feeling of losing control over what lives inside your own project bothers me. I like to know what my code runs and why it’s there. I had already removed Tailwind in a previous migration to vanilla CSS, but the rest of the JavaScript ecosystem was still there.

And at the end of the day, I’m a Swift developer. My daily work is Swift. Yet to generate my own portfolio I depended on a completely foreign ecosystem. If someone visited my repository, they wouldn’t see a Swift developer. They’d see just another JavaScript project.

The question was simple: if I trust Swift for everything else, why don’t I trust Swift for this?

My Solution 🧩

I stopped to think about what I actually needed. My portfolio is not a web application. It has no state and no complex interactivity. It’s a set of static HTML pages generated from Markdown. I don’t need React, Vue, or hydration. I need something that reads Markdown, transforms it into HTML, and writes it to disk.

I found Saga, a static site generator written in Swift. Deliberately minimalist: it reads files, applies transformations, and writes HTML. What it doesn’t include, you decide. It also features hot reload for development, something I didn’t expect to find in such a small project. That philosophy convinced me more than any feature list.

Advantages	Disadvantages
Entire stack in Swift — one language, no context switching	Small ecosystem — if something doesn’t exist, you build it yourself
Compiler-verified HTML thanks to the typed DSL	Learning curve with the DSL syntax
Native image pipeline with no external dependencies	Image pipeline only works on macOS
Node removed from the local environment	Limited community and documentation
Full control over every dependency in the project	More upfront work for features that come out of the box in other frameworks

The underlying reflection

The decision wasn’t technical. It was about coherence. I want anyone visiting my repository to see Swift. I’m not saying Astro is bad — it’s excellent. But my portfolio is my business card, and that card has to speak about me.

My Result 🎯

The site you’re reading right now is generated with Saga, compiled with Swift, and deployed on Cloudflare Pages without Node ever touching my machine.

What surprised me wasn’t the technical outcome. It was the feeling of coherence. Opening my portfolio and seeing that everything, from the first line to the last deploy, is Swift gives me a sense of calm that’s hard to explain.

If you’re a Swift developer and your portfolio runs on Node, I’m not saying you should change. I’m saying it’s worth asking yourself why. In the end, the tool you choose to present yourself says something about you. I chose the one that represents me.

Keep coding, keep running 🏃‍♂️

My First Macro

2026-04-01T00:00:00Z

My Problem 🤔

In my project I have dozens of Fluent models, and there is a block of code that repeats in absolutely every single one of them:

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?

Always the same block. In every model. No exceptions.

The namespace changes, but the structure is identical. With every new model, I copy and paste, adjust the namespace, and hope I don’t forget anything. With 30 models, that boilerplate becomes noise that makes it harder for me to read what actually matters: the model’s logic.

My solution in Swift for this kind of problem is a macro.

My Solution 🧩

A Swift macro can generate new members in a class or struct at compile time. Exactly what I need. The result I’m looking for is to write this:

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

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

And have the compiler automatically inject space, id, init(), and the three timestamps. Without writing them. Without maintaining them.

Package structure

Swift macros require two separate targets: the public interface (what I consume as a developer) and the plugin (the implementation that the compiler executes). In my case, both live in the same Macros package:

Macros — declares the macro and the DatabaseSpace enum
MacrosPlugin — implements the expansion with SwiftSyntax

DatabaseSpace — namespaces as types

Before defining the macro, I need to model the available namespaces. Instead of using loose strings, I decided that the DatabaseSpace enum should make them exhaustive and safe at compile time:

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

This allows writing @FluentModel(.sales) instead of @FluentModel(“sales”). If the namespace doesn’t exist, the compiler tells you before anything runs.

The macro declaration

The public interface of the macro is surprisingly compact:

@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"
)

The @attached(member, names:) attribute tells the compiler two things: that this macro adds members to the declaration where it’s applied, and exactly which names it will generate. Declaring the names is mandatory — Swift needs them to resolve the symbol tree before expanding the macro.

The implementation — FluentModelMacro

The implementation conforms to the MemberMacro protocol and returns an array of DeclSyntax — fragments of Swift code that the compiler inserts into the model:

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)"
    }
}

The expansion method directly returns the array of declarations, with no intermediate variables. Each element is a Swift literal that the compiler injects as-is into the model.

The key is spaceDecl, which encapsulates all the extraction and generation logic in a single method. It navigates the attribute’s syntax tree with SwiftSyntax using optional chaining: it accesses the arguments as LabeledExprListSyntax, takes the first expression, casts it to MemberAccessExprSyntax (because the argument is an enum case like .sales), and with .map converts it into a quoted string. If any step in the chain fails, the ?? operator returns “nil”. Finally, \(raw:) interpolates the value directly into the DeclSyntax.

Lastly, I need a CompilerPlugin to register the macro — it’s the entry point that the compiler loads to know which macros are available:

import SwiftCompilerPlugin
import SwiftSyntaxMacros

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

My Result 🎯

With the macro installed, each model is clean and noise-free:

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

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

The compiler expands @FluentModel(.sales) and automatically generates:

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?

And if a model doesn’t belong to any namespace — like views — you simply omit the argument:

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

In that case, space is generated as nil and Fluent ignores the schema prefix.

The benefits in numbers: 32 models with the macro applied. 6 lines removed per model. Over 190 lines of boilerplate that no longer exist in the repository and will never need to be maintained again.

Keep coding, keep running 🏃‍♂️

DB Admin vs Dev

2026-03-23T00:00:00Z

My Problem 🤔

In many projects I’ve seen how application code ends up doing things it shouldn’t: creating roles, configuring database server parameters, managing instance-level permissions. Everything mixed in the same place, as if it were a single responsibility.

But it’s not. The database has two distinct worlds: administration and development.

Mixing them is one of the most common mistakes, and also one of the most expensive. A developer configuring the instance from their code is crossing a boundary that doesn’t belong to them. And an administrator trying to decide which tables or schemas the application uses is doing the same from the other side.

My Solution 🧩

The separation is conceptually clean: administration belongs to the server, development belongs to the code.

The administrator’s territory

The administrator manages the database instance. Their work includes:

Server configuration — performance parameters, instance-level extensions, settings that require a restart
Roles and credentials — creating users, assigning secure passwords, defining who can connect
Databases — creating them, setting timeouts, revoking default access

All of this is infrastructure. These are decisions made once, executed by someone with superuser privileges, and they have nothing to do with business logic. Ideally, they live as versioned SQL scripts in the repository, but separate from the application code.

The developer’s territory

The developer manages the application’s data structure: schemas, tables, indexes, views, and everything that needs to exist for the application to work.

This responsibility is expressed through migrations — versioned, reversible, and reviewable pieces of code like any other change. It doesn’t matter if you use Swift, Python, Go, or TypeScript: the principle is the same. Your application’s data structure must be automatically reproducible in any environment.

The gray area: admin or development?

There are cases that seem ambiguous. Database roles are a good example. The role itself — with its password and connection permissions — is an infrastructure concept. The administrator creates it.

But permissions on specific tables — what it can read, what it can write, on which schema — that depends on the developer. The table has to exist before it can have permissions, so those permissions go in migrations, not in infrastructure scripts.

The rule I apply is simple: if the object exists before the application, it’s administration. If its existence depends on the application creating it, it’s development.

My Result 🎯

When you apply this separation, the setup process becomes clear and reproducible:

The administrator prepares the instance → server configured, roles created, database ready
The developer runs the migrations → schemas, tables, and application permissions applied automatically

Each layer has its own tool. The administrator doesn’t touch the application code. The developer doesn’t need superuser credentials. Nobody steps on the other’s territory.

This separation also makes teamwork easier: the administration scripts are run by whoever has server access, just once. The migrations are run by any developer on the team in their local environment, as many times as needed.

The database is not yours alone as a developer. But the data structure of your application is.

Keep coding, keep running 🏃‍♂️

Migrate Spaces

2026-03-14T00:00:00Z

My Problem 🤔

In the previous article about Schemas and Spaces we saw how to assign a namespace to a model using the space property. Many of you asked the same question: how are those spaces created in the database?

The most common answer was to do it manually, running a CREATE SCHEMA in the PostgreSQL console before launching the migrations. It works, but it breaks something fundamental: if the database doesn’t exist or the environment is new, the process fails before reaching the actual migrations.

The other problem is that managing namespaces manually doesn’t scale. As soon as you have multiple environments (development, staging, production) or a team, keeping that manual sync becomes a source of silent errors.

My Solution 🧩

The solution is to turn namespace creation into just another migration. This way, it runs automatically in the correct order, is reversible, and is versioned alongside the rest of the code.

The key lies in combining FluentKit with SQLKit. FluentKit manages the migration lifecycle, but to execute arbitrary SQL we need to access the underlying driver through the SQLDatabase protocol. To keep the code organized, we encapsulate the namespaces in an enum with an action that determines whether they are created or dropped:

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)
    }
}

Some important details:

SRSchema as CaseIterable: by iterating over allCases, we ensure all defined spaces are created without having to list them manually in the migration. Adding a new space only requires adding a case to the enum.
Action: the inner enum models the two possible operations (create and drop), allowing the same execute method to be reused in both the migration’s prepare and revert.
Switch expression: a Swift switch expression is used to select the SQL template based on the action. Each branch returns a closure that generates the corresponding statement, keeping the logic compact and readable.
CREATE SCHEMA IF NOT EXISTS: makes the migration idempotent. If the schema already exists, it doesn’t fail — it simply continues.
DROP SCHEMA … RESTRICT: in the revert, the RESTRICT modifier prevents dropping a schema that contains tables. It’s a safety net that avoids accidental data loss when reverting.
unsafeRaw: used to interpolate the schema name directly into the SQL. It’s safe here because the value comes from our own enum, never from external input.

My Result 🎯

This migration must be the first one registered. Before creating any table, the namespaces need to exist. In the migration runner, the order looks like this:

fluent.migrations.add(
    SchemasMigration()
)

When running migrations in a new environment, the entire process is automatic:

And if at any point you need to add a new domain, you just add a case to the SRSchema enum and the next time migrations run, the schema appears. No touching the database manually, no extra documentation to maintain.

Keep coding, keep running 🏃‍♂️

Tailwind to CSS

2026-03-07T00:00:00Z

My Problem 🤔

My portfolio had been running perfectly with Tailwind CSS for months. Everything was fine. Styles were in place, components looked great, and the site loaded fast. So why change? Because working well and working the best way possible are two different things. When you stop to analyze what’s under the hood, you sometimes discover you’re carrying a layer you don’t need.

Don’t get me wrong: Tailwind CSS is an amazing tool. I’ve used it in professional projects and will keep using it where it makes sense. But in a personal portfolio built with Astro, I started noticing a few things:

Unnecessary dependency: 3 extra packages (tailwindcss, @tailwindcss/vite, @tailwindcss/typography) for a project that didn’t really need them
Abstraction layer: Tailwind generates CSS from utility classes. It’s a layer between what you write and what the browser interprets. In a small project, that layer adds overhead without adding value
Extra weight: The generated CSS included utilities I wasn’t always taking full advantage of. ~20KB extra that the user downloaded unnecessarily
Less control: When you want something very specific, you end up fighting the framework instead of writing exactly what you need

My Solution 🧩

The idea was simple: remove Tailwind and replace it with vanilla CSS using a design tokens system built on CSS custom properties.

What are design tokens? They’re CSS variables that define your design system:

: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;
}

With this, I get consistency across the entire project without depending on any framework. Just pure CSS that the browser understands directly.

The process meant migrating 38 files in a single commit. Each Astro component went from using Tailwind classes to having its own scoped <style> block:

Before (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>

After (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>

More lines? Yes. Clearer and more maintainable? Absolutely.

The migration wasn’t just “remove Tailwind and add CSS.” There were interesting pitfalls worth sharing.

Scoped styles and <slot>

In Astro, styles inside <style> are scoped by default. This means each component receives a unique attribute (data-astro-cid-*) and styles only affect that component.

The catch: content passed via <slot> does not receive that attribute. If a parent component tries to style slotted content, the styles won’t apply.

The solution: use :global() for selectors targeting slotted content:

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

opacity vs background transparency

With Tailwind, I used classes like bg-opacity-70. When migrating, my first instinct was to reach for the opacity property. Mistake: opacity affects the entire element, including its children.

The correct solution: color-mix() for background-only transparency:

.modal-overlay {
  /* BAD: affects everything */
  opacity: 0.7;

  /* GOOD: only the background is transparent */
  background-color: color-mix(in oklab, var(--color-gray-900) 70%, transparent);
}

My Result 🎯

The numbers speak for themselves:

~20KB less CSS delivered to the browser
3 dependencies removed from package.json
0 abstraction layers between your code and the browser
Faster builds by eliminating Tailwind’s processing step
Full control over every line of CSS generated

The package.json went from having tailwindcss, @tailwindcss/vite, and @tailwindcss/typography to no styling dependencies at all. Just pure CSS. And the best part: the tailwind.config.mjs file was completely removed. One less configuration to maintain.

The styling system ended up organized into 4 CSS files:

File	Responsibility
design-tokens.css	Colors, typography, spacing, shadows, transitions
base-reset.css	Minimal CSS reset and utilities like .sr-only
prose.css	Blog content typography with dark mode support
layout.css	Global layout classes (.bodyLayout, .mainLayout)

All imported from a single global.css. Clean, predictable, and no black magic.

Migrating from Tailwind CSS to vanilla CSS isn’t for everyone or every project. In large teams or projects with many developers, Tailwind remains a fantastic choice for its consistency and development speed. But in a personal project like a portfolio built with Astro, where performance matters and full control is a luxury you can afford, removing that abstraction layer is liberating. In fact, I ended up taking this philosophy even further and migrated the entire portfolio from Astro to Swift — I tell the full story in Astro to Saga.

It’s like painting a picture: you can use templates and tools to guide you, or you can pick up the brush and create exactly what you have in mind. Both options are valid. But when the canvas is yours, painting by hand has its charm.

Keep coding, keep running 🏃‍♂️

Cupertino MCP

2026-02-11T00:00:00Z

My Problem 🤔

When I develop for iOS, macOS, or any Apple platform, I know the drill:

I’m coding peacefully
I need to check how something works in SwiftUI
I open Safari / my favorite browser
I search on Google / DuckDuckGo
I land on Apple’s official documentation
I read, understand, go back to my IDE
I repeat this process 47 times a day

Or even worse: I ask my favorite AI and it gives me outdated or straight-up hallucinated information because its knowledge isn’t up to date with the latest versions of Swift or SwiftUI.

What if I told you there’s a better way?

My Solution 🧩

Cupertino MCP is a tool that locally indexes all of Apple’s documentation and makes it available to my AI through the Model Context Protocol (MCP).

In plain English: it’s like giving my AI (Claude, in my case) a direct, verified gateway to all of Apple’s official documentation.

How much documentation are we talking about?

302,424+ pages of official documentation

307 frameworks indexed

9,699 Swift packages cataloged

606 sample code projects from Apple

Complete Human Interface Guidelines

Swift Evolution proposals (~400 proposals)

Apple Archive guides (legacy but valuable documentation)

All of this, available offline, no internet needed, and with zero risk of AI hallucinations.

My Result 🎯

Absolute precision

When Claude answers me about Apple APIs, it no longer guesses. It searches the real official documentation and gives me 100% verified information.

No more: “I think in SwiftUI 6 you use it like this…”

Now it’s: “According to the official SwiftUI 6 documentation…”

Development speed

Before:

Question → Wait for response → Doubt → Open Safari →
Search Google → Read docs → Go back to IDE → Implement

Now:

Question → Response with official documentation → Implement

Massive time savings on every query.

Powerful search

Cupertino uses SQLite FTS5 with BM25 ranking. In plain English: ultra-fast searches (under 100ms) with relevant results sorted by importance.

I can filter by:

Specific framework
Platform version (iOS 17, macOS 14, etc.)
Documentation type (API, examples, guides)
Sample code search

Contextualized learning

I don’t just get the correct API, I also get:

Real code examples from Apple
Documented best practices
Official design patterns
Alternatives and deprecations

It’s like having an Apple mentor inside Claude.

Final thoughts

Cupertino MCP is a perfect example of how AI tools become truly useful when they have access to verified, up-to-date information.

It’s not about giving AI more power to “guess better.” It’s about connecting it with reliable sources so it gives you precise answers.

If you develop for Apple ecosystems, Cupertino MCP is a 5-minute investment (installation) that will save you hours every week. And if you use Claude Code like I do, the experience gets even better.

Do I recommend it? Absolutely. It’s a must-have if you develop with Swift, SwiftUI, or any Apple framework.

Is it for everyone? Only if you develop for Apple platforms. If you work with other technologies, look for similar tools — there are surely equivalents for Android, web, and more.

Keep coding, keep running 🏃‍♂️

Which AI

2026-02-04T00:00:00Z

Déjà Vu: The Web 2.0 Frameworks

Remember that golden era when a new web framework popped up every week?

One that was more modern, more powerful, more performant, more beautiful… One that came to “kill” all the previous ones and was going to become the only framework you’d ever need.

Spoiler: none of them killed anything, and now we have more frameworks than ever.

Well then, welcome to the AI era: same concept, but on steroids.

Notification Fatigue

Picture this: you’re peacefully coding with your trusted AI, workflow on point, productivity at its peak… and suddenly:

Notification: “Revolutionary new AI just launched!”

Video: “How to use it in 10 minutes”

Tutorial: “Integrate it into your workflow TODAY”

Thread: “Why you should switch right now”

And here comes the funniest part: the content creator who just 1 hour ago had a video explaining “Why the old AI is the future”, now has another video about “Why the new AI is better than everything”.

I don’t blame them, honestly. It’s their job to stay up to date and create relevant content. But as a consumer… it’s exhausting.

The Impossible Race

If it’s already hard to keep up with the daily updates of the AI you’re using (and trust me, there are so many updates), imagine having to:

Try every new AI that comes out
Learn its interface and quirks
Integrate it into your workflow
Compare it with the ones you already use
Decide if the switch is worth it

Result: Mission impossible.

And don’t get me wrong: I love having options. In fact, it’s wonderful that so much competition and innovation exists. More options = more better.

My Red Line

Now, there’s something I’m adamant about:

I will never use an AI that requires full permissions from the start.

None of that “Give me full access to your machine and trust me” stuff. That’s not for me.

My philosophy is clear:

Tell me what you’re going to do (or plan it out)
I review the changes
I approve (or don’t approve)
Then you proceed

No free will for AI with admin privileges. Full control is my mantra, as I already shared in my article about Claude Code.

It’s No Longer Just a Model

And here’s what’s truly fascinating: AI is no longer simply “a model” or “an app” that you install and use.

Now we have complete ecosystems:

Base + fine-tuned models
IDE integrations
Plugins and extensions
APIs and SDKs
Orchestration platforms
Specialized tools

The speed at which all of this is evolving is incredible. What was science fiction 2 years ago is now your daily coding assistant.

Living in an Incredible Era

At the end of the day, I believe we’re living through something historic:

Battle of the IDEs: VSCode vs. Cursor vs. WindSurf vs. Zed vs…

Battle of the Frameworks: React vs. Vue vs. Svelte vs. Solid vs…

Battle of the AIs: Claude vs. ChatGPT vs. Gemini vs. Copilot vs…

Trying to keep up with everything is exhausting, I’ll admit it. Personally, I find it impossible.

But it’s also exciting. Every day there’s something new to learn, something to try, something that makes you rethink how you work.

Final Thoughts

The takeaway from all of this is simple:

You don’t need to use everything. Really, you don’t.

Find the tools that work for you, learn to use them well, stay up to date with their updates, and it’s perfectly fine to explore alternatives from time to time.

But don’t drive yourself crazy trying to ride every wave at once. Pick your surfboard, learn to use it well, and enjoy the ride.

And if one day you decide to switch boards, go for it. But make it a conscious decision, not a reaction to the FOMO (Fear Of Missing Out) created by 47 simultaneous notifications.

Happy coding (with whichever AI you prefer)

Keep coding, keep running 🏃‍♂️

Conferences 25

2026-01-28T00:00:00Z

iOSConfSG

Date: January 15-17

Place: Singapore

Web: iosconf

Video: youtube

AppDevCon

Date: March 18–21

Place: Amsterdam

Web: appdevcon

Video: videos

Swift Heroes

Date: April 8–9

Place: Turin

Web: swiftheroes

Video: youtube

try! Swift Tokyo

Date: April 9–11

Place: Tokyo

Web: tryswift

Video: youtube

Deep Dish Swift

Date: April 27–29

Place: Chicago

Web: deepdishswift

Video: youtube

iOSKonf

Date: May 13–15

Place: Skopje

Web: ioskonf

Video: youtube

Swift Craft

Date: May 19–21

Place: Kent

Web: swiftcraft

Video: youtube

WWDC

Date: June 9–13

Place: Cupertino

Web: apple

Video: youtube

NSSpain

Date: September 17-19

Place: Logroño

Web: nsspain

Video: youtube

Swift Connection

Date: October 6–7

Place: Paris

Web: swiftconnection

Video: youtube

SwiftLeeds

Date: October 7–8

Place: Leeds

Web: swiftleeds

Video: youtube

Pragma Conference

Date: October 30–31

Place: Bologna

Web: pragmaconference

Video: youtube

Do iOS

Date: November 12-13

Place: Amsterdam

Web: do-ios

Video: youtube

Keep coding, keep running 🏃‍♂️

Async Concurrent Map

2026-01-21T00:00:00Z

My Problem 🤔

In backend applications with Vapor, when we process large volumes of data concurrently, we face an optimization dilemma:

Sequential processing with asyncMap: guarantees resource control, but is slow by processing elements one by one.
Fully concurrent processing with concurrentMap: maximizes speed, but can saturate resources by launching thousands of simultaneous tasks.

For example, when processing 10,000 records with external API calls:

asyncMap: 10,000 sequential calls → very slow but controlled.
concurrentMap: 10,000 simultaneous calls → very fast but can exhaust connections/memory.

We need a solution that combines both approaches: divide the work into manageable groups and process each group concurrently, balancing speed and resource usage.

My Solution 🧩

We extend Collection with a function that combines chunking (division into groups) and concurrent processing, allowing configuration of chunk size and timeout per 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 }
    }
}

Key points:

If chunkSize is not specified, uses pure concurrentMap (fully concurrent processing).
If chunkSize is specified, divides the collection into groups with chunks(ofCount:).
Processes the chunks sequentially with asyncMap (with optional timeout).
Within each chunk, processes the elements concurrently with concurrentMap.
Flattens the results with flatMap to return a unified array.

My Result 🎯

// Process 10,000 records in chunks of 100
// 100 concurrent tasks at a time, 100 times
let results = try await records.asyncConcurrentMap(
    chunkSize: 100,
    timeout: 30.0
) { record in
    try await apiClient.process(record)
}

Benefits of this approach:

Perfect balance: combines the speed of concurrent processing with the control of sequential processing by chunks.

Resource control: limits the number of simultaneous tasks to the chunk size, avoiding saturation.

Timeout per chunk: detects and handles problematic chunks without blocking all processing.

Full flexibility: use chunking when you need it, or pure concurrent processing when you don’t.

Scalability: allows processing millions of records by adjusting chunk size according to available resources.

If you need pure parallel execution, I covered that in Concurrent Map. And if your sequential chunks need rate limiting between them, I added that capability in Async Map Timeout.

This solution is the natural evolution of asyncMap and concurrentMap, combining the best of both worlds to optimize massive data processing in backend applications.

Keep coding, keep running 🏃‍♂️

Async Map Timeout

2026-01-14T00:00:00Z

My Problem 🤔

In the post about AsyncMap we saw how to process collections in a sequential asynchronous manner. However, when working with external APIs that implement rate limiting, we face a critical problem:

// Process 1000 URLs sequentially
let results = try await urls.asyncMap { url in
    try await apiClient.fetch(url)  // ⚠️ 1000 calls without pause
}
// Error 429: Too Many Requests

Making consecutive calls without pauses can:

Exceed rate limits: APIs reject with 429 Too Many Requests.
Saturate external services: overload of simultaneous connections.
Waste resources: forcing retries consumes more time and bandwidth.
Temporary blocks: some APIs block the IP after multiple violations.

We need a way to control the pace of sequential operations, adding intentional pauses between each processing.

My Solution 🧩

We update asyncMap by adding an optional timeout parameter that introduces a configurable pause after processing each element.

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
    }
}

Key changes from the original version:

Optional and backward-compatible timeout: Double? = nil parameter.

If timeout is specified, adds Task.sleep(for: .seconds(timeout)) after each element.

Maintains original behavior when timeout is not specified (no pauses).

Allows dynamic rate limiting adjustment according to each API’s limits.

My Result 🎯

// Rate limiting: 1 call per second
let results = try await urls.asyncMap(timeout: 1.0) {
    try await apiClient.fetch($0)
}

// Aggressive rate limiting: 1 call every 5 seconds
let results = try await endpoints.asyncMap(timeout: 5.0) {
    try await scraper.parse($0)
}

// Without timeout: original behavior (maximum speed)
let results = try await localFiles.asyncMap {
    try await processFile($0)
}

Benefits of this update:

Configurable rate limiting: controls the call pace according to each API’s limits.

Block prevention: avoids 429 errors and temporary IP suspensions.

Full backward compatibility: without timeout it works exactly as before.

Flexibility per use case: adjusts timeout based on external service tolerance.

Predictable processing: easily calculate total time (n elements × timeout).

This update turns asyncMap into a complete tool for controlled sequential processing, ideal for integration with APIs that impose rate limits and need a regulated request flow.

Keep coding, keep running 🏃‍♂️

Copy To

2026-01-07T00:00:00Z

My Problem 🤔

In backend applications with Vapor, we often need to export large volumes of data from the database to files for different purposes: backups, offline analysis, integration with external systems, or data audits.

Using traditional queries with Fluent and then manually serializing the results presents several drawbacks:

High memory consumption: loading thousands of records into memory to process them one by one.
Slow processing: manual serialization to CSV requires iterating and formatting each record.
Lack of optimization: doesn’t leverage the native export capabilities of the database engine.
Unnecessary complexity: manual management of formats, character escaping, and null value handling.

For bulk export scenarios, we need a strategy that leverages PostgreSQL’s native capabilities to generate files efficiently.

My Solution 🧩

We extend Database with a function that executes the COPY … TO command from PostgreSQL, allowing data export directly from the table schema to CSV files in the filesystem.

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()
    }
}

Key points:

Uses PostgreSQL’s COPY … TO, the most efficient method for bulk exports.
The model.space parameter supports custom schemas (defaults to “public”).
model.schema automatically obtains the table name from the Fluent model.
Standard CSV configuration: headers included, delimiters, and proper null value handling.
Uses unsafeRaw for direct interpolation in the SQL query.

My Result 🎯

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

Benefits of this approach:

Optimal performance: COPY … TO is much faster than manual serialization.

Resource efficiency: PostgreSQL writes directly to the file without loading data into application memory.

Consistent format: the database engine guarantees a valid CSV with proper escaping.

Native integration: leverages optimized capabilities of the PostgreSQL engine.

Scalability: allows exporting millions of records without impacting application performance.

This solution is the perfect complement to importCSV, forming a pair of functions that enables bidirectional data movement between PostgreSQL and the filesystem efficiently and reliably. If you haven’t seen the import side yet, I explain how to build it using PostgreSQL’s COPY FROM in Copy From.

Keep coding, keep running 🏃‍♂️

Copy From

2025-12-31T00:00:00Z

My Problem 🤔

In backend applications with Vapor, when we need to insert large volumes of data into the database (initial migrations, catalog imports, bulk loading from external APIs), using .save() in a loop generates multiple individual transactions.

This results in:

High latency: each insert opens/closes connection and transaction overhead.
Poor throughput: doesn’t leverage the database engine’s bulk insertion capabilities.
Timeout risk: slow operations that may fail in environments with time constraints.

For mass import scenarios (thousands or millions of records), we need a bulk insert strategy that leverages native PostgreSQL capabilities.

My Solution 🧩

We extend Database with a function that executes PostgreSQL’s COPY command, allowing us to import CSV files directly from the file system into the table schema.

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()
    }
}

Key points:

Uses PostgreSQL’s COPY, the fastest method for bulk insert from files.
The model.space parameter supports custom schemas (defaults to “public”).
model.schema automatically gets the table name from the Fluent model.
Standard CSV configuration: headers, delimiters, and null value handling.
Uses unsafeRaw for direct interpolation in the SQL query.

My Result 🎯

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

Benefits of this approach:

Extreme performance: COPY is up to 10-100x faster than individual inserts.

Atomic transaction: the entire import happens in a single operation, guaranteeing consistency.

Resource efficiency: minimizes memory usage and database connections.

Native integration: leverages optimized PostgreSQL engine capabilities.

Scalability: allows importing millions of records without significant degradation.

This implementation uses COPY … FROM with file system files. There is currently an open issue in Vapor to implement native support for COPY … FROM STDIN, which would allow performing bulk inserts directly from memory without intermediate files.

I’m actively monitoring this issue to integrate this functionality when available, which will provide an even more flexible and efficient API for mass import operations.

If you also need the reverse operation — exporting data from PostgreSQL to CSV files — I covered that in Copy To.

Keep coding, keep running 🏃‍♂️

Swift Package

2025-12-24T00:00:00Z

The broken dependencies dilemma

When working with Swift Package Manager (SPM), you’ll eventually encounter a compilation error that makes no sense. You’ve tried building multiple times, restarted Xcode, but the error persists. The solution often lies in properly cleaning SPM caches and artifacts, but which command should you use?

There are multiple ways to “clean” in SPM, each with a specific purpose. Using the wrong command may not solve your problem or, worse yet, force you to download gigabytes of dependencies again.

The four paths to clean

SPM offers three official commands plus a manual alternative. Each affects different parts of the system:

Command	Deletes local .build	Deletes Package.resolved	Deletes global cache
swift package clean	No (only compiled binaries)	No	No
swift package reset	Yes (complete)	Yes	No
swift package purge-cache	No	No	Yes
rm -rf .build	Yes (complete)	No	No

Swift package clean

swift package clean

What it does:
Removes only the final compiled binaries inside the .build folder, but keeps downloaded dependencies and intermediate files.

When to use it:

After changing build configurations
To force a complete rebuild without re-downloading dependencies
When binaries are corrupted but sources are fine

Does not download dependencies again nor resolve package cache issues.

Swift package reset

swift package reset

What it does:
Completely removes the .build folder (including downloaded dependencies) and the Package.resolved file.

When to use it:

When there are conflicts in dependency versions
After significant changes to Package.swift
To resolve “dependency not found” errors
When Package.resolved is outdated or corrupted

The next build will download and resolve all dependencies from scratch. This can take several minutes depending on the number of packages.

Swift package purge-cache

swift package purge-cache

Available from Swift 5.7 onwards.

What it does:
Removes the global package cache located at:

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

This cache contains cloned repositories and binary artifacts shared across all your projects.

When to use it:

When multiple projects have the same issue
After updating Xcode or Swift tooling
To free up disk space (can take up several GB)
When you suspect the global cache is corrupted

All your projects will need to re-download common dependencies.

rm -rf .build

rm -rf .build

What it does:
Manually deletes the complete .build folder, similar to reset but without touching Package.resolved. It’s less aggressive than reset because it doesn’t re-resolve dependencies.

When to use it:

To clean build artifacts while maintaining version resolution
In CI/CD scripts where you want full control
When swift package reset is not available

Preserves Package.resolved, which means dependency versions won’t be re-resolved.

Troubleshooting strategy

Level 1: Light cleanup

swift package clean

Try the least invasive first. Solves 30% of issues.

Level 2: Complete project reset

swift package reset

If level 1 fails. Solves 60% of remaining issues.

Level 3: Purge global cache

swift package purge-cache
swift package reset

For persistent issues or those affecting multiple projects.

Level 4: Nuclear

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

Last resort. Complete fresh start.

Real-world use cases

Scenario 1: Error after updating Xcode

swift package purge-cache
swift package reset

Build tools changed and the cache may have incompatible artifacts.

Scenario 2: Dependency version conflicts

swift package reset

You need to re-resolve all dependencies with the new constraints.

Scenario 3: Disk space full

swift package purge-cache

The global cache can grow to several GB without you noticing.

Scenario 4: CI/CD builds

rm -rf .build

In continuous integration environments, you want clean but reproducible builds with versioned Package.resolved.

Understanding the components

.build (local)

Current project’s build artifacts
Project-specific downloaded dependencies
Intermediate build files

Package.resolved

“Lockfile” that pins exact dependency versions
Guarantees reproducible builds
Should be versioned in Git for shared projects

Global cache

Shared across all your Swift projects
Contains clones of dependency repositories
Pre-compiled binary artifacts
Can reach several GB over time

Best practices

Version Package.resolved in Git to ensure the whole team uses the same versions

Use reset after changes to Package.swift to ensure clean resolution

Purge the cache periodically if you work with many projects

In CI/CD, keep Package.resolved but delete .build for clean builds

Don’t ignore .build in .gitignore - it’s already ignored by default

Don’t delete Package.resolved unless you really need to re-resolve versions

Conclusion

Understanding the difference between these commands saves you time and frustration. Not all build issues need a nuclear cleanup:

clean → Only compiled binaries
reset → Complete project + Package.resolved
purge-cache → Shared global cache
rm -rf → Surgical manual control

The next time SPM shows you a strange error, you’ll know exactly which tool to use.

Keep coding, keep running 🏃‍♂️

Subprocess

2025-12-17T00:00:00Z

My Problem 🤔

When working with external processes in Swift applications, the traditional Process class presents several significant limitations:

Manual resource management: Requires explicit configuration of executable URLs, arguments, and output handling
Lack of async/await support: Uses synchronous methods that block the execution thread
Complex error handling: Makes it difficult to capture and process errors from child processes
Verbose configuration: Each execution requires multiple lines of repetitive configuration

In the previous code, I needed to execute Ghostscript to convert PDF files to PNG images, but the implementation with Process was extensive and inelegant.

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()
}

My Solution 🧩

Apple’s new Subprocess library provides a modern and robust API for process execution in Swift. This cross-platform library offers native support for async/await and automatic resource management.

Key features:

Native async/await API for non-blocking operations.

Automatic resource management and process cleanup.

Granular output control (stdout, stderr).

Integrated termination status verification.

Concise and expressive syntax.

The modernized implementation uses the run function from 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
    )
}

Key parameters:

.path: Specifies the executable directly
output: .discarded: Discards standard output since we don’t need to process it
error: .string(limit: .max): Captures errors as a string for logging
result.terminationStatus: Verifies that the process terminated successfully

My Result 🎯

The migration to Subprocess transforms process management code into a cleaner, safer, and more efficient solution:

Benefits achieved:

Improved performance with true asynchronous operations.

Better error handling with integrated stderr capture.

More readable code with less manual configuration.

Seamless integration with the modern Swift concurrency ecosystem.

The new implementation not only reduces complexity but also improves system robustness by providing better error visibility and more elegant asynchronous execution handling in Vapor applications.

Note on DYLD_LIBRARY_PATH

In earlier versions of Swift, there was a known issue with the DYLD_LIBRARY_PATH environment variable when executing external processes. Due to macOS’s System Integrity Protection (SIP) restrictions, this variable was automatically removed when launching subprocesses, causing “Library not loaded” errors in certain cases.

The temporary solution required manually configuring library paths using install_name_tool with @rpath, or alternatively setting the DYLD_LIBRARY_PATH variable instead.

Good news! This issue has been resolved in recent versions of Swift. The Subprocess library correctly handles system environment variables, including DYLD_LIBRARY_PATH, without requiring additional configuration.

Keep coding, keep running 🏃‍♂️

Json Snake Case

2025-12-11T00:00:00Z

My Problem 🤔

When integrating REST APIs, it’s very common for JSON keys to come in snake_case (for example, first_name) while in Swift we model properties in camelCase (firstName).
If we don’t configure anything, we have to manually write CodingKeys in each model or accept decoding errors.

We’re looking for a centralized and reusable way to:

Decode JSON without manual CodingKeys.
Encode our models when sending data.
Maintain the same behavior in both iOS/macOS apps (URLSession) and Vapor (req/res content).

My Solution 🧩

We create extensions for JSONDecoder and JSONEncoder that expose convenience constructors and static snakeCase shortcuts.
Advantages:

Zero boilerplate in models: avoids repetitive CodingKeys.
Self-explanatory name when using them: JSONDecoder.snakeCase / JSONEncoder.snakeCase.
Consistency across the entire project (client and server).

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)
    }
}

Note: if a model needs a specific key name, you can still use CodingKeys locally; the snake_case strategy will act as the default value.

My Result 🎯

Usage examples

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

// iOS / macOS: sending data
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)

With these shortcuts we get:

Fewer errors and greater readability: properties remain in idiomatic Swift camelCase.
Immediate interoperability with legacy snake_case APIs.
Single configuration reusable throughout the project (tests included).

This standardizes how we serialize/parse JSON without sacrificing clarity or fine-grained control when needed.

Keep coding, keep running 🏃‍♂️

Array to dictionary

2025-12-03T00:00:00Z

My Problem 🤔

When working with lists of models (e.g., results, events, or users), we often need O(1) access by identifier for lookups, merges, or deduplication.

However, in many domains the id may be optional (UUID?) until the backend assigns it. If we build a dictionary directly, two frictions arise:

We need to filter out elements without ID to avoid invalid entries.
We must guarantee uniqueness of keys or the Dictionary(uniqueKeysWithValues:) constructor will fail at runtime if there are duplicates.

My Solution 🧩

We extend Array (when its elements are Identifiable with ID == UUID?) to expose toDictionary().
The function uses compactMap to discard elements without ID and builds the dictionary with Dictionary(uniqueKeysWithValues:).

Precondition: existing IDs must be unique within the collection. If you expect collisions, consider a variant with Dictionary(_, uniquingKeysWith:) to resolve duplicates.

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) }
        )
    }
}

Notes:

Elements with id == nil are not included.
Key-based access is O(1) and simplifies in-memory merges/joins.

My Result 🎯

A small, clear helper to convert from an array to a map by ID:

Faster to query O(1).
Safer: avoids inserting elements without identifier.
More expressive and reusable in services and view models.

Keep coding, keep running 🏃‍♂️

Schedule Queues

2025-11-26T00:00:00Z

My Problem 🤔

When using Vapor Queues to schedule jobs, the typical API is:

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

This schedules once per hour. If we want to run it every N minutes (e.g., every 5, 10, or 15), we have to manually register multiple .at(…) calls, which results in repetitive code, prone to errors (duplicated/forgotten minutes), and difficult to read.

My Solution 🧩

We extract a helper over Application.Queues that registers the same ScheduledJob multiple times within the hour using a stride with step minutes. This way, with a single call we express: “run it every N minutes”.

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))
        }
    }
}

Key points:

Uses stride(from: 0, to: 60, by: minutes) to generate minute offsets within the hour.
For each offset it registers hourly().at(…), avoiding logic duplication.
If minutes doesn’t divide 60, the last execution will be the largest multiple < 60 (e.g., minutes = 7 ⇒ 0, 7, 14, …, 56).

My Result 🎯

Usage example:

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

A concise and self-expressive API for short periodic tasks:

Less boilerplate: a single call registers all triggers.
Fewer errors: no manual lists of .at(…) or duplicated minutes.
Readable and testable: the pattern is evident and easy to verify.

Keep coding, keep running 🏃‍♂️

Async Task List

2025-11-20T00:00:00Z

My Problem 🤔

In distributed systems with microservices, complex processes can create control and reliability challenges. One solution is to divide them into atomic tasks, enabling more granular flow control, improved observability, ensured idempotency, and easier recovery from failures.

The challenge is to design a pattern that allows for controlled degradation, so that a single task failure doesn’t affect the entire flow, guaranteeing resilience and fault tolerance in production environments.

My Solution 🧩

Create a task executor that orchestrates asynchronous tasks.
The execute function wraps each task, manages errors with do-catch as a circuit breaker, updates state on success, logs and persists failures, and ensures an atomic transaction to maintain data consistency.

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)
}

My Result 🎯

This implementation provides a high-level abstraction that enables precise orchestration of complex asynchronous processes with atomicity and durability guarantees.

Separation of Concerns: each task isolates its execution context and error handling.

Workflow Orchestration: enables task chaining through the pipeline pattern.

Observability: generates a complete audit trail for debugging and monitoring.

Performance: maintains high concurrency without compromising data consistency.

Resilience: incorporates automatic fail-fast and recovery patterns.

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

Keep coding, keep running 🏃‍♂️

Multi-Step Process

2025-11-12T00:00:00Z

My Problem 🤔

In distributed systems and backend processes, it’s common for a complex operation to require executing multiple sequential steps with dependencies between them: file creation, upload, response generation, validation, cleanup, etc.
Controlling this state flow is critical to:

Ensure each step executes in the correct order.
Allow for recovery in case of error or system restart.
Maintain data consistency even if the process is interrupted.

Without a clear strategy, the code can become fragile, difficult to scale, and prone to errors.

My Solution 🧩

A stage-based state management function is implemented to control the advancement of a ProcessModel through its lifecycle.
The idea is to encapsulate the state transition logic in a single function that evaluates the current state and executes the corresponding action, until the process reaches its final state.

The pattern relies on a repeat-while loop that re-evaluates the state after each operation, ensuring transitions occur in a deterministic and resilient manner.

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
    }
}

Implementation key points:

State centralization: a single control point defines all transitions.
Continuous re-evaluation: the repeat-while loop allows automatic advancement as long as there are state changes.
Operation isolation: each switch case delegates to specialized functions (_uploadFiles, _createResponses, etc.), keeping the code clean and testable.

My Result 🎯

This multi-stage process management pattern provides:

Resilience: each transition is atomic and can be retried if a failure occurs.
Scalability: adding new steps only requires adding a new case to the switch.
Clarity: the complete process flow is understood with a single read.

Application example: data processing pipelines, content publishing workflows, or any long-running process that requires precise control of each stage without compromising data integrity.

Keep coding, keep running 🏃‍♂️

Concurrent Map

2025-10-27T00:00:00Z

My Problem 🤔

When processing collections in Swift, the map method executes transformations sequentially.
For intensive operations or those involving I/O—such as HTTP requests, file reading, or database queries—this can become a bottleneck.
The goal is to leverage concurrency to execute multiple transformations in parallel, ensuring safety with Sendable and error handling.

My Solution 🧩

A Sequence extension is created that adds concurrentMap.
Internally, it uses withThrowingTaskGroup, which allows:

Launching a task for each element in the sequence.
Executing all transformations in parallel, respecting Swift’s structured concurrency model.
Automatically propagating the first error that occurs, canceling the remaining tasks.

The use of @Sendable ensures that both elements and results are safe in concurrent environments.
This way, any asynchronous operation can benefit from parallel execution without sacrificing code clarity.

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)
            }
        }
    }
}

My Result 🎯

With concurrentMap, you achieve significant performance gains in asynchronous operations that can execute in parallel.
The pattern respects Swift’s structured concurrency rules, avoids data races, and maintains the same declarative style as map, making its adoption in existing projects straightforward.

Usage example:

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

This approach is ideal for batch HTTP requests, image processing, bulk data reading, or any scenario requiring maximum safe parallelism.

If you need guaranteed ordering or want to limit resource consumption to one task at a time, I covered that in Async Map. And if you want to combine both strategies — concurrent processing within controlled chunks — I built that in Async Concurrent Map.

Keep coding, keep running 🏃‍♂️

Async Map

2025-10-20T00:00:00Z

My Problem 🤔

When processing collections with asynchronous transformations, the standard map method falls short because its closures cannot be async.
A naive solution would be to use a for loop with await, but this sacrifices readability and consistent error handling.
The goal is to have a sequential map that accepts async throws functions, preserves element order, and simplifies the workflow.

My Solution 🧩

We create an extension on Sequence that adds asyncMap.
Its execution is sequential within the same task, which allows us to:

Maintain deterministic ordering of results.
Limit resource consumption by executing only one operation at a time.
Uniformly propagate the first error that occurs, stopping the process.

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
    }
}

My Result 🎯

With asyncMap, we achieve a clear and safe workflow for asynchronous transformations without parallelism.
It’s especially useful when:

We need guaranteed ordering.
We must limit resource consumption (one task in flight).
There’s dependency between operations.

If you need parallel execution instead of sequential, I explored that approach in Concurrent Map. And if your sequential calls hit rate limits, I added a timeout mechanism in Async Map Timeout.

Usage example:

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

My Problem 🤔

In multiple sections of my code, I need to execute three operations every time I handle an Optional:

Unwrap the Optional content
Log an error in the logging system if the value is nil
Throw an exception when the value doesn’t exist

This pattern repeats frequently, generating duplicate code and reducing maintainability.

My Solution 🧩

The strategy consists of encapsulating the three operations in reusable functions that work in a coordinated manner.

Helper function: logError

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

This function executes the error logging in the logging system and subsequently terminates execution by throwing an Abort exception. The Never return type is fundamental, as it indicates to the compiler that this function never returns normally, ensuring that execution is completely interrupted.

Main function: guardAndLogError

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

This generic function implements the complete pattern:

Uses guard let to safely unwrap the Optional
If the value is nil, invokes logError() to log the failure and terminate execution
If it contains a value, returns it successfully

The genericity T allows using this function with any type of optional data.

My Result 🎯

With this implementation, a single line of code executes the three required operations: safe unwrapping, error logging, and exception handling.

let fileName = try guardAndLogError(
    fileName, 
    message: "fileName value not found"
)

Benefits

Reduction of duplicate code
Consistent error handling
Centralized and structured logs
Reusability through genericity

Extensibility

This pattern can be extended for more specific use cases:

// For boolean validations
func guardAndLogError(
    _ condition: Bool, 
    message: String
) throws { ... }

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

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

Keep coding, keep running 🏃‍♂️

Schemas and Namespaces

2025-10-06T00:00:00Z

My Problem 🤔

When I define a data model in Vapor, I can specify the schema, which corresponds to the table name in the database. But keeping every table in the default schema doesn’t scale for me: to maintain an organized architecture, I want to group my tables into different namespaces by functional criteria instead of concentrating them all in one place. That way I get a logical separation by domain or application module.

My Solution 🧩

To assign a table to a specific namespace, I override the static space property on the model. This property lets me define the namespace where the table will reside, giving me a more granular organization of my database structure.

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() { }
}

My Result 🎯

There’s one detail I had to get right: I must declare the space property as type String? (optional). When I declared it as String (non-optional), it didn’t override the property inherited from the Model protocol, but created a new property with the same name instead. That made the framework ignore my namespace configuration and keep the tables in the default schema, without any apparent error to warn me.

If you’re wondering how to create these namespaces automatically in the database, I explain how to turn that into a migration in Migrate Spaces.

Keep coding, keep running 🏃‍♂️

Partial Indexes

2025-09-29T00:00:00Z

My Problem 🤔

A partial index is an index that is created only on a subset of rows in a table, defined by a specific WHERE condition. Instead of indexing all rows, the index only includes those that meet certain criteria, which can improve performance and reduce space usage.

In my particular case, I needed to index fields based on whether their values were NULL or NOT NULL. For example, the following partial indexes in 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;

It’s also possible to create partial indexes that involve multiple columns:

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;

Not all databases support partial indexes. In my particular case, I’m using PostgreSQL

By default, Vapor doesn’t offer direct support for creating partial indexes, since the standard index generation doesn’t include the ability to add a WHERE clause in the index definition.

The following code snippet creates a normal index, either on one or several fields, but doesn’t allow specifying a condition for a partial index:

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

This code works for creating simple indexes, but lacks the ability to add a WHERE predicate.

This snippet has been adapted by me; the original builder’s .create method exposes more configuration options, but in this example I show a custom and simplified implementation that I currently use.

My Solution 🧩

The SQLCreateIndexBuilder builder supports an optional predicate. If this is not nil, it adds a WHERE clause to the index.

Therefore, I extended this builder to include a where method that accepts a list of columns and a partial index type (for example, null or not null). This method builds the appropriate logical expression for the predicate and assigns it to the index.

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
    }
}

This code allows calling the where method for one or several fields, specifying whether you want a partial index for NULL or NOT NULL values. If no value is provided for partialIndex, the index is returned without a predicate, behaving like a normal index.

The logic consists of creating a list of binary expressions SQLBinaryExpression for each column, combining them with the logical operator AND and assigning the result as the index predicate.

Alternative

The most direct way to create partial indexes is to execute raw SQL statements, as shown in the initial examples. This involves building a method to execute raw CREATE INDEX statements with the corresponding WHERE clause.

Although effective, this approach loses the advantage of abstraction and safety that Vapor offers when building migrations and database schemas using Swift code.

My Result 🎯

With this extension, I can now create partial indexes easily in Vapor, adding only one line to the original code:

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

Where $0.partial is an optional value that indicates the desired partial index type null or not null.

This approach is specifically designed for partial indexes based on the presence or absence of NULL values in columns. However, the implementation can be adapted to support other conditions and more complex use cases, simply by modifying the predicate construction.

The solution offers a clean and reusable way to create partial indexes within the Vapor ecosystem, maintaining the consistency and safety of Swift code.

If you also want to organize your tables into namespaces using Fluent’s space property, I covered that in Schemas and Namespaces.

Keep coding, keep running 🏃‍♂️

My First Data Race

2025-09-22T00:00:00Z

My Problem 🤔

During a refactoring process to convert previously sequential functionality into concurrent processing, I ran into a classic problem: ensuring record uniqueness when multiple tasks attempt to create events simultaneously. While the goal was to improve performance by processing thousands of events in parallel using Swift, the transition exposed a typical concurrency challenge: avoiding duplicates and maintaining data integrity under simultaneous access.

The bug turned out to be a logical race condition of the check-then-act kind. When multiple concurrent tasks attempt to create the same event, they can all check that it doesn’t exist and proceed to create it simultaneously. Only one of the resulting instances gets stored, while the rest become orphaned, causing inconsistencies and broken references in other data structures.

For example: two concurrent tasks check if an event exists. Both see that it doesn’t, both create it, but only one survives in the dictionary; the other reference is now lost.

My Solution 🧩

I reached the final fix through a progression of attempts, each one exposing the limits of the previous.

Actor with array

My first attempt kept the events in an array guarded by an actor.

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
    }
}

Advantages:

Simplicity.
Safety against race conditions.

Disadvantage:

Inefficient search for large volumes O(n).

Actor with dictionary

To speed up lookups, I swapped the array for a dictionary keyed by name and city.

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
    }
}

Advantages:

Fast search and insertion O(1).
Ideal for large data volumes.

Bug:

Logical race condition

Actor with a task per key

To prevent this, I serialize not only access but also creation by key. If there’s already a creation in progress for that key, concurrent tasks must wait for the result of the first one, ensuring that all of them share exactly the same resource.

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
    }
}

My Result 🎯

An actor alone doesn’t prevent logical race conditions of the “check-then-act” type.
In concurrent scenarios, serializing resource construction by key is fundamental to maintaining data integrity.
It’s essential to test under load and concurrent scenarios, not just in sequential mode.

Keep coding, keep running 🏃‍♂️

Timestamps in Migrations

2025-09-15T00:00:00Z

My Problem 🤔

If you’re like me, when you design a database model you want all tables to always include three key fields:

createdAt: indicates when the record was created.
updatedAt: reflects the last time it was updated.
deletedAt: marks when it was logically deleted (without physically deleting the record).

As you can see, in each migration we have to manually write the three timestamp fields. This is not only repetitive, but also error-prone if we forget a field or misspell the data type.

try await db.schema(model)
    .id()
    .field(.name, .string, .required)
    .field(.createdAt, .datetime, .required)
    .field(.updatedAt, .datetime, .required)
    .field(.deletedAt, .datetime)
    .create()

My Solution 🧩

The solution is to create a SchemaBuilder extension that adds a timestamps() method. This extension encapsulates the repetitive logic in one place, making the code cleaner and more maintainable.

extension SchemaBuilder {
    func timestamps() -> Self {
        self.field(.createdAt, .datetime, .required)
            .field(.updatedAt, .datetime, .required)
            .field(.deletedAt, .datetime)
    }
}

My Result 🎯

Now our migrations are much cleaner and more readable. By calling .timestamps() we add the three necessary fields. This reduces the possibility of errors and makes the code easier to maintain.

try await db.schema(model)
    .id()
    .field(.name, .string, .required)
    .timestamps()
    .create()

Keep coding, keep running 🏃‍♂️

Claude Code

2025-09-01T00:00:00Z

What is Claude Code for me?

To move away from what everyone talks about, I’m going to tell you about artificial intelligence from my personal experience.

I’ve integrated Claude Code into my projects, but for me it’s much more than a tool: it’s my digital assistant, another member of my development team, an extension of my capabilities or, as the image represents well, my technological shadow.

It doesn’t replace me nor do I think it replaces any developer at the moment. Claude Code is only as good as you are or as you know how to use it.

My Golden Rules

I have four fundamental rules that I religiously apply with Claude Code:

Total Change Control

I review everything before implementing any changes
It doesn’t have permissions to modify files without my approval
Flow: It provides me the plan → I review the changes → I understand them → I approve them (or not)
This rule is super important to me. Giving it blind permissions doesn’t align with my philosophy

Claude.md as Project Bible

I work intensively on the CLAUDE.md file
I define what the project is and establish clear guidelines
It’s my way of “training” Claude on my style and preferences
Result: Responses more aligned with my vision

Intelligent Configuration

I configure its settings with official documentation paths
When I ask questions about specific technologies, it uses official sources
This guarantees more precise and up-to-date responses

Collaborative Work, Not Dependency

I never start from an empty IDE
I always work on a code base I’ve already developed
My flow: I start creating → I get stuck → I ask Claude
Recurring question: “Is there a cleaner and more efficient way to write this code?”

Limitless imagination

And here comes the interesting part: Claude Code isn’t just for programming. You can use it for whatever comes to mind. Just ask yourself this question:

How can I make this idea work with Claude Code?

One of the coolest ways I use it outside of programming is with my technical content consumption:

I consume tons of programming content:

Online courses

Knowledge pills

Conferences and talks

Technical debates

Specialized podcasts

Practical workshops

The typical problem: You’re programming and remember seeing something useful in a video, but… which one was it? At what minute?

My solution with Claude:

I ask: “Where is this talked about?”
It returns:
- The specific video or videos
- The exact timestamp where it’s mentioned
- A brief summary of the content

Result: Wonderful! Instant access to all my consumed knowledge.

Final Reflection

Claude Code has become my technological shadow. It’s not magic, it doesn’t do the work for you, but if you know how to use it correctly, it can enormously enhance your productivity and creativity.

The key is in establishing clear limits, maintaining control and using it for what it really is: an exceptional assistant that amplifies your capabilities, not one that replaces them.

Keep coding, keep running 🏃‍♂️

Love Vapor

2025-08-25T00:00:00Z

Swift on the server side

When I attended the Swift Full Stack Bootcamp at Apple Coding Academy, one of the modules we were taught was Swift on the server side using the Vapor framework.

From the very start of the theory portion, my heart began to race, and by the middle of that very first class, I was already completely in love.

So, if you ask me “What was your favorite module in the Bootcamp?”, without a doubt, I’d say this one.

Why do I like it?

I’ve always thought that the backend is the brain of any application or website.
It’s where all the real action happens: where information is processed (usually from a database) and prepared so that the end user receives it in the most simple and transparent way possible.

To be clear: I’m not undervaluing the frontend.
In fact, I truly admire those who create incredible designs—heroes in my eyes—because that’s something I personally find impossible… although I do get along quite well with SwiftUI.

Playing with Vapor

In future blog posts, I’ll go into much more detail, but I can already share that I’ve been having a lot of fun with Vapor:

Standalone package to configure different services

gRPC server

Data model with views (including materialized views), indexes, per-application permissions, and schemas

Enums with automatic migrations

PassKey

Bulk inserts for populating huge datasets

Scheduled tasks with asynchrony

… and much more

In various blog posts, I’ll be sharing a bit of everything.
That said, even though I really enjoy Vapor and Swift on the server side, it won’t all be about backend… there will be room for many other topics I’m passionate about.

Keep coding, keep running 🏃‍♂️