6 ms·

$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

$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 replace components. Bad move. SwiftUI is powerful and offers a new way of defining the interface that is focused on the expressiveness it offers to devs. UIKit is just a modified version of that trade off : it offers less expressiveness for more power and sometimes correctness. Mix your poisons, don’t pick them.

ragnese 4y ago
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?
- jshier 4y ago
  XIB? xib files are used in UIKit apps, alongside storyboards, but they're simply serialized views, not a different architecture or paradigm.
  - ragnese 4y ago
    Yeah, sorry. I wasn't being precise. When I say "UIKit" I mean what iOS devs usually refer to as "programmatic views" where you do all the UI stuff in Swift code files rather than the UI Builder and Storyboard tools that Xcode offers. I'm sure SwiftUI is UIKit underneath, too, for what it's worth.
- happytoexplain 4y ago
  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.
  - ragnese 4y ago
    Cool. Thank you for that. I've got through the SwiftUI tutorials and stuff, but I've never tried to make a real project that mixed both approaches, so I had no idea about UIViewRepresentable, etc. 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".
    - Willamin 4y ago
      You can absolutely slowly migrate a UIKit project to begin using SwiftUI – it's part of what I've been doing at work for the past 8 months. The way to cross the boundary from UIKit to SwiftUI or SwiftUI to UIKit (either direction) involves implementing one or maybe two classes/structs and is not too difficult to do.
      - ragnese 4y ago
        Fair enough. I saw your reply to the grandfather comment and I asked some follow up questions there. Thank you. :)
  - Willamin 4y ago
    Part of that is untrue. You can add SwiftUI to an app that starts with the UIKit lifecycle. 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.
xbar 4y ago
This is good advice that I should follow more. But it doesn't address the part where devs find SwiftUI buggy and non-functional where there is a promise of functionality.
zerkten 4y ago
When you support a range of tools, or introduce a new one, you often do it to support different audiences. I'm not an iOS dev. Is it a case that SwiftUI is really intended for a different audience and set of use cases with no expectation of a 100% overlap with the UIKit use cases?
- tarentel 4y ago
  It's marketed as a complete replacement of UIKit.
  - aaaaaaaaaaab 4y ago
    Trust me, noone at Apple believes that. Not even the SwiftUI team.
    - zerkten 4y ago
      What do the folks in the know believe it is?
      - aaaaaaaaaaab 4y ago
        Mostly a shiny tool to lure in beginners and web developers. Kind of like Duplo vs Lego.
tarentel 4y ago
I think trying to re-tool an existing app to be swiftui is a mistake. Replace swiftui with anything and it's a mistake. But swiftui is marketed as a replacement for UIKit and it doesn't seem to work. If I was starting a new app it still seems like a bad idea. Every attempt my team has made to make even small components in swiftui has been a disaster.
tolmasky 4y ago
I think this hides the actual pitfalls: it is possible to be lulled into thinking SwiftUI is the right tool, only to discover that a minor UI change is impossible, leaving you with little option than to dump it entirely for the component in question and rewrite it from scratch in UIKit or AppKit. It is a truism that you should "choose the best tool for the job". Yes, of course. You definitely shouldn't choose the worse tool for the job after all. The tricky bit has always been in determining which tool is best for the job. Once upon a time the answer was easy, there was only one tool, and critically, it was the tool Apple themselves dogfooded for their own stuff, so it was usually at least capable of doing most things. In the age of AppKit/SwiftUI/Catalyst, this is a significantly more difficult question, and this is ignoring things like Electron, etc. The problem with SwiftUi is precisely that if often feels like you only know if it was the best tool for the job after the fact. It requires being an expert in it before you can predict its limitations (which often are bug-related and not necessarily "conceptual"). This would maybe be excusable for a beta release, but SwiftUI is now around 4 years old. Arguably, its original sin is simply not being open source, and on top of that is trapped behind one of the most opaque bug-reporting mechanisms in the industry. Every minor hack involves tremendous reverse-engineering, which may then have to be replicated throughout the community, instead of being a GitHub issue and PR request like in Electron for example. There are of course upsides to the closed-source model, but in 2022, you have to deliver on those upsides if you want to make a strong case for your framework. But as I've mentioned above, SwiftUI hasn't. It has none of the aura or magic of AppKit from the 2000's: a framework used by amazing apps at Apple that can get just about anything done. In fact it is the poster child of all the downsides of this model. And this doesn't even touch on the fact that Apple seems to repeatedly demonstrate that they don't take these technologies very seriously:https://twitter.com/stroughtonsmith/status/1529438357834633216?s=21&t=aIME4FPk_Mlu6zJTJb40dg https://twitter.com/stroughtonsmith/status/15294383578346332...

