31–40 of 216 posts
Has anyone gotten SwiftUI previews to work at all with a project that has more than 20 files or some dependencies? My project utilizes Firebase as the backend and as soon as you add that dependency - SwiftUI previews never compile, due to build time outs.
Earlier quoted context omitted.
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.
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 c…
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.
Earlier quoted context omitted.
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.
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.
Instead, SwiftUI adopted a whole new set of primitives that doesn’t mix. Accessing the underlying UIView is discouraged, and wrapping up UIKit in SwiftUI feels like a legacy feature. IMO SwiftUI should have been a thin wrapper on UIKit.
$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…
Earlier quoted context omitted.
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 c…
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.
Things were easier when it was just Objective-C and UIKit / AppKit. Swift killed my joy of making iOS apps.
How is Objective-C easier than Swift.
Objective-C compiles much faster. Fewer compiler errors. Fewer compiler crashes. Older projects still compile. The debugger is much more reliable. The entire Objective-C toolchain is more solid, because it's older, mature, and changes less.
Also, easier compatibility with cross-platform C and C++ source.
“Hey I got 90% of what I wanted really quick! Neat!” “…oh turns out that last 10% is basically impossible, eh?”
This seems to be the story of apple in general. Very beautiful and easy to use as long as you stay on the path and don’t go too far along lest you discover the 2nd mile is still under construction.
$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…