4 ms·

There are definitely a few things it does that are weird, and this article hits on a few of them. But, I'll call special attention to the whole "adaptive paddi

by 013a 7y ago

There are definitely a few things it does that are weird, and this article hits on a few of them. 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. 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? All of these are getting better, but they only get better because the underlying technologies are becoming more generic. > If I forgot to put padding between HStack elements, well, shame on me, there should be no padding! All mistakes are mine. 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. 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. 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).

diffeomorphism 7y ago
Haven't we been going in the other direction in recent years? With integrated title bars in browsers, custom css, fonts etc.. Chrome on Windows, Mac, Linux etc. always looks like chrome but not native. Similarly webpages look "exactly like the designer intended" even if it is a very bad fit for your device. We used to do things generically, but changed to prescribing every little detail and this now breaks when our assumptions change.
- danudey 7y ago
  Case in point: WhatsApp TestFlight betas recently gained support for dark mode, because they decided to do custom UI (and, honestly, not a terrible one) and it took ages for them to fix it up to support dark mode. Meanwhile, many native-iOS developers had dark mode support on day one, because they stuck closer to iOS conventions and didn't do as much custom UI.
  - eugeniub 7y ago
    Frankly I don't know what in the world you're talking about. WhatsApp is one of the best examples of a native iOS UI implementation. Looking at the app now, it clearly uses very lightly customized native UITabBarController, UINavigationController, UINavigationBarItem, UITableView, etc. The only examples of custom-built UI elements in WhatsApp only come from stuff like the camera view and the messages view. These are areas where Apple doesn't really provide ready-made UI classes in the first place.
- 013a 7y ago
  We did use to do things generically, but more-or-less the wrong kind of generic. Android is a great example of this. I don't know how things are done now, but for its first few years, they had screen size classifiers; ldpi (low dpi), mdpi, hdpi, etc. Of course, devices got better. That set grew to ldpi, mdpi, hdpi, xhdpi, xxhpdi, and xxxhdpi. There's also tvdpi for televisions. It was supposed to be generic. It became a mess, because they were operating at the wrong level of abstraction. But whats more; in the beginning, the `dpi` of a device was actually a consistent way to determine the screen size! I saw many apps in the day rely on this; they'd change the text sizes and paddings and even high level UI organization upon render by conditionally checking the dpi of the device. Its generic, right? Its not like I'm saying "if screen width is above 750px, render X" (cough css). I know less about android as we approach closer to today, but I'm familiar with another problem they had concerning foldables. Android apps were never designed, from the start, to be able to respond to changes in screen size! So that required some new frameworks to be put in place, and old apps had to update. Point being; our UIs have gotten more complex, because the problems they're solving have gotten more complex. We had HTML; a truly pure form of "generic UI design". But, it was designed for documents, not applications, so we built CSS and JS and wrote ourselves into the mess we're in today. Android had some ideas around generic UIs, but they too did not predict what people would actually be using their platform for and where technology was going. SwiftUI is another stab at this, and maybe they'll get it right. I don't know. But, I think technology is settling a bit, and with that settling comes a greater understanding of what UI designers need from their frameworks.
SlowRobotAhead 7y ago
The point isn’t that adaptative spacing does a good job most of the time, it’s that it’s doing things it isn’t telling you about in code and you “just need to know” for when it isn’t doing a good job. Think about having to remember UI padding voodoo the couple days after you back from a vacation. The UIkit shouldn’t try and hide language normal commas, it shouldn’t try and imply “smart” or “magic” padding.
- jamil7 7y ago
  You're right but it's a tradeoff I guess. It seems like they want to optimise for developers building half decent looking apps with adaptive UIs across their platforms with less effort.
- 013a 7y ago
  Similarly, We've all seen incomprehensible ten-thousand line CSS styles sheets, with layers of inheritance, where you're forced to grep through to find that one line on some ancestral class that controls the left padding for every h1 on the site... except this specific one, which I guess is using !important on its own class? Damn it. So, what'll it be? We're talking about inherent complexity. Should it be application specific? Or should the platform take a stance on the Right Way? If we have a rule that holds in 95% of cases, embedding that rule into the platform itself does make sense, as long as you can escape hatch out in those 5% of cases it doesn't hold. It reduces the complexity developers have to hold in their head. Its no longer "Oh, yeah, I need padding on that, how much? 4 pixels I guess. Is that standard? Wait, no, i think we moved to 8px recently. Or, wait did we move this to 'em'?". Its just "I need padding. I'm adding padding. On to the next thing." Your company isn't special. The problems we're each solving are more alike each other than not. Embrace the magic. Learn it. It'll make your life easier, and your software better.
  - SlowRobotAhead 7y ago
    >"Oh, yeah, I need padding on that, how much? 4 pixels I guess. Is that standard? Wait, no, i think we moved to 8px recently. Or, wait did we move this to 'em'?" I'm not sure how the magic/JustUsuallyWorks/ solution fixes this issue. If the argument is people need to remember things, and SwiftUI takes that away and just puts in what an algorithm thinks is right, that's probably going to be pretty generic design for the final product.
rootlocus 7y ago
> 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. Poor Apple. Poor customers. They are all entitled to perfectly 'designed' UIs which consistently showcase the majestic and breathtaking visual design of the Apple ecosystem. With they shadows, and the smooth animations, and the perfectly balanced padding. If only they could control what you see and what you can do with your Apple devices. Oh wait. They do. And now we have to fight for the right to repair. And we have to fight for the definition of 'ownership'. And we have to fight against monopolies. The argument that anything not controlled by Apple would hurt the optics of the ecosystem and damage Apple's brand / reputation / value has been used to diminish our rights in every possible way. But we have pretty UIs!

