Why native?

Atelier seamlessly integrates with your existing apps, including Safari, Finder, Shortcuts, and iWork. Your Mac already has the ability to automate tasks, and Atelier simply provides Claude Code with a seat at the table.

What Atelier does differently

Claude Desktop is great, but I wanted something that felt like it was designed for macOS, not just ported to it.

Conversational UI

Atelier lacks “Chat, Cowork, or Code” toggles, consolidating all features into a single session. This is my biggest frustration with Claude Desktop: each tab offers a completely different set of capabilities and operates independently. Forcing users to switch between three tabs for no apparent reason only adds to the frustration, especially considering the app’s sluggish and glitchy performance at the time of writing.

Automation is built in

You don’t need to keep the app open. Schedule a task, close it, and then return to the results. Currently, the app mimics the Shortcuts UI to some extent, but I’ve included AppIntents in the roadmap. This will allow you to directly trigger “Ask Claude” (which is currently only available in the iOS app) or automate a project.

Memory is managed automatically

The app tracks context within a session, so Claude remains sharp without you manually managing it. Now that the context window is 1 million tokens, this is simpler. However, it comes with slightly degraded performance. The app uses hooks to detect the compact window and then times the conversation into reusable pieces for future reference.

The whole idea of Atelier is to maintain a single, massive conversation, but you’re welcome to create as many as you need.

Multiple windows, multiple projects

Open multiple sessions simultaneously, just like you would with your favourite apps. This way, you can switch between tasks without losing your train of thought. Your AI agent should function similarly to your other Mac apps. For example, if you need to work on multiple folders at once, simply open a new window for each folder and chat away.

You get the idea, a lot of features in the app.

Built in 10 days

The app is far from perfect, and it’s definitely nowhere near the scope of Claude Desktop. However, it works well, is fast, and is currently available as a free download. Additionally, it’s fully open source, so you can peek into the code or expand its capabilities.

What’s next

I’m working on deeper OS integrations. The goal is to create an app that can operate autonomously in the background, leveraging macOS’s native scheduling and automation features, allowing you to focus on other tasks.

If you’re a Mac user residing in Claude Code and have ever wished for a proper home for the CLI, this is it.

Download Atelier for free → https://raul.xyz/atelier

The problem

I’ve been using Claude Code a lot. Across multiple projects, multiple branches, dozens of sessions. It’s awesome; but after a while, I started losing track. Which session was on which branch? What did I ask last Tuesday? What’s still in progress? Claude Code stores all of this locally in JSONL files under ~/.claude. I wanted something visual. A map of everything I’ve been working on, organized by project and branch, that I could glance at and immediately know where things stand.

The AppKit attempt

Naturally, I reached for Swift. It’s what I know best, and a native macOS app felt like the right tool for a local visualization. I started building a radial graph in AppKit. Nodes for projects, branches radiating outward, session cards at the leaves. It looked promising at first, but the more sessions I loaded, the worse it performed.

Dragging, zooming, rendering — everything got sluggish.

To clarify, this was entirely my fault. Native code is perfectly capable of handling this. However, while debugging drawing passes and dealing with coordinate spaces, I kept reinvented the wheel. Dealing with bezier curves, hit testing, and pan and zoom gestures; all of which the web has already solved countless times. The JavaScript community is full of examples of precisely these interactive graphs.

So I did what any reasonable person would do. I selected all, and pressed delete.

The pivot

Node.js with Express for the backend, vanilla JavaScript and HTML5 Canvas for the frontend. The server reads Claude Code’s local session files, groups them by project and branch, and serves them as JSON. The browser computes a radial layout and draws everything on a Canvas visualizing branches, color-coded projects, interactive session cards you can click to resume directly in Terminal.

The learning side quest

Every project needs one. Last time it was SwiftUI component models. This time, it was the realization that sometimes the best technical decision is choosing the boring tool that fits the problem, not the sophisticated one you’re most comfortable with.

I also learned that Claude Code’s local storage format is surprisingly well-structured. Each session gets its own JSONL file with metadata, prompts, and responses.

You can still just do things

