Jorge Calderita's Blog

Astro to Saga

2026-04-17T19:06:06Z

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 Workers 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 🏃‍♂️

OnlyDNS

2026-04-17T19:06:06Z

My Problem 🤔

In a previous article I talked about how La Liga was blocking my website during matches. People trying to visit my portfolio and blog would find that the page simply would not load, just because my domain went through Cloudflare’s infrastructure, and La Liga was blocking entire IP ranges from Cloudflare to crack down on illegal streams.

I knew it. I documented it. And I left it there.

For months I did nothing to fix it. Not out of laziness or because I thought it was complicated — but out of anger. My website worked perfectly fine; it was La Liga that was applying indiscriminate blocks and making it unreachable. It was not my fault. So I stood my ground: I should not have to be the one to make a move.

So I did nothing. For months.

The thing is, I had Cloudflare’s proxy enabled — the famous orange cloud. My site is hosted on Cloudflare Pages, so everything lives within the Cloudflare ecosystem. But with the proxy turned on, traffic goes through Cloudflare’s CDN/proxy layer, which uses shared IP ranges. And those ranges are precisely the ones La Liga was blocking.

My Solution 🧩

The solution is to disable Cloudflare’s proxy and switch to DNS-only mode — the grey cloud.

With the orange cloud active, Cloudflare acts as a “shopping mall”: every visitor enters through the proxy/CDN door, which uses shared IP ranges alongside thousands of other sites. Those are the IPs that La Liga blocks in bulk to stop illegal streams — and my website ends up as collateral damage.

With the grey cloud, Cloudflare becomes just a “traffic director”: it resolves the DNS and points directly to Cloudflare Pages. My site is still hosted on Cloudflare, but traffic arrives through the Pages IP ranges — which are different from the proxy ones and are not on La Liga’s blocklist.

The process in the Cloudflare dashboard is straightforward:

Log into the Cloudflare dashboard and navigate to DNS > Records.
Find the records pointing to the site — usually an A or CNAME record with the domain name.
In the Proxy status column, click the toggle with the orange cloud to turn it into a grey cloud (DNS only).
Save the changes.

The change propagates within minutes. From that point on, traffic arrives through a different route within Cloudflare — one that is not in the crosshairs of La Liga’s blocks.

Since my site is static and still hosted on Cloudflare Pages, I notice virtually no difference in speed. I lose some proxy-layer features — like CDN-level firewall or caching at their edge nodes — but for a static portfolio website those benefits are marginal compared to the upside of having the site accessible to everyone during matches.

My Result 🎯

My website now loads during La Liga matches. Anyone trying to visit my portfolio or blog while the Champions League anthem is playing will no longer be greeted by a blank screen.

Five minutes. One click. Months of problems solved.

The lesson I take away is not technical — it is pragmatic. Whether I was right or not, my problem was either going to be solved by me or by no one. And I do believe I was right: my website should not have to be collateral damage from La Liga’s blocks. Thanks, La Liga.

Keep coding, keep running 🏃‍♂️

My First Macro

2026-04-17T19:06:06Z

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-04-17T19:06:06Z

The 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.

The idea 🧩

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 ✅.

The 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-04-17T19:06:06Z

🧩 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 😬.

💡 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 ⚠️.

📊 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-04-17T19:06:06Z

🎨 Why Touch What Already Works?

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. And when you stop to analyze what’s under the hood, you sometimes discover you’re carrying a layer you don’t need 🧅.

🤔 The Problem with Tailwind (In My Case)

Don’t get me wrong: Tailwind CSS is an amazing tool. I’ve used it in professional projects and will continue 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 ⚔️

💡 The Decision: Vanilla CSS with Design Tokens

The idea was simple: remove Tailwind and replace it with vanilla CSS using a design tokens system with 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, you get consistency across the entire project without depending on any framework. Just pure CSS that the browser understands directly 🎯.

🔧 The Migration

The process involved 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 ✅.

📚 What I Learned Along the Way

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

📊 The Results

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 Final Architecture

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 🧙‍♂️.

💭 Final Thoughts

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-04-17T19:06:06Z

🍎 The Apple Documentation Problem

If you develop for iOS, macOS, or any Apple platform, you know the drill:

You’re coding peacefully 💻
You need to check how something works in SwiftUI 🤔
You open Safari / your favorite browser 🌐
You search on Google / DuckDuckGo 🔍
You land on Apple’s official documentation 📚
You read, understand, go back to your IDE 🔄
You repeat this process 47 times a day 😵

Or even worse: you ask your favorite AI and it gives you 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?

💡 Cupertino MCP: The Solution

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

In plain English: it’s like giving your 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 🛡️.

