{"id":30183,"date":"2020-09-18T14:10:18","date_gmt":"2020-09-18T18:10:18","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=30183"},"modified":"2020-09-28T15:26:26","modified_gmt":"2020-09-28T19:26:26","slug":"the-state-of-swiftui","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2020\/09\/18\/the-state-of-swiftui\/","title":{"rendered":"The State of SwiftUI"},"content":{"rendered":"

Peter Steinberger<\/a> (tweet<\/a>, 2<\/a>, Hacker News<\/a>):<\/p>\n

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<\/a>, and it’s still fairly easy to make it crash on both macOS (FB8682269)<\/a> and iOS 14b8 (FB8682290)<\/a>.<\/p>

[…]<\/p>

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::Graph<\/code> in 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<\/a> lot<\/a> of<\/a> similar<\/a> problems<\/a>.<\/p>\n

[…]<\/p>\n

This isn’t unique to Fruta. I’ve been taking a look at @Dimillian’s<\/a> RedditOS app, which is built with SwiftUI on macOS. He stopped development<\/a> because it’s so slow that it’s not shippable.<\/p><\/blockquote>\n\n

This is sad because stability and speed are supposed to be the selling points of Swift.<\/p>\n\n

Frank Reiff<\/a>:<\/p>\n

\n

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.<\/p>\n

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.<\/p>\n<\/blockquote>\n\n

It will be really interesting to see what happens with companies like Omni Group<\/a> 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<\/a> 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.<\/p>\n\n

Nathan Lawrence<\/a>:<\/p>\n

I wouldn’t use Fruta as a model for SwiftUI, even though Apple does.<\/p>

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.<\/p>

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.<\/p>

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.<\/p><\/blockquote>\n\n

Roshan Choxi<\/a>:<\/p>\n

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.<\/p>\n

[…]<\/p>\n

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.<\/p><\/blockquote>\n\n

Steve Troughton-Smith<\/a>:<\/p>\n

\n

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<\/p>\n<\/blockquote>\n\n

Damien Petrilli<\/a>:<\/p>\n

\n

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.<\/p>\n<\/blockquote>\n\n

Samuel Coe<\/a>:<\/p>\n

\n

I can’t bring myself to release this horribly buggy experience to users (thanks SwiftUI).<\/p>\n

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.<\/p>\n

This is a big lesson learned for me.<\/p>\n<\/blockquote>\n\n

Previously:<\/p>\n