After spending months writing, rewriting, formatting, and obsessing over details that most readers will never consciously notice, I finally have something I can hold in my hands. The paperback version of my SwiftUI Architecture book is now available, and seeing it in physical form feels very different from shipping a digital product.
You can learn more about the book and grab it here: https://azamsharp.school/swiftui-architecture-book.html
When you publish an eBook, you hit upload and move on. With a paperback, you slow down. You start thinking about things like how the text feels on the page, whether the code blocks are readable, how long someone can sit with the book without getting tired, and whether the whole thing actually looks like something worth studying. That process forced me to revisit the content multiple times, not because the ideas changed, but because the experience of consuming those ideas matters more in print.
This book was never meant to be something you skim on a weekend and forget. It was written to be studied, revisited, and applied over time. That is why having a physical version matters. You can sit with it, mark it up, flip back and forth between sections, and actually spend time thinking about the decisions you are making in your own apps.
The content itself stays true to what I have always believed about software development. Most apps do not fail because developers do not know enough patterns. They fail because developers try to apply too many patterns without understanding the tradeoffs. Somewhere along the way, we started equating complexity with quality, and that mindset creates fragile systems that are hard to maintain.
In this book, I focus on what actually holds up in real projects. I talk about structuring SwiftUI apps in a way that does not fall apart after a few features are added. I discuss how state should flow through your application without turning into a tangled mess. I also spend time on decisions that most tutorials completely ignore, like when not to abstract, when to duplicate code, and when to keep things simple even if it feels uncomfortable.
A big theme throughout the book is something I call pragmatic architecture. It is not about chasing the perfect design or preparing for every possible future scenario. It is about making decisions that solve today’s problems while keeping the door open for reasonable change later. There is a difference between being prepared and over-engineering, and most teams cross that line without realizing it.
Working on the paperback also made me appreciate how much presentation affects learning. I went through multiple iterations of font sizes, spacing, and layout until it felt right. The goal was not to make it look fancy, but to make it easy to read for long sessions. Code needed to be clear without overwhelming the page, and text needed to feel dense enough to deliver value without becoming exhausting. These details are subtle, but they make a big difference when you are actually sitting down to learn.
This book is not for someone who just installed Xcode last week. It is for developers who have already built a few apps and are starting to feel the pain of scaling those apps. If you have ever looked at your project and thought, “this worked at the beginning, but now it feels messy,” then this book will resonate with you.
You can learn more about the book and grab it here:
https://azamsharp.school/swiftui-architecture-book.html
The paperback version is available on Amazon, so you can choose whichever format works best for you. Some people prefer digital. Others want something they can keep on their desk and revisit.
This has been a long process, but it is one I am proud of.