This is the same lesson from last time. I wanted something. It didn’t exist. So I built it (twice, technically).

Try it for yourself.

GitHub - raulriera/claude-code-canvas: Visualize your Claude Code sessions as an organic radial mind map

Workout Widgets App

I recently decided to try Apple Fitness+. It’s a beautifully designed app with a wide variety of great workouts. However, despite enjoying the overall experience, I was surprised to find that there were no motivating widgets.

For me, consistency is built from visibility. It’s about seeing the thing you care about every day, rather than being nudged by another notification you’ll quickly swipe away.

It all boiled down to one thing: I wanted a widget that would do one job and visually remind me that I haven’t worked out today.

GitHub - raulriera/WorkoutWidgetsApp: Dead simple workout motivation app. Did you work out today?

Learning Opportunity

As usual, every project requires a new side quest, a small learning opportunity. This time, I repurposed a previous idea into the SwiftUI component model.

In this case, I took an old concept from an app I worked on a while ago, stripped away the unnecessary layers, and rebuilt it using SwiftUI’s latest features. This wasn’t a requirement, but rather an opportunity to solve the same problem using a new set of tools.

Startup Tasks, every app needs them

If you’ve worked on apps professionally, you know there’s a set of maintanance or “startup” tasks your app needs to complete before it’s ready for users. This might include selecting your age, your current location, or reading from local storage. I wanted to tackle this problem using SwiftUI component models.

I tried a few things, but I ended up settling on a custom container. It allowed me to accomplish almost everything I wanted with the cleanest API. However, I’m fully aware that this is over-engineered, especially for the type of app I was making (and the fact that it was only one startup task needed). Nevertheless, it was a fun project to work on, where I could delete everything, try something else, and so on.

You can see the component here, and its usage it’s pretty straightforward

TaskContainer is a custom container that iterates over its children and hides anyone whose “task” hasn’t been marked as completed. This could be useful with all the examples above, where you place all your tasks one after the other (or in parallel using a Section group).

That’s it

This is essentially the entire article and app. I doubt such a simple app would be allowed into the App Store. For now, the code will have to suffice.

Vibe coding doesn’t have to be digital slop. It can be just as valuable as a learning tool, a way to bounce around ideas, or simply a way to explore different ways of writing code.

I recently revived one of my old projects and started using GitHub Copilot’s agent mode to maintain it. In just two days, I’ve shipped more features and improvements than I had in the last six years — mostly because I just haven’t had the time. Copilot helps me kick off tasks quickly, and I either merge the suggestions as-is or make small tweaks before merging.

It’s genuinely been a magical experience ✨.

AI might not be for everyone. But one thing is clear: we are the real winners of the AI race. Every company is building a similar product, all racing to become the next big thing in AI. The result is that everything is becoming better, faster, cheaper, and more innovative. It has genuinely never been a more exciting time to be a developer.

For now, I’ll keep experimenting with all the tools out there. But I’ve got to hand it to Microsoft — while so many of us are talking about coding in Cursor, VSCode and Copilot are steadily carving out a solid place in my development workflow.

The following tweet inspired me to finish an animation I had planned for one of my apps. The end result was better than I expected.

In Emoji Stickers, every time you select an emoji they fly into your canvas. This animation was just a straight line from point A to point B. There was nothing wrong with it, but always felt kind of stiff. Using curves, we can do better.

The code

I knew what I needed to do, I remember watching a WWDC video a while ago about CAKeyframeAnimation and using paths to animate along a given area. I was surprised that the implementation was actually very simple.

That is literally all, of course you need to tweak your timing functions, duration, etc to really polish it. But I will ignore that for this article and focus on the challenging bit, that second line. How can I draw this line? And more importantly, how can I debug it?

Drawing the path

I knew I wanted to add a curve into the translation of the view, changing the view origin wasn’t going to be enough anymore. Enter UIBezierPath and the delightful addQuadCurve function to literally do just want we need.

The final implementation looks like this:

If we breakdown the previous code snippet, you will find two (2) main themes: finding the points, and drawing a small curve between

Finding the origin and final destination of the curve.