🎯 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 🏎️.

📊 Super Powerful Search

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

You 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, etc.) 🔍.

Keep coding, keep running 🏃‍♂️

Which AI

2026-04-17T19:06:06Z

🎭 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 😂.

Keep coding, keep running 🏃‍♂️

Conferences 25

2026-04-17T19:06:06Z

iOSConfSG

📅 January 15-17

📍 Singapore, 🇸🇬

🔗 iosconf

🎥 youtube

AppDevCon

📅 March 18–21

📍 Amsterdam, 🇳🇱

🔗 appdevcon

🎥 videos

Swift Heroes

📅 April 8–9

📍 Turin, 🇮🇹

🔗 swiftheroes

🎥 youtube

try! Swift Tokyo

📅 April 9–11

📍 Tokyo, 🇯🇵

🔗 tryswift

🎥 youtube

Deep Dish Swift

📅 April 27–29

📍 Chicago, 🇺🇸

🔗 deepdishswift

🎥 youtube

iOSKonf

📅 May 13–15

📍 Skopje, 🇲🇰

🔗 ioskonf

🎥 youtube

Swift Craft

📅 May 19–21

📍 Kent, 🇬🇧

🔗 swiftcraft

🎥 youtube

WWDC

📅 June 9–13

📍 Cupertino, 🇺🇸

🔗 apple

🎥 youtube

NSSpain

📅 September 17-19

📍 Logroño, 🇪🇸

🔗 nsspain

🎥 youtube

Swift Connection

📅 October 6–7

📍 Paris, 🇫🇷

🔗 swiftconnection

🎥 youtube

SwiftLeeds

📅 October 7–8

📍 Leeds, 🇬🇧

🔗 swiftleeds

🎥 youtube

Pragma Conference

📅 October 30–31

📍 Bologna, 🇮🇹

🔗 pragmaconference

🎥 youtube

Do iOS

📅 November 12-13

📍 Amsterdam, 🇳🇱

🔗 do-ios

🎥 youtube

Keep coding, keep running 🏃‍♂️

Async Concurrent Map

2026-04-17T19:06:06Z

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.

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.

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-04-17T19:06:06Z

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.

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.

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-04-17T19:06:06Z

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.

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.

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

2026-04-17T19:06:06Z

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.

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.

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.

Notes

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

2026-04-17T19:06:06Z

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	❌ (only compiled binaries)	❌	❌
swift package reset	✅ (complete)	✅	❌
swift package purge-cache	❌	❌	✅
rm -rf .build	✅ (complete)	❌	❌

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

2026-04-17T19:06:06Z

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

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

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

2026-04-17T19:06:06Z

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

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.

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

2026-04-17T19:06:06Z

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.

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.

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

2026-04-17T19:06:06Z

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.

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

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

2026-04-17T19:06:06Z

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.

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

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

2026-04-17T19:06:06Z

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.

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.

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

2026-04-17T19:06:06Z

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.

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

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

2026-04-17T19:06:06Z

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.

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

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

2026-04-17T19:06:06Z

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.

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.

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

2026-04-17T19:06:06Z

Schema and Namespace

When defining a data model in Vapor, it’s possible to specify the schema, which corresponds to the table name in the database. However, to maintain an organized architecture, it’s recommended to group tables into different namespaces based on functional criteria, rather than concentrating them all in the default schema. This practice facilitates logical separation by domains or application modules.

Implementation

To assign a table to a specific namespace, you must override the static space property in the model. This property allows you to define the namespace where the table will reside, providing more granular organization of the 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() { }
}

Consideration

It’s essential to declare the space property as type String? (optional). If declared as String (non-optional), it won’t override the inherited property from the Model protocol, but will create a new property with the same name instead. This will cause the framework to ignore the namespace configuration, keeping the tables in the default schema without any apparent error indication.

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

2026-04-17T19:06:06Z

Partial Indexes

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

Problem

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.

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.

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.

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.

Final Notes

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

2026-04-17T19:06:06Z

From refactor to data race in Swift

During a refactoring process to convert previously sequential functionality into concurrent processing, I encountered 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.

Actor with array

private actor EventsActor {
    private var events: [SportEventModel] = []

    func getOrCreate(
        name: String,
        cityId: UUID,
        build: () async throws -> EventModel
    ) async throws -> EventModel {
        if let event = events.first(
            where: {
                $0.normalizedName == name
                && $0.$city.id == cityId
            }
        ) { return event }

        let event = try await build()
        events.append(event)
        return event
    }
}

Advantages:

Simplicity.
Safety against data race conditions.

Disadvantage:

Inefficient search for large volumes O(n).

Actor with dictionary

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 data race condition

