In the previous post we looked at hidden furnaces in agentic products. The example was the most common one, title generation. You type the first message, and the product quietly asks another model to name the conversation. Small and useful.
Something that is important to understand when working with agentic products is that we are always in the hands of the product developer.
The most interesting AI workflow I have right now is not a coding workflow. It has code in it. It has a small Swift CLI, some auth state, a few JSON exports, a Codex automation, and way too much knowledge about how Discourse represents unread things. But it is not one of those fancy loops that will make you a product overnight.
A few weeks ago I read An Interpreter for Swift, from Cocoanetics, and I had that nice feeling of somebody else having already articulated the thing that was vaguely floating in your head.
Skills are everywhere right now. People talk about them as if they were some magical incantation that will make AI more powerful while also keeping it under control.
In the previous post we gave superpowers to the harness in the form of a bash tool. Even doing it just for the learning experience, it was already very eye-opening. It made this little Swift harness feel much closer to the real thing.
After teaching the harness to load AGENTS.md, my mind went back to thinking about the tools, and wondered, do we even need multiple tools?
In the previous post, Have You Built an Agent Harness Yet?, we built a tiny harness in Swift. We gave it a loop, a prompt, and some tools, and with that it already had most of the features we are used to with modern AI. No magic. Just autocomplete, and a harness deciding what the model gets to see and do.
For years I have repeated a thing that I still believe. Every programmer should write a promise library once. I think agent harnesses are the 2026 version of that exercise.
I was migrating to a newer version of The Composable Architecture, which meant there was a list of deprecations to clean up. One of the things on that list was adding InferSendableFromCaptures as an upcoming Swift feature flag across all our package targets.
There was a period during the Swift Evolution Concurrency discussions that I remember very fondly.
Today I made an exciting discovery: the existence of AnchoredRelativeFormatStyle. An API that, as of the time of writing this, barely appears in search results other than Apple’s sparse documentation. And to my surprise, it’s exactly what I’ve been looking for over the past few years.
Recently, while watching a Tsoding stream, I saw something that piqued my curiosity. Alexey demonstrated how one of his applications could render a video just by calling into the ffmpeg binary directly, instead of using it as a source code dependency or even a static or dynamic library linked to his program.
Sometimes in command line tools we want to perform some cleanup final task before the process is killed. To detect this scenario we can hook to unix signals like an interrupt and perform the needed work before existing from the process.
Recently, I finished an almost final draft of my novel and decided it was time to refresh my online presence and website. Instead of starting my next novel, I dove into creating the next version of my site, what I call alejandromp4. And, of course, you know what that means… using a new static site generator! Yes, I have a problem with focusing my hobbies; I’m working on it.
In my team, one of the things we always make sure of is keeping our dependencies up to date. We rarely add a dependency without a really good reason, and when we do, we assign an owner who is responsible for keeping it up to date.
Every year SwiftUI improves and gets new modifiers that widen the capabilities of the framework. Sadly, as responsible developers, we can’t use any of that because our users take some time to update and, as opposed to the Android ecosystem where Jetpack Compose is just a library embedded in every app, we need to wait for our users to be at the required minimum OS version to enjoy those fancy new tools.
It’s been a while since the last time I thought about traits and mixins in Swift, but the WWDC23 presentations about macros brought a lot of memories from those times when I really lamented not having that functionality in the language. Thankfully, Swift 5.9 gives us a form or meta-programming that allows us to get some basic support for mixins.
WWDC23 is over and as previous year I’m sharing my unedited notes from all the sessions I’ve watched.
One of the many things I love about working with The Composable Architecture is how it encourages the developer to focus on domain modeling. I think that properly designing the models or entities of a domain is one of the biggest contributors into good code, and the lack of it makes everything way harder than it should be. Thankfully Swift is a great language that allows us to express almost everything we need to in a very strict and concise way, another reason the language of your choice matters most than people pretends.
Buckle up. This is an adventurer journal while exploring what’s the best way of exposing the new style of formatting APIs in Foundation. We will walk through the paths of the type system, including existential types, generics and type erasure; and discover the magical possibilities of the dependency system.
The folks at Point-Free have given us yet again a new tool to improve our Swift development: swift-dependencies, see their announcement. Let me show the journey I’ve been for the past couple of hours with excitement and discoveries with this new library.
I’ve been very excited about memory ownership improvements to come to Swift, and now that they seem to materialize, I needed to share it with you. Specially because I feel this topic is very complex in people’s mind, and many will discard it as something only useful for experts, advanced uses or even “for nobody, Swift is getting too complex”.
One of the nice things about Swift Concurrency is its cooperative thread pool. When writting concurrent code you should not think about threads but is still good to know how things work under the hood.
In the early days of Swift, one thing I really enjoyed was the focus on properties (bye-bye ivars!) and the unification of stored and computed property syntax. It became very common to define properties that initialized some parts of your view automatically.
Swift’s Optional type is one of the biggest hits of the language. Mainly because it’s opt-in. Everything is non-optional by default, which solves the old problem of having to deal with nulls everywhere. That said, nulls (or Optional.none) still shows up a decent amount of times, so the second thing Swift did very well was to provide great affordances to work with optional at the language level.
Sometimes some topic gets in my head and doesn’t leave until I’ve gone far enough to satisfy my curiosity. Usually this ends up with me spending days writing some code that just goes to the trash once I’m done with it, but today I decided to share a bit of one of these rabbit holes I went down to.
Following Structured Concurrency was one of the best decisions Swift could have made when introducing concurrency into the language. The impact of that decision on all the code written with concurrency in mind can’t be underestimated.
One of the beautiful things about Pointfree’s Composable Architecture is how you can start using it on a smaller part of your app. It makes it very easy to improve a codebase without having to stop the press, which is something that I always require of any new technology.
Today I want to show you a rather obscure feature of Swift. You will learn a bit about Swift’s type system, type inference and other nice powers that the language has.
Today I want to share a weekend experiment where I built the classic Matrix effect in SwiftUI. It all started after seeing this tweet of the effect implemented in Compose. I immediately wondered what would it take me to build that in SwiftUI, so when I had some spare time in a weekend I gave it a go.
One of the most important aspects to understand about Swift Concurrency is how cancellation of async tasks works. You may expect that when a task is cancelled, it immediately stops, like when you kill a process. But that’s not at all how it works, cancellation in Swift is cooperative.
WWDC21 has brought many cool things and there is one that will facilitate a lot the creation of new projects with dependencies. Until now it was a bit of a pain to remember which packages you wanted to add on almost every new project. It was such an inconvenience that I even have my small CLI to create new Swift packages. But I think now there is a better way!
As last year I decided to share my unedited notes from the sessions I’m watching. The difference is that this time I’ve focued more on the topics and not on the sessions themselves. I’ve found this way more approachable this time.
We’re just in the week of WWDC and it’s clear that Swift’s Concurrency it’s the biggest topic that will change how we develop. I’ve been following its evolution for months now and I’m happy to see how Apple talks about it on their sessions, it helps us see how much they really believe in this new langauge feature.
Swift is about to get its Concurrency features. Their development is going very well, with many proposals actively reviewed and a lot of the work already available in recent snapshots. The story is big and with many moving pieces interlinked with each other. That makes it a bit hard to wrap your head around the entire thing. Specially for those that don’t read Swift Evolution as a hobby ^^.
SwiftUI’s layout system is very nice to get started with. Combining stacks and modifiers you can get very far very quickly, but at some point you will need to pass information up the view hierarchy. Thankfully SwiftUI has a solution for that: preferences.
Swift is well known for its lean syntax that helps newcomers understand the code relatively quickly. But it’s also a language with advanced and powerful features. Sometimes this makes part of the community wonder if it is going too far. In this post, I’m glad to merge these two worlds and use an “advanced” feature of the language to improve the base syntax. Of course I’m talking about Result Builders and a DSL for Dictionary literals.
In this post I want to show you a little behind the curtain. As you may have noticed if you follow me on Twitter, recently the tweets with links to this post got a little fancier. What you may not know is that these images are generated using SwiftUI.
One of the major benefits of SwiftUI is its amazing DSL. A feature that not only makes it nice to read but also makes it possible to use the type system to unlock tremendous performance benefits. AnyView is a view that defies all of this, and although useful in very specific circumstances, you should always try to use a better alternative.
SwiftUI is an amazing tool to create all sorts of views in our applications. But many times we want that ease of use to generate graphics that can be used outside of apps, usually as simple image files. That’s why is so useful to know how to generate images from SwiftUI views. This power unlocks a new world of possibilities!
Having a good process to update your tools is very important, specially for those that affect directly your code. I’ve talked about how I update swiftformat and this post will discuss my update process for SwiftLint.
Talking about how one updates a tool may seem a bit nonsensical, after all, what dificutlies can you have when updating a tool? Well, you would be surprised! But no, this post is not about issues when updating swiftformat. Quite the opposite!
Optional equitability is one of those aspects of Swift that seems simple at a first glance but that makes you stop and think twice when you encounter it in actual code. The good thing is that once you pause and look at it you realise is trivial.
Sometimes when writing Swift code you want to reference an instance before its creation. It’s not a very common, which is why I’m writing this post so I can easily remember it next time it happens.
This post is a personal opinionated piece around unit testing and the dogmas of our industry. Be sure to come here with an open mind and respectul toughts. I will also link to some Pointfree content so make sure you check them out.
The introduction of SwiftUI and previews changed completely my process of developing applications. Having such an easy way of quickly prototyping UI ideas affected the rest of my process. But as much as I love Xcode previews, they are not perfect. In this post I want to share with you a small trick that can improve a lot your iteration cycles.
Swift type system is quite powerful and the where clause is a very important part of how developers interface with it. This keyword allows developers to constraint code to a set of conditions. Swift 5.3 frees this keyword to be used in more contexts.
Swift 5.3 comes with a nice addition for enums: it will synthesize the required implementation to conform to the Comparable protocol. This reduces a lot the boilerplate needed to make your enums comparable.
A couple of weekends ago I was reading my Twitter timeline and I, don’t know how, ended up in this old tweet.
PointFree has released a library with their Composable Architecture and I’ve been showing it a little bit on livestreams and videos. This page wants to serve as an index and a summary for this content.
Protocol extensions are one of the most powerful features in Swift, but they also come with a bit of danger. In this post I will explore how this feature interacts with class inheritance and how dangerous it can be.
I shared a very special video on my Following Swift Evolution video series the other day, Road to Swift 6! I think it’s an important moment to look at what the future of our beloved language looks like so I spend some time cleaning up a transcript of the video to have it posted in this blog, for posterity.
With the release Xcode 11 is now easier than ever before to work with the Swift Package manager. If I enjoyed making CLI tools with Swift before, now it’s a pleasure! Lately I’ve been working on a small plugin for the recently released static site generator Publish. And the plugin is itself a Swift Package so I had to opportunity to enjoy SPM and Swift tooling development.
One of the common things we want to display with SwiftUI are lists of our models. The basics of it are pretty easy, you just need to use a ForEach view.
SwiftUI has some presentation modifiers to display alerts, sheets and full screen views. On one hand, presenting an alert is nice and easy, it feels really well designed. But on the other hand presenting a modal screen (or action sheets or popovers) is too cumbersome.
In my previous post about SwiftUI buttons I described a technique to reuse button configuration with a ViewModifier. Now that beta 2 is out, we finally have the proper tools to reuse styles in a much better way!
Yesterday I shared with you a post where I was trying to understand SwiftUI’s layout system in order to implement equally spaced distribution for views inside stacks.
One of the things that I still don’t fully understand about SwiftUI is how to customise the layout of views.
The abstractions on SwiftUI are so composable that customising the UI it’s basically an intrinsic property of the framework. Let’s take a quick look at some things you can do with Button.
WWDC’19 has been great and I’m obviously hyper excited about SwiftUI but if there is one thing that I like more than watching a great announcement is watching great video content, and the WWDC sessions are the best!
After all the game changing announcements on the WWDC one of the words that is used a lot is “finally!”. We’re excited and happy that Apple as finally given us a new UI framework, FRP, etc. But it’s interesting how the way we all talk implies that Apple has been ignoring us for years and until they woke up in 2019.
WWDC ’19 is over, and what a week! Let me start by saying that this is probably the best WWDC ever. We have seen the announcement of game changing technologies for the Apple developer community, but even ignoring those big announcements, the rest of smaller details make on itself a great WWDC.
I’ve already mentioned how I moved tasks from Todoist to Bear but one of the missing pieces of the migration was some lists that I had on Reminders.
The Property Delegates proposal has been in review for some days by now and is a good example of the strength of the Swift community.
Last year I wrote about Improving struct composition in Swift by levering the using keyword and feature taken from Jai. Recently I’ve been inspired by pointfree to implement this feature using code generation.
There is this commonly followed programming rule that says that parameter lists must be short.
Today I’ve used Protocols to make a generic function only accept a certain number of types. The interesting part is that the only thing the protocol has is an associatedtype, there are no other requirements, which may seem a little weird at first.
After finalising the InterpolableLanguage protocol in the third part of this series we will finally put it to good use and show an example of this can be used on day to day code.
In the first article of this series we made a safe string type that was safe to use but with a cumbersome API, and on the second article we made that API much nicer to Swift 5 interpolation. On this post we will generalise that conformance to make it easy to create new safe languages.
In the previous article we made a safe string type that was safe to use but with a cumbersome API. In this part we will use new Swift 5 interpolation system to make it really nice to use.
The String problem is something that I’ve explored before, in my 2015 post Solving the Strings Problem in Swift. The solution back then was far from ideal as Swift was missing a powerful String interpolation system.
This is a small trick that I use when I’m writing a script in Swift that performs some operation in a large number of objects, usually files. More often than not this operation is somehow destructive and ends up overwriting the original file, so I want to make sure that I got the changes right before applying it to the entire set of data.
After having clear the requirements for a notes system and comparing different options I decided to give an honest try to Bear. Now, one of the first things I need to do is move the tasks from my current system, Todoist, into it.
In the past few days the Swift community has been awoken again with the promise of a better way of using Swift for scripting, all thanks to swift-sh.
Everyone knows that NSSpain is one of my favourite conferences but sadly this year I haven’t been able to assist. Luckily for me the recordings are already up so I watched the talks online ^^
One of the best things of modern Swift is the introduction of KeyPath. It allows us to reference getters and setters as first class values in our code. With them you can simplify a bunch of code and make it less error prone. In this post I’m gonna evolve the groupBy function from GroupBy in Swift 2.0 to use this new functionality.
On 2014 I wrote a post about how to drive a UISegmentedControl with the new powerful Swift enums. Back then the major complain was that to get all the cases of the enum you had manually list the cases of the enum, which was tiresome and error prone.
I was reading the Rust forums when I saw this post talking about an oficial Rust error crate. It reminded me about the discussions in the Swift forums about making a bigger standard library.
As every year after WWDC is time to sit down and watch the videos of the sessions! I wrote last year about How I watch the WWDC videos and this year I’m doing a similar thing. I still use the unofficial WWDC for macOS to download the videos and watch them at more than 2x in VLC. This time I decided to use a single note in Notes app to keep my notes of the sessions and to mark the videos I’ve seen. And because everything is in a single note it makes it really easy to share, so I decided to share my notes with you!
Today I woke up to receive great news for the Swift community. The Swift Forums now have a new section to talk about some community projects!
RxTesting makes testing a custom Rx operator an enjoyable experience. Being able to fake time simplifies a lot the develpemnt of reactive code and helps on building confidence in the code.
How flatMapLatest cancels an API request? This is a common question that people has when they start learning about Rx. Specially since RxSwift has an example of this in the README.
p5.js and the rest of Processing projects are an amazing way of making coding more accessible to everyone, allowing creative people to make interactive applications with ease and teachers to introduce kids to programming in a entertaining way.
One year ago I decided to start working on a Lox interpreter in Swift following Bob Nystrom’s book Crafting Interpreters. Today I’m happy to say that the work has been completed. Mission accomplished.
Today I was reading Composing types in Swift which showcases the different ways of composing the different types in Swift: structs, classes and enums. Is a good read, specially if you are too deep in the OOP mindset.
While programming with a static type system there are times when you write the definition of a function but you still don’t have any idea on how to implement it.
Swift forums are live! This is a great change that many of us have been waiting for a long time and that marks a new era for the Swift community. I would like to take this moment to reflect on the state of Swift and express some of my wishes for 2018.
I recently discovered the podcast LambdaCast, a really interesting podcast about functional programming with hosts that are at different points on the path to functional programming. This gives an interesting view to the listener that can get explanations from starters and experts. They usually talk about FP in terms of how to use them in imperative land, mainly with Javascript and C#. That’s nice for many people, but every time they give an example my brain starts thinking about how Swift deals with it.
Watch how I create and publish a library with Swift Package Manager for the first time!
In this post I’m gonna explore the talk Idiomatic Kotlin by Dimitry Jemerov. I’m gonna do it by showing how each of the topics the author talks about could be done in Swift.
I’ve been always a big fan of productivity, time is gold. But funny enough, as many other people, we fall into the traps of being productive by just spending more time on looking for tools and solutions to be more productive. This is not a bad thing per se, but it can end up being. You may end up having a false sense of productivity because you improve your workflows and tools. But, in reality, the only thing that matters is the output of your work and, specially, your happiness.
Some days ago I finally merged one of the biggest Pull Request our team has seen, the migration of our codebase to Swift 3. I decided to write some words here as a way of remembering the beginings of the language we expect to work with for ages.
The chapter 5 of Crafting Interpreters has been published and after a first read I started writing some Swift code to continue my implementation of the interpreter. Here there are some thoughts that I’ve captured while implementing the Expression classes.
A couple of days ago I was reading Crafting Interpreters written by Bob Nystrom and it awoke my passion for programming languages so I decided to implement an interpreter for Lox in Swift!
One of the things I think is really important in any team is to keep track of the performance. Not to use it as ammo to blame individuals but to learn and have data to keep improving.
Yesterday I gave a talk about Functional Reactive Programming to my coworkers at LifeWorks. At first, I wanted to give some insight about it to the Android team, as they were using Rx for the API layer. But at the end there were more assistants than I expected. From Android and my iOS team to Web and backend developers. So I had to do the talk as generic as posible (although the code is in Swift) and also try to convince everyone about how this is the next step.
I’ve always been a big fan of Linked Lists. Maybe is because it was one of the first data structures that I learn how to implement and they were my introduction to the fascinating world of pointers. Nowadays I hardly think about pointers in my daily work. In Objective-C you just treat them as the objects you want to message with, and in Swift the lovely * has disappeared. But I still feel nostalgic sometimes.
The post Mock yourself, not your tests immediately captured my attention just by saying “I feel like we abuse of them”. As I’ve been having more and more the same feelings about mocks in my tests.
One of the things that Apple released on WWDC was the official support for Xcode plugins. Although in a very limited way, is really nice to see Apple opening Xcode with an official framework.
Being able to conform to a protocol and automatically have the implementation that you need is really a game changer. Having trait like functionality is one of the most interesting aspects that Swift has given us.
This is an update to an previous post about using blocks to simplify in Objective-C.
The other day, while I was writing a Swift script, I added an option to make it run continuosly so it could be on a server doing its job without stoping. for eva.
This is the second part of my posts about the sate of scripting with Swift. In the previous post I wrote about what I expect from a language toolset when writing scripts and where Swift still needs some improvements. In this post I want to do a quick overview of the libraries that I used to write the script.
In the past few days I’ve spend some time writing a little script in Swift and I thought it was a good time to revisit the state of the Swift ecosystem as a scripting language.
Getting C-level performance in Swift for numerical algorithms is quirky but not particularly difficult. If you limit yourself to value types (no classes or existentials), use unsafe pointers and tuples instead of arrays, use overflow discarding operators &+/&-/&* instead of normal +/-/*, use while or repeat/while for your loops, then Swift and clang C will generally compile to identical instructions.
I really recommend reading how Maxim made his FlatBuffer library 10 thousand times faster Swift.
For those occasions when you need to check something some state at regular intervals.
The other day I had to work with some date formatting on iOS and Android and I end up using the great https://nsdateformatter.com website. I immediately missed the option to change the locale and seeing that it was open source I took my chance to contribute.
Good analysis of the rejected Swift proposals by Chris.
A while ago I wondered how easy would be to make a screenshot of a window in OS X from another application using some system API. With that idea in mind last Christmas I started a project that ended up being too time consuming.
I was reading about Error Handling in Rust to have a better understanding of the implications of typed throws in Swift (thanks to David for the proposal). At the end of that guide there is an example using a simple script to search for the population of a city in a CSV. This are my conclusions after porting that script to Swift.
We are used to treat closures as first class citizens in our code. Same goes to functions as they are interchangeable. But we often don’t think of them as actual types. So they also can play with the rules and abstractions that we usually attach to classes or structs.
Since Swift was open sourced I’ve ben scanning trough the mailing lists and there has been some interesting proposals for the future of the language. There are other places were people summarizes the conversation, but I just wanted to write here the proposals that are the most interest to me.
In this post I try to port the type based solution to the strings problem ideas by Tom Moertel to Swift.
Sometimes is a small Swift library that makes it easy to run code… sometimes. Well, actually, just once.
I’ve been following the linked blog because I’m really interested in the usage of Swift in environments different from the typical Apps. And because using it for robotics seems pretty cool.
Today I had to do a little research on the state of JSON mappers in Swift for a new project. I’ve been using a simple JSON library to help me deal with the JSON structure in a safe way, but for this project I had to use something a little more sophisticated like a mapper.
The other day I had some spare time and I started exploring the idea of a Stack in Swift using protocols. For what? For fun.
The author of the linked post gives some reasons on why Swift is a good language for an introduction to computer science class. I’m really interested in Swift being a good language to teach and I found the post really interesting.
This post is one of those ones that I’ve been wanting to write for a while. It was some days ago when, by coincidence, I was reading a post about dependency injection at the same time that a coworker came to talk with me about the topic.
In the last version of BWallpapers I added the ability to save the wallpaper to a specific Wallpaper album in the Photos app.
Protocols in Swift are really powerful thanks to be able to be generic and to protocol extensions. But there is some things that drive us nuts. Mainly the usage of generic protocols in collections.
The other day while I was adding the ability to generate the protocol file to my Sketch plugin I took the opportunity to make a couple of changes to the code.
2018/08/23: A new version of this post is available. Using KeyPath to simplify the call site and reduce possible mistakes.
From Wikipedia, Singleton in Software Engineering:
I would like to talk about a video of a great talk that I really recommend. I’m really interested on the topic of sharing code between iOS and Mac because basically is what I do with BingWallpapers.
Yesterday night I found myself reading this code in GitHub
As I said on my Fist impressions on WWDC 2015 I was really excited for finally having traits in Swift, in form of Protocol extensions. After playing with them this days I most than happy :) But I’ve seen some people struggling to understand how the dispatching of the methods works, in other words, which method will be called?
I mentioned the new Swift error handling in my WWDC first impressions post. And although it’s true that I still have not had the opportunity to use it in a real project I’ve been playing with it in playgrounds :P
Every year, after the WWDC I usually record a podcast episode talking about my feelings of the keynote. This year I’ve been keeping a list of the things that I like the most, so I will leave it here as a reminder to myself.
Today I’ve been updating BingWallpapers to use the last version of Swift and also include the latest changes of WallpapersKit, the framework that is shared across the Mac and iOS versions.
When I wrote my srly script I thought on doing it in Swift, but at the end I decided to go with a well known scripting language, Ruby.
If you like this post I recommend you to read a more recent article about the same topic: Solving the String problem with Swift 5.
Yes, the title is not wrong. Apple just released Xcode 6.3 beta that includes multiple huge improvements to Swift 1.2 solving a lot of concerns that we all had. But the cool part is that indirectly Objective-C also has improved.
By default a Swift playground stops it’s execution when the top level function finishes. If you want to run async code you will never see the results. The system doesn’t provides a waiting architecture like node.js, which is a bad thing scripts.
This is another thing about extensions that I was not expecting. The other day while implementing Jlaner I had some problems with extensions.
For now, the Siwft and Objective-C protocols are two diferent things. The biggest differences is that Swift protocols can have structs and enums and can be adopted by value types.
2018/08/18: Swift 4.2 introduces automatic synthesis of enum values. Check out the new version of this post.