I spend most of my time trying to understand the reasoning behind the new way to display alerts in SwiftUI. Kilo Loco on Social Media: www.kiloloco.com X/Twitter - x.com/kilo_loco
SwiftUI also breaks existing design patterns and small companies that use SwiftUI still use UIKit for navigation so it's not even 100 percent SwiftUI. I don't understand who this would be helping beside new iOS developers who have trouble understanding UIKit... SwiftUI is more approachable but there is a ton of underlying abstractions that are confusing and more complicated than UIKIt.
Using a singleton as an observed object in SwiftUI is a recipe for pain. You should try to decouple the service singleton from anything in the view layer. Use a facade with publishers for view-relevant values to wrap the singleton, that way in testing you can stub in a mock.
First, considering how fast people upgrade, it doesn’t need to be backwards compatible. Second, what else are you going to use? Objc, UIKit, and storyboards are complete garbage. To be sure, constraint violations, I would not call reliable and these are things I have to deal with them on a daily basis. Throw in combine and goofy reactive control system, and swift becomes about 2 to 5 times faster for development than any other option. No system is perfect, but if this one isn’t working well for you spent more time getting more familiar with it.
@@bonchbonchno, but they are both in that old vibe of thinking and their time has passed. I build some of the most complicated mobile systems in the world, there’s nothing you can’t do with swift UI that you can do with UI Kit. In both you have to design it properly. That to me is just an excuse for bad coding
@@leifashley SwiftUI doesn't cover everything UIKit and AppKit (especially) can do, so their time hasn't passed just yet. Apple wouldn't be able to rewrite Finder, Xcode, or other core apps in pure SwiftUI. SwiftUI's data-driven nature often requires you to refactor your entire model as the complexity of your app increases because you have to know the complete structure of all your views in advance, which is very difficult. Debugging rendering issues is very challenging, and error messages are often indecipherable or sometimes silent. It's a productive framework for simple apps, but in its current state, it scales very poorly.
@@bonchbonch funny, after 5 years and dozens of apps written in SwiftUI, it seems to work well. You for sure do not need to know everything in advanced or refactor the ui anymore than UIKit. 90%+ of ui components are in SwiftUI, and with better performance out of the box, especially animation. You will always need to refactor an app when it grows because of performance reason, but that has nothing to do with SwiftUI. Given the amount of time saved building with it, at least then you’ll have time past your mvp to do so. I’ve found at any scale the framework works amazingly well and light years easier than UIKit. Constraint violations and qos threading issues are 0.0%. UIKit had its time and the future for it is dead. Live in the past and fall behind, or push forward and grow with the progress of the industry.
@@leifashley Because SwiftUI is so data-driven, you have to stuff a lot of things into the model, and if the design of your views change or you add new features over time, you have to refactor your model. This doesn't scale well with app complexity. Also, the time spent debugging rendering issues is a nightmare. Embracing things because they're shiny and new isn't good engineering practice. Just look at Microsoft's mish-mash of UI frameworks they've introduced every few years. We're several years into SwiftUI now, and developers are still struggling with its bugs and incompleteness. It's currently impossible to write a serious app like Xcode or even Finder in 100% SwiftUI.
This is just painful. You're posting a video two months ago showing support for iOS 15, which runs on 6s, eluding that you need to support old devices. iOS 16 runs on iPhone 8, which was released five years ago, and as of last year in February iOS 16 had an adoption rate of 81%. iOS 17 had an adoption rate of 71% as of February. So either you're supporting antique devices or you just haven't bothered upgrade your code base. But you cannot swift UI for something like that, and neither Android or Java is going to have endless amount of backward compatibility. It's your job as an engineer and the software engineering group to make sure code maintenance is an ongoing process. I'm not sure what the point of this video is except to reach for examples, but unless you're writing apps for the government or finance, I can't think of any other company they would want to support devices this old. Even then, many of those apps have already moved on. I can find reasons to not use SwiftUI, but I can find far far more to not use UIKit ranging from storyboard issues to constraint violations.
I'd be curious to know if any of your opinions, thoughts, or reflections changed once the coffee kicked in or you had more sleep. While SwiftUI has a ton of problems, some of the things you were running into were between the keyboard and chair -- trying to display an Alert view from inside of an alert modifier for one. Wanting to create a wrapper that sits over UIKit already has a name -- SwiftUI. I get it, at least three times a day, I struggle with the question, "Is SwiftUI worth it and should I go back to UIKit?" UIKit isn't without its struggles - e.g. compositional layout and code jumping due to massive controllers has a high cognitive load and can be very error prone to troubleshoot.
I’ve been using TCA for months now. Best way to do swiftUI. It makes things so much cleaner and modular and testable. The new swift macros also allows TCA to be even more easy to use and less verbose
SwiftUI also breaks existing design patterns and small companies that use SwiftUI still use UIKit for navigation so it's not even 100 percent SwiftUI.
I don't understand who this would be helping beside new iOS developers who have trouble understanding UIKit... SwiftUI is more approachable but there is a ton of underlying abstractions that are confusing and more complicated than UIKIt.
The pains starting at 24:35 in regards to alerts are exactly how I feel. They failed this so badly and they're worse than you even know.
Great to see you back!
Glad to be back 😁
Who's idea is to make SwiftUI. Please. Please!
You have posted the video only a minute ago but I’m one of those who immediately like it because the content is sure to be good.
Hope you like it 😁
Using a singleton as an observed object in SwiftUI is a recipe for pain. You should try to decouple the service singleton from anything in the view layer. Use a facade with publishers for view-relevant values to wrap the singleton, that way in testing you can stub in a mock.
First, considering how fast people upgrade, it doesn’t need to be backwards compatible.
Second, what else are you going to use? Objc, UIKit, and storyboards are complete garbage. To be sure, constraint violations, I would not call reliable and these are things I have to deal with them on a daily basis.
Throw in combine and goofy reactive control system, and swift becomes about 2 to 5 times faster for development than any other option.
No system is perfect, but if this one isn’t working well for you spent more time getting more familiar with it.
You don't need to use Objective-C for UIKit. SwiftUI doesn't scale well for complex applications.
@@bonchbonchno, but they are both in that old vibe of thinking and their time has passed.
I build some of the most complicated mobile systems in the world, there’s nothing you can’t do with swift UI that you can do with UI Kit. In both you have to design it properly.
That to me is just an excuse for bad coding
@@leifashley SwiftUI doesn't cover everything UIKit and AppKit (especially) can do, so their time hasn't passed just yet. Apple wouldn't be able to rewrite Finder, Xcode, or other core apps in pure SwiftUI. SwiftUI's data-driven nature often requires you to refactor your entire model as the complexity of your app increases because you have to know the complete structure of all your views in advance, which is very difficult. Debugging rendering issues is very challenging, and error messages are often indecipherable or sometimes silent. It's a productive framework for simple apps, but in its current state, it scales very poorly.
@@bonchbonch funny, after 5 years and dozens of apps written in SwiftUI, it seems to work well.
You for sure do not need to know everything in advanced or refactor the ui anymore than UIKit. 90%+ of ui components are in SwiftUI, and with better performance out of the box, especially animation.
You will always need to refactor an app when it grows because of performance reason, but that has nothing to do with SwiftUI. Given the amount of time saved building with it, at least then you’ll have time past your mvp to do so.
I’ve found at any scale the framework works amazingly well and light years easier than UIKit. Constraint violations and qos threading issues are 0.0%. UIKit had its time and the future for it is dead.
Live in the past and fall behind, or push forward and grow with the progress of the industry.
@@leifashley Because SwiftUI is so data-driven, you have to stuff a lot of things into the model, and if the design of your views change or you add new features over time, you have to refactor your model. This doesn't scale well with app complexity. Also, the time spent debugging rendering issues is a nightmare. Embracing things because they're shiny and new isn't good engineering practice. Just look at Microsoft's mish-mash of UI frameworks they've introduced every few years. We're several years into SwiftUI now, and developers are still struggling with its bugs and incompleteness. It's currently impossible to write a serious app like Xcode or even Finder in 100% SwiftUI.
This is just painful. You're posting a video two months ago showing support for iOS 15, which runs on 6s, eluding that you need to support old devices. iOS 16 runs on iPhone 8, which was released five years ago, and as of last year in February iOS 16 had an adoption rate of 81%. iOS 17 had an adoption rate of 71% as of February. So either you're supporting antique devices or you just haven't bothered upgrade your code base. But you cannot swift UI for something like that, and neither Android or Java is going to have endless amount of backward compatibility. It's your job as an engineer and the software engineering group to make sure code maintenance is an ongoing process.
I'm not sure what the point of this video is except to reach for examples, but unless you're writing apps for the government or finance, I can't think of any other company they would want to support devices this old. Even then, many of those apps have already moved on. I can find reasons to not use SwiftUI, but I can find far far more to not use UIKit ranging from storyboard issues to constraint violations.
Building with SwiftUI is a nightmare when you need to support older iOS version 🤣
Absolute dog water
Then stop supporting older iOS versions… problem solved
Welcome baaaack !!!! ✨✨✨
Glad to be back 😁
I'd be curious to know if any of your opinions, thoughts, or reflections changed once the coffee kicked in or you had more sleep. While SwiftUI has a ton of problems, some of the things you were running into were between the keyboard and chair -- trying to display an Alert view from inside of an alert modifier for one. Wanting to create a wrapper that sits over UIKit already has a name -- SwiftUI.
I get it, at least three times a day, I struggle with the question, "Is SwiftUI worth it and should I go back to UIKit?" UIKit isn't without its struggles - e.g. compositional layout and code jumping due to massive controllers has a high cognitive load and can be very error prone to troubleshoot.
I only use UIKit. I think someone in Apple loves Taylor Swift too much.
how about some Compose Multiplatform where basic stuff doesn't seem to work? it is pretty compelling though, when it works
I havent tried neither Compose/Kotlin Multiplatform yet. Overall, Android development has the worst developer experience so I wouldn't expect much
I’ve been using TCA for months now. Best way to do swiftUI. It makes things so much cleaner and modular and testable. The new swift macros also allows TCA to be even more easy to use and less verbose
i wish swift ui follow what flutter do 🥲