Knowing the two points: the origin being the starting position of the emoji, and the destination the exact centre of the canvas. Now, all I needed to do is create a CGRect between the two points (this little rectangle will come handy in the next step)

With this information, the next step is to draw the line.

Plotting a small curve between the points

Drawing a curve between the two positions requires a control point which apple describes as follows:

The control point of the curve.

Not great 🙃, thankfully they have a nice illustration that is more helpful.

We find such point using our previous rectangle:

By randomly choosing between the bottom and top of the rectangle and assign that as the Y coordinate, and then choosing the middle of the rectangle as the X coordinate. We create a small amount of playfulness to the animation by giving at least two (2) variants.

Debugging the path

This was all great in paper, but how can we debug the rectangles, lines, and curves we are drawing? We probably have multiple choices, but I went with the most simple ones I could think of: using the debugger with quick look, and drawing them out to the app for better visualization.

Using the debugger was the easy part, we need to put a breakpoint in place right after we define our path and once the runtime stops there, simply click on it to see more information.

The most difficult but totally “tweetable” solution, was to draw the paths on screen every time we add something. That can be achieved with the following code snippet:

Technically, all of them could be CAShapeLayers but I started with a UIView for some reason 😅. As you can see, we create a view representation of the rectangle between the two points, and finally add a layer to the canvas with the shape of the path we constructed.

Seeing it all together

That is all, and the best part is how it looks! This was probably one of the quickest wins I had in this project while still having a great impact.

Further reading

That is all!, as always you can find the full source code on GitHub https://github.com/raulriera/technical-articles

iOS 13 brings new dynamism to your apps.

Last year at Shopify we started developing the All-new Point of Sale. There was a small problem, given that all screens are presented full screen to the user we needed the ability to distinguish a modal screen versus the rest. iOS 13 had a great answer for this.

It feels like every new iOS version adds something to UITraitCollection or UIUserActivity. iOS 13 was no different, there was a small but powerful addition to UITraitCollection which comes handy when developing your universal apps. Specially if your app is presented as a floating window, that addition was userInterfaceLevel¹.

What is UserInterfaceLevel?

Apple describes it as the visual level for content in a window. The possible values are base, elevated, and unspecified. The first one being the window’s main content and the last one anything above it*. This will be the perfect match for our need of modal windows having a dedicated background colour.

* Check the comment section for a great explaining from Geoff Hackworth about how these values changes depending on other factors

Using it to meet our requirement

The previous snippet is how Shopify’s Point of Sale application is handling dynamic colours. You should focus on line #24, we detect the current elevation of the user interface and decide which of the two colour sets to use for this particular colour.

Now, let’s say we want to change the background colour of a view all we need to do is:

And thanks to the excellent UIAppearance² we can style our UINavigationController similarly how we styled the background view, and all our screens will be displayed with the correct colour.

Putting everything together into a project, it looks something like this:

Further reading

That is all!, as always you can find the full source code on GitHub

raulriera/technical-articles

1. Apple documentation https://developer.apple.com/documentation/uikit/uitraitcollection/3238085-userinterfacelevel
2. Apple documentation https://developer.apple.com/documentation/uikit/uiappearance

UserInterfaceLevel, the future of floating apps was originally published in Dev Genius on Medium, where people are continuing the conversation by highlighting and responding to this story.

Interface Builder is amazing for building UI. Code is great for extensibility. Why not use both?

I have a long-running joke in my Twitter bio about fighting in the great Storyboards vs Code wars. Using things like Storyboards is a hot topic among iOS developers. There have been many before it:

• Automatic Reference Counting vs Manual Memory Management.
• Auto Layout vs Manual Layout.
• Swift vs Objective-C.

You get the idea, status-quo versus new. I like storyboards, they allow me to create complex views very fast. But, using them comes at a great “merge conflict” cost if you are working with more than yourself.

What can we do about it?

I have praised FunctionalTableData before, a declarative UI building library developed at Shopify. Newcomers to this library will find how verbose it is to create a Cell (UIView subclass, and a State) when compared with similar solutions like React Components.

We can do better by using code for the states, and making the views using Interface Builder. The best of the two worlds.

