21–30 of 216 posts
I've written architecture astronaut code of my own, so I saw this coming. Swift the language, and SwiftUI the gui toolkit, have a classic over-engineered magnum opus style to them. The generality and generic-ness just leak out all over the place. I also saw a bit of this early on in Dart and Flutter. From what I can tell they seem to have charted a better course and avoided getting stuck too deeply in their own perfe…
$0.02 on this is that I see a great many people doing the typical “all or nothing” with SwiftUI. I think this is a mistake. Like every single other engineering tool in existence, this one has costs and benefits. For the people saying it doesn’t work: use UIKit for those pieces. Otherwise, use it where it makes sense, and no more. I see this in Compose in Android too - lots of devs doing wholesale refactoring to repla…
To be fair, though, I feel like the difference between SwiftUI and UIKit or XIB is much bigger than the difference between UIKit and XIB. I don't have much practice with SwiftUI since I have to support some older iOS devices, but how awkward is it to do navigation between screens implementing with SwiftUI Views and those using UIViewController and friends? How does UINavigationController work into all of that?
Things were easier when it was just Objective-C and UIKit / AppKit. Swift killed my joy of making iOS apps.
Earlier quoted context omitted.
To be fair, though, I feel like the difference between SwiftUI and UIKit or XIB is much bigger than the difference between UIKit and XIB. I don't have much practice with SwiftUI since I have to support some older iOS devices, but how awkward is it to do navigation between screens implementing with SwiftUI Views and those using UIViewController and friends? How does UINavigationController work into all of that?
XIB? xib files are used in UIKit apps, alongside storyboards, but they're simply serialized views, not a different architecture or paradigm.
I'm sure SwiftUI is UIKit underneath, too, for what it's worth.
...no comparison with Flutter or at least remarks of what would also apply to it?
Earlier quoted context omitted.
To be fair, though, I feel like the difference between SwiftUI and UIKit or XIB is much bigger than the difference between UIKit and XIB. I don't have much practice with SwiftUI since I have to support some older iOS devices, but how awkward is it to do navigation between screens implementing with SwiftUI Views and those using UIViewController and friends? How does UINavigationController work into all of that?
If you use SwiftUI at all, the app has to start with the SwiftUI lifecycle (Edit: May not be true, see replies). But then you can wrap any UIView or UIViewController in a SwiftUI wrapper (UIViewRepresentable and UIViewControllerRepresentable). So that view/controller will be presented by SwiftUI's navigation logic, but inside that view/controller, you can write a whole UIKit app if you want.
I think that adds to my point that SwiftUI isn't something that's very amenable to "just use it where it's appropriate", or "gradually try it out by migrating a small part of your project", etc. It sounds like you have to commit to "this is a SwiftUI app now, and we can integrate with old stuff if/where/when we need to".
Things were easier when it was just Objective-C and UIKit / AppKit. Swift killed my joy of making iOS apps.
I looked a bit of the posts on Twitter, and wow, it’s really polarized. People seem to either love it or hate it. Is SwiftUI still that controversial, or is it just an effect of people posting on Twitter?
It makes some tasks much much easier, e.g. low vision users really benefit from variable font sizes, which Storyboards can do but it feels unnecessarily hard to do in a non-fragile way.
I can also see the benefits of reactive UI over the Storyboard approach, especially with UICollectionView and UITableView.
But…
The code examples, even from WWDC slides and Apple docs, don’t even always compile; the widgets are different enough it’s not always clear how to get to the desired UI when you’re starting from UIKit, and the integration between UIKit and SwiftUI (in both directions) isn’t as easy as I’d like, and you have to keep resuming the canvas view because it’s not smart enough to figure out for itself when the code now represents a valid view.
Earlier quoted context omitted.
To be fair, though, I feel like the difference between SwiftUI and UIKit or XIB is much bigger than the difference between UIKit and XIB. I don't have much practice with SwiftUI since I have to support some older iOS devices, but how awkward is it to do navigation between screens implementing with SwiftUI Views and those using UIViewController and friends? How does UINavigationController work into all of that?
If you use SwiftUI at all, the app has to start with the SwiftUI lifecycle (Edit: May not be true, see replies). But then you can wrap any UIView or UIViewController in a SwiftUI wrapper (UIViewRepresentable and UIViewControllerRepresentable). So that view/controller will be presented by SwiftUI's navigation logic, but inside that view/controller, you can write a whole UIKit app if you want.
In fact, you can jump back and forth between UIKit and SwiftUI as many times as you like throughout your app's view hierarchy.
The current project I'm working on involves slowly porting an older UIKit+Storyboard app over to SwiftUI, so I'm seeing this in practice every day.
I looked a bit of the posts on Twitter, and wow, it’s really polarized. People seem to either love it or hate it. Is SwiftUI still that controversial, or is it just an effect of people posting on Twitter?
My advise is to try it, and learn along the way. After a while the idea of going back to UIKit will become scary.