ragnese 4y ago

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?

jshier 4y ago
XIB? xib files are used in UIKit apps, alongside storyboards, but they're simply serialized views, not a different architecture or paradigm.
- ragnese 4y ago
  Yeah, sorry. I wasn't being precise. When I say "UIKit" I mean what iOS devs usually refer to as "programmatic views" where you do all the UI stuff in Swift code files rather than the UI Builder and Storyboard tools that Xcode offers. I'm sure SwiftUI is UIKit underneath, too, for what it's worth.
happytoexplain 4y ago
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.
- ragnese 4y ago
  Cool. Thank you for that. I've got through the SwiftUI tutorials and stuff, but I've never tried to make a real project that mixed both approaches, so I had no idea about UIViewRepresentable, etc. 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".
  - Willamin 4y ago
    You can absolutely slowly migrate a UIKit project to begin using SwiftUI – it's part of what I've been doing at work for the past 8 months. The way to cross the boundary from UIKit to SwiftUI or SwiftUI to UIKit (either direction) involves implementing one or maybe two classes/structs and is not too difficult to do.
    - ragnese 4y ago
      Fair enough. I saw your reply to the grandfather comment and I asked some follow up questions there. Thank you. :)
- Willamin 4y ago
  Part of that is untrue. You can add SwiftUI to an app that starts with the UIKit lifecycle. 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.

xbar 4y ago

This is good advice that I should follow more. But it doesn't address the part where devs find SwiftUI buggy and non-functional where there is a promise of functionality.

zerkten 4y ago

When you support a range of tools, or introduce a new one, you often do it to support different audiences. I'm not an iOS dev. Is it a case that SwiftUI is really intended for a different audience and set of use cases with no expectation of a 100% overlap with the UIKit use cases?

tarentel 4y ago
It's marketed as a complete replacement of UIKit.
- aaaaaaaaaaab 4y ago
  Trust me, noone at Apple believes that. Not even the SwiftUI team.
  - zerkten 4y ago
    What do the folks in the know believe it is?
    - aaaaaaaaaaab 4y ago
      Mostly a shiny tool to lure in beginners and web developers. Kind of like Duplo vs Lego.

tarentel 4y ago

I think trying to re-tool an existing app to be swiftui is a mistake. Replace swiftui with anything and it's a mistake. But swiftui is marketed as a replacement for UIKit and it doesn't seem to work. If I was starting a new app it still seems like a bad idea. Every attempt my team has made to make even small components in swiftui has been a disaster.

tolmasky 4y ago

I think this hides the actual pitfalls: it is possible to be lulled into thinking SwiftUI is the right tool, only to discover that a minor UI change is impossible, leaving you with little option than to dump it entirely for the component in question and rewrite it from scratch in UIKit or AppKit. It is a truism that you should "choose the best tool for the job". Yes, of course. You definitely shouldn't choose the worse tool for the job after all. The tricky bit has always been in determining which tool is best for the job. Once upon a time the answer was easy, there was only one tool, and critically, it was the tool Apple themselves dogfooded for their own stuff, so it was usually at least capable of doing most things. In the age of AppKit/SwiftUI/Catalyst, this is a significantly more difficult question, and this is ignoring things like Electron, etc. The problem with SwiftUi is precisely that if often feels like you only know if it was the best tool for the job after the fact. It requires being an expert in it before you can predict its limitations (which often are bug-related and not necessarily "conceptual"). This would maybe be excusable for a beta release, but SwiftUI is now around 4 years old. Arguably, its original sin is simply not being open source, and on top of that is trapped behind one of the most opaque bug-reporting mechanisms in the industry. Every minor hack involves tremendous reverse-engineering, which may then have to be replicated throughout the community, instead of being a GitHub issue and PR request like in Electron for example. There are of course upsides to the closed-source model, but in 2022, you have to deliver on those upsides if you want to make a strong case for your framework. But as I've mentioned above, SwiftUI hasn't. It has none of the aura or magic of AppKit from the 2000's: a framework used by amazing apps at Apple that can get just about anything done. In fact it is the poster child of all the downsides of this model. And this doesn't even touch on the fact that Apple seems to repeatedly demonstrate that they don't take these technologies very seriously:https://twitter.com/stroughtonsmith/status/1529438357834633216?s=21&t=aIME4FPk_Mlu6zJTJb40dg https://twitter.com/stroughtonsmith/status/15294383578346332...