I'm noticing an accelerating trend of undocumented special behaviors w/ SwiftUI, like how Labels wrap differently at large dynamic type sizes inside a List. It means that if you do anything non-standard (e.g. use a UIView), you have no idea how many things you'll break. 1/

This has somewhat always been true. UIButton has a lot of subtle behaviors that make reproducing it by hand tricky, which is why checking button behaviors is a classic way to spot a non-native view. UITextView is overflowing with subtle behaviors and features. 2/

But SwiftUI raises it to a new level with behaviors that change based on accessibility settings, other views in the same container, screen size, and a huge pile of platform-specific behaviors that are briefly mentioned in videos, but not documented. 3/

It's not just that this creates a combinatorial explosion in your testing matrix. You don't even know what all the inputs to the testing matrix are. And since they're not documented, you won't know when Apple changes them. 4/

It reminds me a lot of JavaScript frameworks where I just have to know that passing a string here will do X and passing a buffer will do Y and passing an integer will do Z. And hopefully it's documented, but sometimes I just have to guess and see what happens. 5/

Most of the time with a JavaScript framework, I can go look at the code and see what it's doing, and work out what the code actually expects vs what "happens to work." And if a new version blows me up, I can just not upgrade. 6/

Like I said, this has always been challenge w/ Apple frameworks, and UIKit more than AppKit. (And while it's easy to break accessibility if you build anything custom, Apple documents accessibility, particularly VoiceOver, reasonably well.) 7/

But it feels that SwiftUI is putting its foot down on the accelerator of magical behaviors that are often delightful, but always a surprise.

And yet still…I'd rather write SwiftUI. The Heart wants what it wants. /fin