|
|
|
|
|
|
by fingerlocks
1243 days ago
|
|
|
I don’t understand. Why stubbornly insist on using pure SwiftUI when UIKit components can be trivially integrated into a SwiftUI app? I have personally dropped using any kind of List/Scroll component because I know I can build a better version in UIKit without much thought.
I have also “converted” a former UIKit app to SwiftUI by dropping the business logic in an ObservableObject and wrapping the rest of the existing code in UIView*Representables. This whole process took maybe a day or two, it’s surprisingly easy. Also, performance pro-tip: Use @Published in an ObservableObject sparingly with most state changes in PassthroughSubject or CurrentValueSubject. |
|
|
Our natural instinct was never to revert to UIKit because we have no experience working with it. This combined with the fact that our problems built up gradually over time, i.e. there were no signs of trouble. By the time we had, we didn’t think — right or wrong — that it would be straightforward to pivot. To be fair to SwiftUI (and us), we’ve made meaningful progress in our optimisation efforts but we can’t consider the effort complete yet.
The other more meta point I would add is if everyone — including Apple themselves — defaulted back to UIKit whenever they hit an obstacle, then SwiftUI stands no chance of becoming a product you can depend on unconditionally with no caveats.
Publishers are dangerously easy to employ, right? This a harsh lesson learnt. Again, when something effectively has no learning curve, then it’s too easy to take for granted. And just as it’s naive/wrong of me to expect my users to use the product in the intended way and not iterate based on the reality of everyday usage, same logic should apply to SwiftUI’s mechanics/UX.