The State of SwiftUI
Peter Steinberger (tweet, 2, Hacker News):
Since then, there have been many betas, and we’re nearing the end of the cycle, with the [Big Sur] GM expected in October. So it’s time to look at Fruta again. And indeed, the SwiftUI team did a great job fixing the various issues: The toolbar is pretty reliable, the sidebar no longer jumps out, multiple windows works… however, views are still sometimes misaligned, and it’s still fairly easy to make it crash on both macOS (FB8682269) and iOS 14b8 (FB8682290).
[…]
Most SwiftUI crashes are a result of either a diffing issue in AttributeGraph, or a bug with one of the bindings to the platform controls (AppKit or UIKit). Whenever you see
AG::Graphin the stack trace, that’s SwiftUI’s AttributeGraph (written in C++), which takes over representing the view hierarchy and diffing. […] Googling for this error reveals that there are a lot of similar problems.[…]
This isn’t unique to Fruta. I’ve been taking a look at @Dimillian’s RedditOS app, which is built with SwiftUI on macOS. He stopped development because it’s so slow that it’s not shippable.
This is sad because stability and speed are supposed to be the selling points of Swift.
On the Mac, Swift UI is so far away from being practical that Apple might well have moved on to the next technology before it is.
Mac apps need to be backwards compatible for at least 5 years, so if Swift UI is ready in 2022, it can’t be used until 2027.
It will be really interesting to see what happens with companies like Omni Group who try to go all-in on SwiftUI. On the Mac side, it just doesn’t make sense to me at this point, both because of the limitations with first responder and more advanced controls and because of the potential bugs and performance issues. Making the easy stuff even easier doesn’t seem worth possibly painting yourself into a corner. Also, roughly 1/3 of my customers can’t run SwiftUI apps at all.
I wouldn’t use Fruta as a model for SwiftUI, even though Apple does.
It’s not well structured, it has huge bugs, cruft from different approaches to certain problems that got abandoned months ago…it’s not an illustration of the framework or its inner mechanics at their best.
I think what you learn when you build with SwiftUI at any kind of magnitude is that you’re a little on your own. Many approaches that experts or instructors (including at friggin Stanford University!) offer are just plain nonfunctional or inefficient.
This is not because SwiftUI is broken — there are some decisions I disagree with, sure, and often those decisions can be a big enough problem the require some workarounds or extra coding of your own - but because it’s poorly documented and explained. It is evolving so fast.
For frontend designers and developers trying to deal with building UI that runs across dozens of devices, the goal of “write once, run anywhere” has been the panacea of UI development. If anyone had the motivation, talent, and platform control to achieve this goal it would be Apple. And I believe they have been largely successful with SwiftUI.
[…]
As great as SwiftUI does at universal UI code, it demonstrates that there is still a large amount of code that needs to be specific to the device because of the spectrum of different sizes, inputs, accessories, and hardware performance of different devices.
As a situational tool, SwiftUI is awesome. There’s no way I’d trust it to build an app directly, it’s nowhere near reliable enough for that, but it’s great for providing the content views for your UIKit view controllers and reducing so much manual layout code or storyboard work
My favorite SwiftUI bugs: when it crashes internally without knowing which line of code is involved so you have to troubleshoot, line by line, without any clue.
I can’t bring myself to release this horribly buggy experience to users (thanks SwiftUI).
My faith that Apple fixes this is low and I’m feeling really let down that these keyboard-avoidance issues weren’t fixed in Beta.
This is a big lesson learned for me.
Previously:
Update (2020-09-28): Michael Buckley:
I feel pretty bad about all the time I spent trying to make SwiftUI work at Panic. The idea behind it is great, the actual design has some issues, but the implementation has been a nightmare to work with compared to AppKit or UIKit.
My determination last year was that SwiftUI was a fantastic tool if used as a replacement for Interface Builder; spending a lot more time with it this year I think that’s just as true today. Takes about the same amount of time to lay out a UI, but SwiftUI leaves you with code
Code is great because you can refactor it. Localize it. Switch container types by renaming them. Copy/paste properties between views. Extract previously-static metrics to properties and tweak them dynamically layout-wide. Use ifs and ifdefs for conditional views & layout
Even if you’re wrapping UIKit (/AppKit), and don’t trust SwiftUI for actual app logic (I definitely don’t), I feel like moving from nibs & storyboards to SwiftUI should be high on your priority list. I’m genuinely surprised there isn’t a SwiftUI replacement for launch storyboards
Previously:
2 Comments RSS · Twitter
> This is sad because stability and speed are supposed to be the selling points of Swift.
Good one! :-O
In terms of speed, it has definitely, conclusively and at this point almost certainly irredeemably failed.
And stability doesn't really seem to be all that great either.
> “write once, run anywhere” has been the panacea of UI development. If anyone had the motivation, talent, and platform control to achieve this goal it would be Apple.
Except that this is explicitly a non goal for SwiftUI. SwiftUI paradigm is learn once, write everywhere. You still have to write UI for each platform.