Putting this crazy idea into practice

We won’t cover how to use FunctionalTableData, we did that in Building Apps with FunctionalTableData. We are going to skip forward and focus on the views. For that, we are going to turn to Xcode’s Interface Builder and create a new .xib file.

Using everyone’s favourite app as a guideline, lets recreate Instagram’s profile header. At the moment of this writing it looks like:

Turning to Interface Builder, we are going to add UIStackViews, UILabels, UIImageView, and an UIButton. After dragging around a bunch of views, it looks like so:

Imagine doing all those stack views and views by code, I am screaming too. But, how do we get this view to work with our HostCell implementation?

Loading the main view from a .xib file

Even though we created everything using Interface Builder, we still need to write a bit of code for our header file. Every IBOutlet connecting the views that we will manage with the state, which we will build later.

Everything in here looks very similar many apps we have done before, but what is that loadNib method? Without it, we will have to load the UINib from a Bundle, instantiate the view, and then apply constraints to pin it to the edges. Or, we can write a simple protocol to do all of that for us:

This protocol is very straightforward, the best thing it does is matching the name of the current class to our .xib file. That way, if we use it in our InstagramHeaderView.swift (See Image 3), we need its corresponding .xib file to be named InstagramHeaderView.xib.

No Cell in FunctionalTableData is complete without a state, let’s quickly create it using the knowledge we already have. If we have previously gone over the trouble of creating small state files for the base iOS views (UIButton, UILabel, etc) using them for big states like this one become as simple as creating properties.

Noticed how instead of creating multiple properties to manage everything about a Button or an Image, we simply create a property that holds a ButtonState and an ImageState. To learn more about these states, take a look at FunctionalTableData’s example project.

Putting it all together

You know the drill by now, we normally create a typealias to hide all the implementation details required by HostCell. Our new cell would be something like this

typealias InstagramHeaderCell = HostCell<InstagramHeaderView, InstagramHeaderState, LayoutMarginsTableItemLayout>

That is pretty much it! ✨. Using this cell is something we have cover before, if you need a refresher please head over to Building Apps with FunctionalTableData.

Did I miss anything? Get in touch on Twitter at @raulriera

People make mistakes. Let’s use allow undoing.

You have accidentally shaken your phone and noticed that little alert screen that says “Undo [something]”. In this story we are going to implement Undo and Redo actions in an iOS app.

By now you are making all your screens using a declarative and functional approach, right? 😉 If not, you can read all about it. Expanding on that approach, we can easily implement undo actions into our app if all our View Controller state is encapsulated like it was demostrated in that article.

Looking at the documentation

When I looked at Undo Manager it appeared like I was going to be dealing with Selectors, old Objective-C API, and whatever else was lurking underneath. I tried to get around this by creating a wrapper struct with some syntactic sugar.

struct Undoer {
  let undoManager: UndoManager
  ...
}

Thankfully, Geoffrey Foster talked me out of it and I end up choosing a better approach. By simply extending UndoManager to include one more function. Now, taking everything I had in the previous wrapper, all I was left with was this.

Pretty simple right? To be honest, the biggest issue with writing this short function was embracing the fact that you want to capture your variables inside the registerUndo closure, while also having it call itself.

Exploring the code

UndoManager works exactly like that. It retains a copy of the data in the closure so you can revert any changes by calling undoManager.undo() or redo() for that matter. Doing so, executes our handler callback and recursively calls itself again, but this time with the values inverted. Creating that loop of undo and redo actions that we desire.

Fixing the bug 🙃

There is one issue that you probably spotted by now. If we use reference types, we won’t be maintaining the previous data. Thankfully that is why we have the Codable constraint in the generic type T.

By leveraging Codable, we can implement a quick and dirty version of copy to serialize and deserialze the content of the data, so we can maintain the state.

This is more like it, now our UndoManager can store and restore the state of any class or struct, and we barely even had to break a sweat writing this.

You can find the source code of this function with a quick implementation into a View Controller in the following link.

raulriera/technical-articles

Did I miss anything? Get in touch on Twitter: @raulriera