There are definitely a few things it does that are weird, and this article hits on a few of them.<p>But, I'll call special attention to the whole "adaptive padding thing" as a broader signal for something I feel that SwiftUI does very, very right and more UI frameworks need to start thinking about. Its made to design iOS apps. iOS has a design language that (1) is relatively consistent, (2) changes over time, and (3) changes across the many devices Apple supports.<p>In this era of many, many devices (don't just think Apple here; think any device; think VR, think TVs, etc), we need to operate at a higher layer of abstraction than most UI systems operate at. Most websites are pure garbage on 35" ultra-ultra-wide displays. It took a decade before mobile web entered the "generally useable" state it is in today. Ever tried to enable an ultra-high DPI setting on, say, Ubuntu or Windows?<p>All of these are getting better, but they only get better because the underlying technologies are becoming more generic.<p>> If I forgot to put padding between HStack elements, well, shame on me, there should be no padding! All mistakes are mine.<p>Wrong, and Apple has the data to prove it. When you release a poorly designed app to the App Store, the mistake is your's; your customers suffer because of it; and, it hurts the optics of application quality on the App Store, and thus Apple suffers.<p>This is relatively easy to draw a comparison to, say, manual memory management in C++. "If I forgot to properly bounds check a memory segment, well, shame on me, there should be no bounds checking! All mistakes are mine". Sure; and now your customers are vulnerable to hackers. You have a higher responsibility than just your Pride.<p>The defaults should be Safe. There should be options to override them when I feel confident I know what I'm doing (and SwiftUI has this, not the least of which being, you don't have to use SwiftUI, you can mix-and-match SwiftUI components with traditional iOS components).