How long does it take to become a true SwiftUI master?

How far am I on my own way to mastery? 🤔

Let’s quantify and have a wild guess!

Point of Reference: Text Kit

I start this introspective journey by looking at another topic I feel like I could become quite the expert, even though I am painfully aware of how much I still don’t know – Text Kit.

When I query my Zettelkasten for all things Text Kit, i.e. nstextview OR nslayoutmanager OR nstextstorage OR nstext OR nsglyph OR textkit, I get 169 notes.

For the #nstextview tag alone I get 65 unique notes.

My first research notes are from 2015, so all in all, this written record is the effort of 7 years of work. And then there are blog posts, Open Source repos, and apps I use this to top things off.

Was it hard to start using Text Kit?

Not at all!

I was able to use NSTextView, the AppKit view component, from day one. (From within a Xib, mind you. Programmatic setup took longer.) It displayed text nicely, I could make the font larger, observe content changes and save changes to disk. No problem, although the Cocoa text system was arguably the most complex AppKit component I encountered by that time. Core Data is also a huge topic, but in a different way.

Summarized, Text Kit and NSTextView require research to customize the layout, to figure out syntax highlighting, to compare approaches, to implement typewriter scrolling and auto-pairing of brackets etc.

In other words: The additional research was all about deepening my knowledge of Text Kit so I could do cool stuff with text.

Looking at My SwiftUI Research the Same Way

Now for a comparison, when I query my Zettelkasten for all things SwiftUI, it gets a bit trickier to come up with fitting tags/search terms.

For example, #swiftui alone nets me 65 notes (the exact same number for #nstextview, turns out).

Unlike the various Text Kit components, SwiftUI views aren’t prefixed with “NS” or anything else, so searching for SwiftUI’s Text view isn’t very helpful. “Text” is too generic a search term. Some concepts are exclusive to SwiftUI, though, like @AppStorage and @EnvironmentObject, so I can mix these in. But it’s harder to figure out if the search produces fitting results.

When I navigate my web of notes to get through the SwiftUI department, I rely on entry-points like topic overviews and links. The search for the #swiftui tag is the best direct proxy I have at the moment. Mixed with a couple other terms, swiftui OR environmentobject OR appstorage OR (navigation AND 2022 AND NOT web), I get 72 unique notes. So that’s the number I’ll be using here.

Some of these 72 notes stem from 2020, just to keep a track of the new tech. 20 were written in July 2021, when I worked on a toy project to learn the basics and got frustrated over and over again, so that didn’t work out well. 40 were written in May and June 2022, when I worked on a SwiftUI client project and solved real problems.

None of these notes are about obscure details.

Comparing My Text Kit and SwiftUI Departments in My Zettelkasten: Why Are the SwiftUI Notes So Boring?

A lot of my Text Kit notes cover the interplay of components, efficient glyph generation, making drawing performant, and other tricky subjects. They cover OS bugs that other people uncovered, work-arounds to implement custom behavior.

None of my SwiftUI notes are about anything truly interesting. They all are about basic behavior, and the odd animation here and there.

I think that’s because:

1. SwiftUI isn’t my first UI framework: I need to adapt, to assimilate and accommodate the new ideas;

2. SwiftUI’s documentation was not very discoverable. It got better, but I also feel more accustomed to it with use (Stockholm Syndrome anyone?);

3. Auto-completion in Xcode is all but useless with SwiftUI, because most view modifiers are available on everything, so you don’t see what’s special about a view easily.

Note-Making Got Me This Far at Least

I’m very glad I do have this well-fed Zettelkasten at my disposal for the journey.

I was able to track questions, open loops, and also very isolated, ‘atomic’ findings, like how to create “Horizontally sliding sub-view replacements with SwiftUI”, or “Force light status bar in SwiftUI”. These are barely more than code snippets. The basics are so different from my AppKit muscle memory that I do need to remind myself to truly Think Different&tm; here.

But I also have conceptual notes like ”@EnvironmentObject is a branched global variable” (coined by Dominik Hauser), and almost 1000 words worth of “SwiftUI navigation via view replacements and lightweight Router” that introduces a simple routing concept to get from A to B within an iOS app.

I have no clue how others figure anything like this out, except maybe by total immersion (not just the swim technique).

To change the way you think requires effort. For the client project in early 2022, I also made a lot of progress in getting used to the SwiftUI way when I spent a full-time job’s amount of work tinkering with the framework, then watched videos that demonstrate SwiftUI stuff in my lunch break and whenever possible in between, and read through blog posts again and again until I noticed I could connect the dots better.

It is impossible to say if SwiftUI is harder than learning Objective-C and AppKit in 2010.

It is harder for me now to think in terms of SwiftUI, I believe (!), because I have spent 10 years making apps in a different way.

Either way, maaaaan, SwiftUI is a tough nut to crack if you want to understand anything. Or understand anything. I don’t even know which to emphasize.

I can sympathize with fellow developers who wish for retirement before SwiftUI becomes mandatory because SwiftUI is not just a slightly different object-oriented framework to build UIs. It’s using different paradigms everywhere, and even drives the Swift language evolution in some places.

Connecting the dots, for me, meant to capture any dots first. Collect definitions from the docs and interpretations from blogs, then capture the components’ relationship and functionality, then explore examples and applications all around the web to see how people actually use things.

I felt so dumb trying to grasp the first couple of blog posts that I had to treat this like a whole new language: starting from first principles, how does anything work? Start with layout view builders. No, start with view builders. Include Swift 5.5 features to build DSL. Try to build a DSL. Try to learn to truly see the new patterns in SwiftUI code to separate the unknown machinations from things I can sort into buckets, mentally.

To feel dumb is not a pleasant state.

In 2021, I aborted the toy project journey because the cross-platform iPad + Mac app got hard to maintain with the mindset of just hacking around. But none of the problem solving patterns I was trained to use to get through structural problems applied. I could feel the gears in my head grinding to a halt; I felt absolutely clueless, because I didn’t see a way to bring what I knew into this new world. Pieces in the middle were missing. I longed to use approaches I knew just to erase some of the uncertainty, and to stop some of the ever moving pieces from moving further, like app state management.

Oof.

Ok, now how far am I on my way to SwiftUI mastery?

After the iOS client project we completed, I feel somewhat competent in basic layout tasks and scene transitions.

Also, writing animation code is quite fun!

Judging from the sheer volume of written knowledge I built up, seemingly from scratch, that barely covers basics like “.padding before .border is inset, .padding after .border becomes margin”, there’s a long way to go.

What comforts me is the cross-pollination of the SwiftUI department in my Zettelkasten with other departments, like the ‘unidirectional flow’ department, or the ‘functional programming’ department, or the ‘declarative programming’ department, which eventually all comes back to programming paradigm comparisons, mental models, and ways to think and problem-solve. Eventually.

I’ve seen a couple of ebooks teaching you how to make UIs, but not that many texts have been written about whether this changes you software architecture, and which (architectural) patterns fit, apart from maybe The Composable Architecture.

That indicates there’s still a lot to discover – so while my road to mastery is, err, still going a long ways into the distance, I’m not that far behind the bulk of developers, I guess. Once I absorbed all the shared knowledge, I shoild be almost equally as competent as the lot :)

But honestly: I’m confident I can get into a semi-productive mess, but I don’t know the ways out, yet. It’s different for a lot of AppKit scenarios in which I’ve already been a couple of times. So there’s a long way to go for both SwiftUI to suck less, and me to, well, suck less, too.