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)

I was thinking the same thing for web a few days ago,

I think the primary change here is unidirectional flow of data, a better understanding of immutable data structures and management, and improved framework support for autolayout. SwiftUI makes this the easy default, but we do all this in ObjC, just super hard to learn...

None of this disagrees with you, and being accessible makes things relevant and usable, so like, yeah I totally agree with you.

The language makes this a lot easier (I wouldn’t want to do a lot of this stuff in ObjC or Java). Eg so much of the design pattern is based around value types and enums; which are a pain without Swift or Kotlin.

*loud applause, shares it with my team* I love SwiftUI and Jetpack Compose and this is an amazing thread, but I really wanna get a shout out to Flutter - they invested years showing this model possible, enabling Apple and Android to be confident commiting to it

For sure - and I do think the cross-platform frameworks do have their place – but they’ll never be the fidelity of (or have the power of) the true first party platforms.

bravo sir

i get paid for these tweets right

What a great thread!

🙏🏼

Everything in this thread: 💯

100% agree. But you need to be able to break down into when its required. Eg in SwiftUI 1 its not possible to have a NavigationLink without arrow (unsure about now) without resorting to tricks. It needs to assume defaults but allow you to override them in a logical/consistent way

this is very powerful and true! exactly.

This!

You are touching on one of the fundamental insight for SwiftUI and other framework. I think Kyle does a wonderful job in explaining this in developer.apple.com/videos/play/ww… around minute 23. I think the expression of "Big-O" notation for you brain that is used really bring this home.

Ooh, I really like that way of putting it! Also: Too many Kyles

Duplication of state

cc @kylebshr

this happened in a biking slack group today as well, helpppp

Im wondering what your thoughts were on technologies that try to abstract that but on a platform basis like Xamarin Forms or Flutter? Even less to think about getting right to too much abstraction and not enough power?

I’m not a fan, simply because these platforms will always lag behind the first party platform frameworks from Apple and Google. It also makes your code (and job experience) less portable since you’re locked in. They definitely do have their place, though.

I think some of it boils down to what type of app and for whom you are making it. Full blown App Store apps would tend to support bleeding edge and full polish. Some business apps, no so much polish and features. Im being polite :-)

If your level of hatred for your users is over a certain threshold, the benefits are undeniable

yes yes yes this whole thread

I think you are overselling it. It’s amazing, but people have been using the same principles for managing complexity that SwiftUI does for years now. Which is a great, it feels like a natural evolution of technology.

The abstraction, though, of semantic UI components that automatically update in response to system environment changes (dark mode, RTL, dynamic text) cannot be overstated. Not having to do that plumbing yourself for any of your state changes is liberating.

Yeah – exactly this!

I agree, I absolutely love using it because it perfectly matches the way I prefer to solve these problems: UI in code, reactive data-driven UI, highly composable, etc.

People have, absolutely, but now the platform does. Now there’s a consistent standard to the way that complexity gets culled that (even when it’s not ideal) is something we can begin to coalesce around over time.

All hail command line applications, where the closest to UI design is writing the man page and the ascii art to wrap around the returned data

your thesis seems to imply that UI design has never been done at this scale / quality. but desktop apps, often at higher quality than seen today, have been around for 35 years. machines differ wildly... and windows, color depths, and multi-display too.

i agree that declarative UI is awesome and async stateless code is super too. but to say that the problem we face in UI design today is unique seems, at least to me, a bit myopic -- as if app design started in 2008.

Definitely – though I think a major difference and breaking point is just how stateful and rich UI has become – animations based on diffs, interactive and reversible animations, physics, etc. Look back farther than 10-15 years ago, and this was pretty rare. Now it’s table stakes.

This. I don’t think the complexity introduced by animation (and esp their async completion handlers) is fully appreciated.

It is overrated rather. Complexity in animation can be bounded by screen size and duration. No one needs multi-day animation of 100-page-long document. Not so for complexity of desktop apps. It's compounded by many factors.

This is incorrect. Desktop apps for business are more stateful than modern consumer mobile apps. Also most commercial grid components beat any single mobile app.

Animations are peanuts. * tolerate imperfections and outright errors * short lifetime limits complexity

(No comment)

You should highlight that SwiftUI allows you to stay in the native iOS world, whereas 3rd party frameworks like React or Flutter have a track record of pushing teams to MORE 3rd party tools, away from the important privacy, accessibility and performance attention that iOS offers.

Agree, and even that is not enough. Hence why we have Redux, BLoC and other state management approaches

This sounds a *lot* like the benefits of React, for web UIs, which checks out, since as far as I can tell, SwiftUI was heavily inspired by React.