by 013a 7y ago

diffeomorphism 7y ago

Haven't we been going in the other direction in recent years? With integrated title bars in browsers, custom css, fonts etc.. Chrome on Windows, Mac, Linux etc. always looks like chrome but not native. Similarly webpages look "exactly like the designer intended" even if it is a very bad fit for your device. We used to do things generically, but changed to prescribing every little detail and this now breaks when our assumptions change.

danudey 7y ago
Case in point: WhatsApp TestFlight betas recently gained support for dark mode, because they decided to do custom UI (and, honestly, not a terrible one) and it took ages for them to fix it up to support dark mode. Meanwhile, many native-iOS developers had dark mode support on day one, because they stuck closer to iOS conventions and didn't do as much custom UI.
- eugeniub 7y ago
  Frankly I don't know what in the world you're talking about. WhatsApp is one of the best examples of a native iOS UI implementation. Looking at the app now, it clearly uses very lightly customized native UITabBarController, UINavigationController, UINavigationBarItem, UITableView, etc. The only examples of custom-built UI elements in WhatsApp only come from stuff like the camera view and the messages view. These are areas where Apple doesn't really provide ready-made UI classes in the first place.
013a 7y ago
We did use to do things generically, but more-or-less the wrong kind of generic. Android is a great example of this. I don't know how things are done now, but for its first few years, they had screen size classifiers; ldpi (low dpi), mdpi, hdpi, etc. Of course, devices got better. That set grew to ldpi, mdpi, hdpi, xhdpi, xxhpdi, and xxxhdpi. There's also tvdpi for televisions. It was supposed to be generic. It became a mess, because they were operating at the wrong level of abstraction. But whats more; in the beginning, the `dpi` of a device was actually a consistent way to determine the screen size! I saw many apps in the day rely on this; they'd change the text sizes and paddings and even high level UI organization upon render by conditionally checking the dpi of the device. Its generic, right? Its not like I'm saying "if screen width is above 750px, render X" (cough css). I know less about android as we approach closer to today, but I'm familiar with another problem they had concerning foldables. Android apps were never designed, from the start, to be able to respond to changes in screen size! So that required some new frameworks to be put in place, and old apps had to update. Point being; our UIs have gotten more complex, because the problems they're solving have gotten more complex. We had HTML; a truly pure form of "generic UI design". But, it was designed for documents, not applications, so we built CSS and JS and wrote ourselves into the mess we're in today. Android had some ideas around generic UIs, but they too did not predict what people would actually be using their platform for and where technology was going. SwiftUI is another stab at this, and maybe they'll get it right. I don't know. But, I think technology is settling a bit, and with that settling comes a greater understanding of what UI designers need from their frameworks.

SlowRobotAhead 7y ago

The point isn’t that adaptative spacing does a good job most of the time, it’s that it’s doing things it isn’t telling you about in code and you “just need to know” for when it isn’t doing a good job. Think about having to remember UI padding voodoo the couple days after you back from a vacation. The UIkit shouldn’t try and hide language normal commas, it shouldn’t try and imply “smart” or “magic” padding.

jamil7 7y ago
You're right but it's a tradeoff I guess. It seems like they want to optimise for developers building half decent looking apps with adaptive UIs across their platforms with less effort.
013a 7y ago
Similarly, We've all seen incomprehensible ten-thousand line CSS styles sheets, with layers of inheritance, where you're forced to grep through to find that one line on some ancestral class that controls the left padding for every h1 on the site... except this specific one, which I guess is using !important on its own class? Damn it. So, what'll it be? We're talking about inherent complexity. Should it be application specific? Or should the platform take a stance on the Right Way? If we have a rule that holds in 95% of cases, embedding that rule into the platform itself does make sense, as long as you can escape hatch out in those 5% of cases it doesn't hold. It reduces the complexity developers have to hold in their head. Its no longer "Oh, yeah, I need padding on that, how much? 4 pixels I guess. Is that standard? Wait, no, i think we moved to 8px recently. Or, wait did we move this to 'em'?". Its just "I need padding. I'm adding padding. On to the next thing." Your company isn't special. The problems we're each solving are more alike each other than not. Embrace the magic. Learn it. It'll make your life easier, and your software better.
- SlowRobotAhead 7y ago
  >"Oh, yeah, I need padding on that, how much? 4 pixels I guess. Is that standard? Wait, no, i think we moved to 8px recently. Or, wait did we move this to 'em'?" I'm not sure how the magic/JustUsuallyWorks/ solution fixes this issue. If the argument is people need to remember things, and SwiftUI takes that away and just puts in what an algorithm thinks is right, that's probably going to be pretty generic design for the final product.

rootlocus 7y ago

> 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. Poor Apple. Poor customers. They are all entitled to perfectly 'designed' UIs which consistently showcase the majestic and breathtaking visual design of the Apple ecosystem. With they shadows, and the smooth animations, and the perfectly balanced padding. If only they could control what you see and what you can do with your Apple devices. Oh wait. They do. And now we have to fight for the right to repair. And we have to fight for the definition of 'ownership'. And we have to fight against monopolies. The argument that anything not controlled by Apple would hurt the optics of the ecosystem and damage Apple's brand / reputation / value has been used to diminish our rights in every possible way. But we have pretty UIs!