3 ms·

I’ve never struggled with being on the right thread. It’s always main to update UI. Grand dispatch makes this trivial, and the recent actors work also extends t

I’ve never struggled with being on the right thread. It’s always main to update UI. Grand dispatch makes this trivial, and the recent actors work also extends this. I’m also not sure how this is SwiftUI specific as UIKit and most other UI frameworks are the same. What are the growing pains here?

w10-1 3y ago
Aside from UI updates, processing includes view-model derivations (e.g., calculating errors), persistence, and loading, all of which are offloaded to dispatch queues or actors and then brought back to the UI/main thread. wrt granularity, there's @State, @StateObject, and @Observable, with different binding reaches. So understandably a lot of choices reflecting legacy and new API's, integration with UIKit and web/media services -- and probably AI recognizers in the background. To me the pains are that the approach taken needs to be consistent application-wide (async is pretty viral, queues are designed to be shared e.g., per subsystem, etc.), making it hard to manage or migrate a code base. Also many features build on macros which can make builds almost intolerable. Also saving on macOS vs integrating with update manager on iOS. It can be hard even to find documentation on stdlib feature support e.g., Regex. It's good they maintain both the legacy support and go full-steam-ahead on new features, but developers (i.e., I) need more guidance on tip-toeing around pitfalls and managing platform differences.
brailsafe 3y ago
Well, I've been fighting with an extremely simple Navigationsplitview for ages. Put a list in the sidebar, put 100 items in it, and render almost anything else in the detail on macos (one version back). Then select an item in the nav and hit the down arrow. Depending on implementation, scrolling will get clipped to the visible area, it'll hold onto multiple selections if the first has been scrolled off screen, or the main thread will get thrashed and performance will be about what the current settings menu is. I haven't found something that I don't have to accept a really mediocre experience with, but next I'm going to try rewriting it with NSTable

w10-1 3y ago

Aside from UI updates, processing includes view-model derivations (e.g., calculating errors), persistence, and loading, all of which are offloaded to dispatch queues or actors and then brought back to the UI/main thread. wrt granularity, there's @State, @StateObject, and @Observable, with different binding reaches. So understandably a lot of choices reflecting legacy and new API's, integration with UIKit and web/media services -- and probably AI recognizers in the background. To me the pains are that the approach taken needs to be consistent application-wide (async is pretty viral, queues are designed to be shared e.g., per subsystem, etc.), making it hard to manage or migrate a code base. Also many features build on macros which can make builds almost intolerable. Also saving on macOS vs integrating with update manager on iOS. It can be hard even to find documentation on stdlib feature support e.g., Regex. It's good they maintain both the legacy support and go full-steam-ahead on new features, but developers (i.e., I) need more guidance on tip-toeing around pitfalls and managing platform differences.

brailsafe 3y ago

Well, I've been fighting with an extremely simple Navigationsplitview for ages. Put a list in the sidebar, put 100 items in it, and render almost anything else in the detail on macos (one version back). Then select an item in the nav and hit the down arrow. Depending on implementation, scrolling will get clipped to the visible area, it'll hold onto multiple selections if the first has been scrolled off screen, or the main thread will get thrashed and performance will be about what the current settings menu is. I haven't found something that I don't have to accept a really mediocre experience with, but next I'm going to try rewriting it with NSTable