5 ms·
The author talks about SwiftUI on macOS, which I also find to be much much more buggy than what's on iOS. Very unexpected things happen, like items in a specif
by mrtksn 4y ago
The author talks about SwiftUI on macOS, which I also find to be much much more buggy than what's on iOS.
Very unexpected things happen, like items in a specific region in the App UI stop responding to clicks next time once you interact with them.
However I find it fine on iOS and the issues are usually around Apple changing something in the behaviour of the UI or API and breaking it, then you need to fix it for specific versions of the iOS. That's what you get when a framework is not mature yet, I guess.
That said, I don't think there's a turning back. It might be buggy but it definitely feels like the right way of building UI.
Oh, about the performance, you can build very sluggish or very responsive UI with SwiftUI because there's a night and day performance cost difference between "re-calculating and re-drawing" the UI and adjusting a property of it. Always try to structure your components in a way that changes happen by changing passed values instead of inserting or re-doing the views.
SwiftUI works quite a bit like React, many performance lessons from React will translate into SwiftUI.
- jamil7 4y ago> Very unexpected things happen, like items in a specific region in the App UI stop responding to clicks next time once you interact with them. I've been able to workaround this by sticking a .id() on the view in question, I've seen similar issues with views falling out of the keyviewloop when you have a bunch of dynamic forms.
- mrtksn 4y agoThanks for the tip!
- guelo 4y agoTying the SwiftUI version to the iOS version is seriously asinine. In the Android world Compose is a regular library so devs can pick the version. That's partly why there has been much more adoption of Compose even though it was released years later than SwiftUI.
- mrtksn 4y agoI wonder what is the technical justification for it too, if any. I mean, sure - you can save space by making it a dynamic library that is shipped with the OS but considering how immature it is, shipping a specific version of it with the app should be an option IMHO.
- callmeal 4y agoMy guess would be a monetary justification. After all you can't just have developers working on year old laptops and devices when you can make them buy new ones by making this one simple change.
- ummonk 4y agoYou don’t have to buy a new laptop or phone to install a software update and start developing for the latest version of iOS / Mac OS.
- jules 4y agoThe potential profit from that is a rounding error for Apple.
- coldtea 4y agoThese kind of "conspiracy theories" for this or that what amounts to negligible money always make me cringe. Not that companies don't do shitty things for money. But they don't do things like that for negligible money compared to their other operations, especially since there are far more important reasons to do them... The reason is platform coherence and control, and lock-step updates. To avoid cases like this: https://segmentfault.com/a/1190000040213084/en https://segmentfault.com/a/1190000040213084/en https://ntdotdev.wordpress.com/2021/02/06/state-of-the-windows-how-many-layers-of-ui-inconsistencies-are-in-windows-10/ https://ntdotdev.wordpress.com/2021/02/06/state-of-the-windo... ...and not the insignificant money that could be made from devs updating a laptop a little earlier (especially since you can trivially use a still supported 5-6 year old laptop anyway with the newest Apple OS, and you wouldn't see any major performance issue, except in cases like the Intel to ARM switching. So what would they gain? Developers forced not to use an 8 or 10 year old laptop? As if they would?).
- deleted 4y ago[deleted]