Logical data race condition

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.

Solution

To prevent this, it’s necessary to 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
    }
}

Lessons learned

An actor alone doesn’t prevent logical data 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

2026-04-17T19:06:06Z

Timestamps

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

Problem

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

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

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 🏃‍♂️

☁️ Cloud Server

2026-04-17T19:06:06Z

☁️ Cloud Server

When you work with backend, unless you’re working on a local network and nothing you do will go outside, you’re going to need a cloud server and the sooner the better 🚀.

Working locally is great, but having a cloud server is a step forward, and it’s better to start as soon as possible to have a development server in the cloud.

🔧 CPU Architectures

As technology advances, there are more and more options both in providers and processor technology 💻:

AMD 🔴:
- ✅ Excellent price/performance ratio
- ✅ Mature and stable x64 architecture
- ✅ Wide software compatibility
- ✅ Ideal for high-performance applications
Intel 🔵:
- ✅ Historical leader in the server market
- ✅ Excellent enterprise support
- ✅ Specific optimizations for legacy applications
- ✅ Consistent and predictable performance
ARM 🍃:
- ✅ The latest to arrive but with great potential
- ✅ Superior energy efficiency
- ✅ Better price per core
- ✅ Ideal for microservices and containers
- ✅ Lower consumption = lower operational cost
- ⚠️ Some compatibility limitations with legacy software

💰 Free Tier - Oracle Cloud

I’ve opted for Oracle Cloud and its free tier, which offers you an ARM server, as it’s the option that best fits my needs 🎯.

🖥️ VM.Standard.A1.Flex (Ampere ARM)

⏱️ Up to 3,000 OCPU-hours per month

🧠 Up to 18,000 GB-hours of memory per month

🚀 1 server with 4 OCPUs + 24 GB RAM running 24/7

🔄 Or several smaller instances (example: 4 × 1 OCPU + 6 GB RAM)

💾 Up to 200 GB combined between boot volumes and blocks

♾️ Free indefinitely, always within plan limits

⚠️ Oracle may reclaim inactive instances (no significant usage in 7 days)

🌍 There may be regional restrictions due to lack of capacity

💸 100% free within the Always Free plan

Keep coding, keep running 🏃‍♂️

Claude Code

2026-04-17T19:06:06Z

🤔 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

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

2026-04-17T19:06:06Z

❤️ 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 🏃‍♂️

La liga, thanks!

2026-04-17T19:06:06Z

My website blocked during La Liga matches

If you’re trying to visit my site during a La Liga match and it’s not loading, you’re not imagining things — it’s actually being blocked.

In Spain, La Liga applies aggressive anti-piracy measures, and one of them is blocking access to websites hosted on Cloudflare’s network during live matches. Unfortunately, this means that if your website is hosted on Cloudflare — like mine is — you might get caught in the crossfire, even if you’re not streaming or distributing any illegal content.

Cloudflare protects and accelerates millions of websites globally, but due to La Liga’s policy, entire IP ranges or CDN edges may be blacklisted, which affects innumerable legitimate websites.

Why does this happen?

La Liga uses automated systems and DNS-level blocking to restrict access to what they consider potential piracy sources.
Cloudflare is widely used by all kinds of sites, including those that host pirated sports streams — so their IPs get flagged.
As a result, many innocent websites are blocked during games, simply because they share infrastructure.

What can you do?

If you’re in Spain and you can’t access my portfolio during a match, try again later.
If you’re curious about the issue, there are online tools to test if a domain is being blocked.
Or use a VPN to temporarily bypass the restriction (just for browsing my portfolio, of course 😅).

It’s a frustrating example of how overzealous digital enforcement can harm the open web — even small developer portfolios like mine.

”Thanks, La Liga!!”

Update: I eventually found a simple fix for this problem. If you want to know how I solved it in 5 minutes, read Only DNS.

Keep coding, keep running 🏃‍♂️

My first article

2026-04-17T19:06:06Z

🚀 Big update on my website!

Today I’m launching an important update to my personal website, which is now built with Astro and Tailwind.

I’ve added the ability to write articles — and this is the first one!
From now on, I’ll be sharing my experiences, discoveries, and daily challenges as a Swift developer.
I might also share a bit about my personal life.

⚡️ No fixed schedule:
I’ll post whenever I have something relevant to share — whether it’s problems, solutions, curiosities, or new technologies I’m exploring.

With this new version, I can focus solely on writing articles in Markdown; everything else is fully automated.

If you’re interested in Swift, iOS, visionOS, Vapor, full-stack development with Swift, and the Web, or simply want to join me on this journey — welcome!

Keep coding, keep running 🏃‍♂️