I've been working on Boutique and Bodega for much of the last three months, officially celebrating the launch of Boutique and Bodega v2 today. If you’d like to learn more about what's new you can read about it in this tweet storm, or read a quick rundown below ¹. But this post isn't about Boutique and Bodega, it's about the process of building Boutique and Bodega.

If you'd asked me in April if I'd spend three months this year working on an open source project, I would have said no way. I left my job at Twitter to be an indie developer building apps that represent my vision of personal productivity, but life is funny sometimes. Life teaches the same lesson over and over again — you can't predict what'll be important to you at any point in time. I built something to answer my own question, "what does a good SwiftUI architecture would look like?” for my own apps, and that's what came to be Boutique. But Boutique has blossomed into much more than just a new architecture, it's become a whole new way to build persistence layers, SwiftUI apps, and for me its created a community of people who find my work valuable. Boutique has quickly become a key part of my present and future app development plans, while remaining simple and approachable through many iterations. I've already integrated Boutique into more than half a dozen of my own apps, notably without many issues or much work, and every day I hear from people about how they're using it as well.

I can't say it's all been ups though, there have been plenty of downs as well. I’m writing this post not with the intention of convincing you to build an open source project, nor am I trying to dissuade you from participating in open source. I'm aiming to provide a balanced perspective because I would like nothing more than to see you build something that's important to you, to leave your dent in the universe. If that dent takes the shape of open source project then it would be an honor to have provided a head start based on what I've learned, knowing better what to expect than I did. Continue Reading →

This Twitter thread offers a concise high level 13-tweet summary of this post's announcements, but you miss out on a lot of important detail that I highly recommend reading if you plan to start using the libraries I've developed and introduce in this post, or if you'd like to read an interesting technical walkthrough.

This post was updated on August 22, 2022 to reflect the v2 release of Boutique and related API changes.

Apple has never provided a blessed architecture for SwiftUI, and many developers have spent thousands of hours filling the gaps with their own ideas. A familiar approach for many developers is to take the MVVM pattern many people adopted in their UIKit/AppKit apps and translate it to the needs of SwiftUI. That can work well enough, but you begin to see some cracks in the architecture when you need to manage state and data flow due to how heavily SwiftUI leans on having a single source of truth. Others have taken the path of integrating powerful libraries such as The Composable Architecture which provide you with the tools to reason about your entire application. TCA takes inspiration from redux, more specifically The Elm Architecture, two patterns that are rather incredible in how they allow you to define your entire application as a tree of state. But TCA's great power comes with great responsibility a very high learning curve, which can make it difficult to learn personally. TCA's goals are much more of a fit for solving problems with a very high level of complexity, which may not be necessary for every app.

When it comes to developer ergonomics and program provability MVVM and TCA live on opposite ends of the spectrum. MVVM is lenient and depends on convention while TCA apps are built with rigidity in mind to guarantee correctness. This post isn't meant to be a tour of architectures though, I've mentioned those two patterns to show that there's a spectrum of how we develop software, and I believe there's room for something in between.

If SwiftUI shows us anything it's that declarative programming is the future of software development, and we need an approach to software development that leans into the strengths of the paradigm without being overly constrictive. What's needed isn't a whole new architecture, but to bring together tried and true patterns with a new concept, the Store.  Continue Reading →

Whether you're starting your design journey or if you've been doing design for years, nothing's more important than the fundamentals. The fundamentals are what help you get from 0 to 60, and when it comes to design it turns out that that 60% may be all you need. You can create something really beautiful by understanding color, spacing, typography, and animation, which is what we'll cover in this video. I gave this talk that at Pursuit, while live coding, showing you how to take an app from stock UIKit to something beautiful in only 15 minutes. I've been told quite a few times by people I've shared this talk with that it was invaluable for them, so if you've ever opened up Figma and thought "I don't know where to start", you should take 15 minutes to watch.

And if you need inspiration, here's a repository of resources I've put together to help you along your design journey. Continue Reading →

Is coding a science or an art?

— Matthew Garlington (@dejadu13) May 21, 2022

I've seen many versions of this question posed over the years, and to Matthew's credit it's a very good question. As you can see in the replies people translate their lived experience writing code and answer art or science based on however they conceptualize and practice programming. A few years ago MIT conducted a study that concluded "reading computer code is not the same as reading language", answering the question of whether coding is art or science with a rigorously documented "both". While I'm hard-pressed to argue with science, I'd like to provide a different answer, one that's a little more conceptual. Continue Reading →

The work of writing maintainable code is an ongoing endeavor and some of my favorite problems to solve are ones that build maintainable systems. Maintainable systems are ones you can learn once, easily manipulate, and ideally take from project to project. My favorite part of building maintainable systems is that it minimizes the amount of work I need to do when starting a new project, and like it is for many programmers hitting ⌘ + ⇪ + N to start a new project is one of the most satisfying feelings in the world for me. Continue Reading →

GraphQL has been on my list of technologies to learn for a few months now, and last week I came across Majid Jabrayilov's post, feeling pretty excited to tackle the subject. The post was very good, but it didn't answer the one question I've had as I've gone through numerous exercises to understand GraphQL, how do I make GraphQL requests without a library? Continue Reading →

I've been thinking about privacy lately. No, not online privacy, but about how APIs can balance exposing the right amount of implementation details without revealing too much.

I'll walk through a task I find myself doing often when building iOS apps, creating a view controller with header view, and four different ways to go about it. Continue Reading →

As iOS developers, a lot of our work involves taking models from a server, and transforming them to be displayed on an iPhone or iPad. This sounds like a job for some declarative architecture. 🤔 Continue Reading →

If you haven't checked out Part I, I recommend reading it because if you don't, none of writing below will make sense! Continue Reading →