One of the reasons I'm grateful for Swift and SwiftUI (and other similar frameworks) is that building UI without it is, frankly, untenable at the quality levels we have come to expect, especially as app complexity and surface area increases. It collapses in on itself. (1/16)

Think: multiplayer mode (Figma, GDocs), multiple device sizes, light and dark mode, complex accessibility functionality, etc.

There's just too much state to manage. You'll never get it right, much less hold the state tree in your head. (2/16)

This is especially true with large, or even medium development teams. Traditional UI construction is just too mushy and too easy to do wrong. Now add understanding how your teammates or other teams do it (or do it wrong) to this. (3/16)

This is compounded by the fact that building UI is also a totally under-appreciated skill – it's really hard to do right. You can tie yourself into a uni-directional mess of intertwined state real fast, without realizing it. (4/16)

Do you have 4+ years of iOS experience? Have you really learned a lot of about state modeling and management? Have you personally seen it fucked up and had to pay the price? You'll be fine. Maybe. (5/16)

Any less? Good luck!

Unless you've dedicated yourself to learning the nearly infinite minutia required to use the platform effectively, it's just really really easy to mess up, usually without realizing it. (6/16)

Sure it's easy to put a custom button on a screen; but how does it respond to accessibility? Light & dark mode? Different screen sizes?

Ok now do that with a list of items. Now make that list filterable. Now make it performant for that customer with 10k things. Etc. (7/16)

I've taken to calling this the "soundstage problem" – engineers build a UI that looks good and works good in exactly the configuration they developed it in, and nothing else – it falls apart and breaks in any other context. (8/16)

This is infuriating for customers – apps ends up feeling cheap and untrustworthy based on who built the UI and how much skill they had. UI is all the customer sees. If it sucks, they think the product sucks. Doesn't matter how good your backend & foundational eng work is. (9/16)

It also sucks for engineers – the feeling of trying to implement a basic feature, but you can't, because of soundstage UI is infuriating. You end up spending tons of time poking at it to get it to do what you want, usually increasing complexity in the process. (10/16)

Frameworks like SwiftUI, Jetpack Compose, etc, alleviate this entire problem set (ok, most of it). You have to write orders of magnitude less code to do complex things. The complex things are usually trivial to accomplish. It's great. (11/16)

You can iterate so so much faster due to tools like Xcode Previews – see your live, real UI in a bunch of permutations! Edit the code and watch them all update in real time! (12/16)

The age-old problem that every engineer has stumbled over of "animate updates to this set of content based on a diff" is gone (you weren't doing it right before, it probably crashed sometimes)! Just write the code to describe it and the system figures out the rest. Magic. (13/16)

Before, all this accidental complexity was spread around your tippy-top level UI code – impossible to consolidate, and had probably a collective 100 or 1000 bugs across your app. These declarative frameworks instead acknowledge this essential complexity and package it up. (14/16)

Before SwiftUI and Compose were announced, I was extremely nervous what UI development was going to look like in the future. It was so bogged down, so slow, so easy to mess up, that I was worried that iOS and Android development was going to slowly grind to a halt. (15/16)

From where we are today, I couldn't be more excited about the future of iOS and Android due to these two frameworks. They're instrumental in making UI higher quality, and making UI development fun! Fin. (16/16)