[cageface]

You can really see this when trying to build apps with Swift & SwiftUI. The language and the framework seem to be optimized for nice terse WWDC demos but both fall apart pretty quickly when you start to do any heavy UI lifting with them. And I think that's starting to bleed into their own native UI now too. The lousy macOS settings app is a good example.

Unfortunately there don't seem to be any good alternatives to Apple. Windows is even worse.

[neilv]

Yes, I was a fairly early SwiftUI guinea pig, when I'd mistakenly assumed it was solid because of how Apple was pushing it, and your "WWDC demo" is spot-on.

The DSL could've been better (while still syncing between code and direct-manipulation GUI painter). And the interaction model seemed like it wasn't to be trusted, and was probably buggy (and others confirmed bugs). The lack of documentation on some entitlements APIs being demoed as launched left me shouting very bad words on multiple days (which is not something I normally do) before I made everything work.

I could feel this, and ended up wrapping all my UI with a carefully hand-implemented hierarchical statechart, so that the app would work in the field for our needs, the first time, and every time. Normally, for consumer-grade work, I would just use the abstractions of the interface toolkit, and not have to formally model it separately.

Don't get me started on what a transparently incompetent load of poo some of the Apple developer Web sites were, for complying with the additional burdens that Apple places on developers, just because it can. Obvious rampant data consistency problems, poor HCI design, and just plain unreliable behavior. I think I heard that at least some of that had been outsourced, to one of those consulting firms that everyone knows isn't up to doing anything competently, but that somehow gets contracts anyway.

[grishka]

All of these modern "declarative" frameworks seem to be optimized for hello world kinds of apps. Jetpack Compose, too.

And SwiftUI is just being too smart sometimes: https://tonsky.me/blog/swiftui/

Not sure about other people, but for me, my UI framework making its own heuristic decisions about how to lay out and style my views is the last thing I want. It robs me of the certainty that my UI will look and work the way I intend. And this is why, as an Android developer, I still build my apps with decade-old tried and true technologies.

[cageface]

Yeah that view builder syntax is a perfect example of optimizing for the wrong thing. It makes for nice short examples but in real apps your compile times explode trying to untangle these crazy generics and the compiler very often just throws up its hands and tells you to figure it out. This means you just start commenting out bits of code until you find by trial and error what it doesn't like.

That this is shipping in the native UI framework for a trillion dollar tech company is astonishing.

[bitwize]

Except those technologies are now deprecated and you don't know when they might be removed. Jetpack Compose is now the vendor-favored way to build apps, so best practice is to use that.

[grishka]

I don't care what "best practices" are. Seemingly everyone sticks to these, yet here we are discussing that software quality everywhere throughout the industry has taken a dip.

> Except those technologies are now deprecated and you don't know when they might be removed.

Views and activities and XML layout will never be removed, of that I'm certain. After all, Compose does use views in the end. That's the only way to build UIs that the system itself understands. And, unlike SwiftUI, Compose itself isn't even part of the system, it's a thing you put inside your app.

I don't care about deprecations. Google has discredited itself for me and its abuse of the @Deprecated annotation is one of the reasons. The one thing that's very unfortunate is that all tools unquestionably trust that the person who puts @Deprecated in the code they maintain knows what they're doing, and nothing allows you to selectively un-deprecate specific classes or packages; you can only ignore all deprecations in your class/method/statement.

And, by the way, I also ignore the existence of Kotlin. I still write Java, albeit it's Java 17. The one time I had to deal with Kotlin code (on a hackathon) it felt like I'm coding through molasses.

[iknowstuff]

Their new wifi network selector is laggy as fuck. The old one was perfectly fine. This is just like windows reimplementing basic UIs in their UI-framework-of-the-year.

[a-dub]

KDE 6.3 is pretty great these days.

[seec]

Windows is only worse if you don't consider the freedom of choosing the hardware it runs on and its ability to be modified to run as you see fit.

Apple is really losing the plot because they really need their software to be good to sell their hardware. Microsoft doesn't even have to care that much because there is not a relevant alternative coming out any time soon (as the various Linux failures have shown), but at least you don't have to give them a lot of money (in fact as close to zero as possible if you really want to).

[llm_trw]

Ironically Linux with KDE is very good for being both pixel perfect, responsive and enjoyable to work with.

What a time to be alive.

[agumonkey]

"in the beginning was the command line"