> SwiftUI is a nice idea in principle, what with being reactive

I want to like reactive, but between its inherent properties, how SwiftUI does it, and the fact I'm having to use VIPER as the architecture for the project…

…I don't like it, but I also don't know exactly where the issue is. And "not knowing where the real problem is" means I also can't add any productive suggestions for how to improve matters, to the very obvious annoyance of the iOS lead.

> I'm having to use VIPER as the architecture for the project…

This is your problem. VIPER is just a huge amount of worthless bureaucratic toil. It’s only useful if your only option to scale development is putting as many warm bodies in seats as possible and need to enforce mediocrity to keep things from going off the rails. It’s not great in general and particularly bad for SwiftUI.

This 100x. A VIPER codebase I inherited for some client work a few years ago was perhaps the most cumbersome and tedious codebase I’ve ever had to work with. Needless to say they missed their launch window and market opportunity.

> The operating system at large still has _tons_ of them that you can't get rid of

Have you tried System Settings > Accessibility > Display > Reduce motion?

Of course. It has almost no effect at all, as far as I can say. These are also important:

  defaults write com.apple.dock autohide-time-modifier -float 0.1
  defaults write -g NSUseAnimatedFocusRing -bool NO
  defaults write com.apple.dock springboard-show-duration -float 0
  defaults write com.apple.dock springboard-hide-duration -float 0
  defaults write com.apple.dock springboard-page-duration -float 0.1

Then it takes just as much time, but instead of movement you get smooth fading between views :)

This is one thing I like about Android. In developer settings you can make every UI animation twice as fast or even turn them off entirely. It's the first thing I do on every device I use.

I think animations are fine and even good as long as they're communicating something to the user (not just done for flare) and perhaps more critically, are non-blocking (e.g. the UI is still functional during the animation) which makes the ability to toggle off animations less necessary.

Switching spaces on macOS is one of the best examples of easy improvements. There's info being communicated (where the user is being swept away to, where the destination desktop sits in relation to the current one) but it should probably be sped up by at least 40% and not block user interaction so if there's a focused textfield at the destination desktop, the user can start typing mid-transition and no text will be lost.

Yeah, UI animations can be good. The vast majority are bad, and even the good ones are almost always too long. That's why it's nice to have a setting for them. Those macOS animations you mentioned have no settings to make them faster and they are infuriating.

On phones I usually speed animations up rather than turning them off entirely. But on the Pixel Watch the animations are so gratuitous and add so much friction to my use of the watch that I turn them off entirely.

I haven't tried a Pixel Watch, but on phones I find Android animations generally kind of awkward. They too often feel like they don't fully connect with what they're animating, if that makes sense, and the curves they're on are often odd. I could definitely see the appeal in turning them off.

What are your favorite parts of gtk+? I'm working on my own UI framework and trying to borrow myfavorite parts of the lot of them. Gtk+4 seems to have some decent stuff, but I've only dabbled with it and worked more with old school QT. I always liked the signals a / slots myself.

GObject signals and properties are very powerful. The layouting model is sane. In general, the toolkit is very regular.

It's hard to just give you a generic answer. I can only really compare to Win32, Cocoa, and some parts of the web stack.

Thanks, that tells me a bit. Signals are my favorite way to do reactivity. I'll have to checkout gtk's properties.