SwiftUI Fundamentals
This book distills the core principles and foundational concepts behind SwiftUI, the modern UI framework for building apps across Apple platforms. My goal is to help you go beyond surface-level understanding and develop a deep, practical knowledge of how SwiftUI works under the hood.
SwiftUI provides a simple, declarative way to build user interfaces, but behind that simplicity is a carefully designed architecture that can be tricky to grasp without the right perspective. In this book, we’ll explore the key APIs and design patterns that power SwiftUI, giving you a solid foundation to write more efficient, maintainable, and expressive code.
I’ve been working with SwiftUI since it was first released and later had the privilege of contributing to its development as a member of the core SwiftUI team at Apple, where I helped design and build some of the framework’s most widely used APIs. I wrote this book to share the insights I gained during that time, insights that will help you better understand how SwiftUI is built and how you can use it more effectively in your own projects.
Previously:
- SwiftUWhy
- SwiftUI at WWDC24
- The SwiftUI Field Guide
- Thinking in SwiftUI (2023)
- macOS Apprentice
- Integrate SwiftUI Into a UIKit App
5 Comments RSS · Twitter · Mastodon
I don’t remember it was needed to know how AppKit is working from the inside to use it well.
While it can be technically interesting to know how an API works under the hood, if you need to know it instead of just having a look at the documentation and basic examples, there’s quite an issue with the API itself.
@some The issue with any reactive UI framework, let alone a buggy mess like SwiftUI, is you have to have intimate knowledge with the underlying implementation, in order to be able to achieve tasks that are normally not possible or very hard in such a system. There are a class of problems that are almost impossible to solve efficiently in a reactive UI system, such as an endless scrolling gallery of images (or an endless chat with bubbles, etc.). You need to know the underlying impl in order to be able to hack your solution around it.
I tried to adopt SwiftUI back in 2018 at version 1.0. Helped several on GitHub even.
Then I gave up. Too much, too fast. Apple already improved on AppKit with UIKit, already improved on Obj-C (kind of) with Swift by getting rid of header files, actually unified IB with Xcode....
And that was ENOUGH! I get that I'm "old school". (Ever hear of COBOL-74?) Still, what gives? If I need AI to help me with coding, I quit. (Vibe coding? Seriously people, learn *why* then do it.) SwiftUI is the *Apple* way of doing reactive -- also called UI coding back in the day -- code. It's in the name!
APIs. Open. Public. I'll still use UIKit because CoreImage is Apple only. And while Apple deprecated GLKit -- you know OpenGL -- years ago, Metal (which is quite good for Apple devices) has its issues and LOCK IN. Going with SwiftUI is lock-in like this.
All I'm gonna say is that I built this thing 7-8 years ago in Objective-C, and it still compiles without any issue today.
I've read Natalia's book "Integrating SwiftUI into UIKit", and thought it was quite good. I'm also currently re-reading Daniel Steinberg's "A SwiftUI Kickstart" book as he recently updated it with the latest Xcode 16 and API changes. Daniel has always been my go to source when I need to learn something. He's a great educator, presenter and wonderful human being. In fact, when Apple introduced Storyboards, I didn't get it, until I saw Daniel's presentation on them at a CocoaConf years back and the light bulb turned on for me and I got it. He did a better job presenting them than Apple!
But with his SwiftUI book, the light bulb didn't turn on for me the first read. Now reading it a second time, not only is it still not coming on, but I'm very much convinced this is the wrong approach.
I get the same feeling with all these SwiftUI books where's there this overt used car salesman pitch for the framework. "Look, see how little code you have to write to make this UI? Isn't it great!"
And then I look at the code and its this hodgepodge of nested VStacks and HStacks with views embedded in them, each one of them having this waterfall of view modifiers hanging off the side. And I sit there and think, well yeah, but I could have built this very UI, and have built more complicated UIs, a decade prior writing Zero lines of code using Interface Builder.
I didn't have to wait for this very buggy and janky "Live Preview" to load up, that I feel like is always showing me the stethoscope icon to report a bug to Apple when all I did was modify a comment. In Interface Builder I can change a font of a label from the inspector and see the new font appear instantly, as opposed to SwiftUI where I have to write that code, then I'm waiting for the spinner to show me the changed font.
Yes, you can Option-Control-Click to bring up the SwiftUI Inspector, which I've found to be very unreliable and frustrating when it applies the view modifier in the wrong spot. Because the ordering of these modifiers affects the end result and matters. There's been times where it appended the modifier in the wrong spot and I got a build failure. Its absurd.
This weekend I was banging my head on an issue where I wanted to do some custom drawing when a Text view was rendered. After searching through the poorly documented documentation, I discovered a struct entitled "Text.Layout" that appeared to have exactly what I needed to do what I want. But how do I use it? The engineers apparently couldn't bother to take 2 minutes to add a DocC "See Also" statement which should have pointed me to TextRenderer.
TextRenderer ultimately did exactly what I needed, but apparently this API was just recently introduced in iOS 18!? Ok, so here's this "modern framework" that after 6 years or so finally gained the capability to do what you could have done on Day 1 with UIKit and reference types.
Hopefully someone here can drop a few links to some GitHub open source projects that would best represent the quintessential example of great SwiftUI code that I can study from. Because I've still not found it.
