Its UI becomes desynchronized and self-inconsistent in ways I wouldn’t have believed are possible. The very fact that it exists and is capable of presenting as incoherent UI as it does is damning evidence against whatever UI framework it uses.
However, its predecessor UIKit is mostly imperative and it takes a lot of manual code to keep the UI reflective of the underlying data model. For this reason I find many IOS apps, and especially apple’s own, to be always mildly broken.
Programming in UIKit is like programming in JQuery, or maybe Backbone at best.
SwiftUI brings us to the modern age of react (but with less capabilities and more bugs)
IOS developers though tend to be pretty resistant to such “modern” paradigms. If you read the rest of the discussion on this post, you fill find that even using Swift, let alone SwiftUI is still a very debated issue.
Maybe the grass is greener, but I don’t find the same resistance for new ideas in the web (typescript) or Android (kotlin) communities.
I do wonder if this resistance is combing from an objective evaluation of the new tech, or the lack of desire/time to learn something new.
The newness is an issue because new SwiftUI revisions ship with new iOS releases, which means that big chunks of it are gated by the oldest iOS version you support. Jetpack Compose on Android gets this more right since it’s independent of the OS, but suffers from other tradeoffs (Java ecosystem and the rest of Android dev gives me a headache sometimes).
SwiftUI is also just missing various things that are present in UIKit, and so if you’re using those things it’s easier to write the whole app in UIKit instead of bridging those controls to SwiftUI.
I absolutely foresee going SwiftUI exclusive but realistically that’s still a few years down the road.
The framework lacking consideration for navigation until recently shows that its rollout has been half-baked, though.
At the start SwiftUI was something you could add to an existing UI/AppKit project, so individual parts could be rewritten. They've been building on top of that since. Refining the api and slowly letting you write more and more with just SwiftUI
This problem isn’t exclusive to SwiftUI though, WinUI/Windows App SDK is also mobile-flavored likely due to its UWP heritage, lacking basic desktop widgets like a tableview/datagrid.
Hah, it's far worse than that - Microsoft has let their desktop DX story stagnate for 15 years now (WPF was launched in 2006), since then Microsoft hasn't launched any new desktop-first UI framework for Windows, nor offered more than token improvements to User32, CommonControls, and WinForms since then.
It's no lie that everything MS has done in the UI-framework space since Windows 7 in 2009 has been a waste of time and money. It started-off with the "Metro" Windows Phone reboot, then the shoehorning of that into Windows 8, and the various XAML-derived frameworks since then - and none of them have attempted to tackle the very fundamental flaws (declarative data-binding doesn't scale, INotifyPropertyChanged breaks causality tracking and cannot be unit-tested, mutable ViewModels were carved by Lucifer himself!) - and as you said, no care or attention is paid to applications needing high information-density display.
----
...so while all this is going on, the Office org came up with its own in-house GPU-accelerated UI introduced in Office 2013 which we can all agree is slow, bloated, glitchy (y'ever used Excel with a 500Hz mouse?), but also proprietary and undocumented, so the wider Windows ecosystem can't benefit from the Office org's framework which would have otherwise (almost) neatly filled the gaps left-behind by the Windows org.
I just want Satya to hire me for the job-title of "VP of Consistent User-Experience" and I'd make it a top-priority that Windows itself comes with a reusable spreadsheet+datagrid component that all applications can use - and it wouldn't cost the company more than a year and a few million dollars - but save billions by avoiding lost developer confidence - and would serve to remind everyone that native desktop UX can always be better than browser-based UX.
---
Sorry, am ranting.
That's funny, just a few hours ago I was looking at some pics of Office 95 running on Windows 95 and reminiscing about how Office's menu bars and toolbars looked/worked differently than the system standard ones despite both being presumably worked on in parallel. Some things never changed.
You may be thinking of Office 97, which introduced the "flat" look for the toolbars and the animated sliding menus.
It is all about financialization of software so art and craft wouldn't matter. End goal is simply cloud desktop with integrated AI/ChatGPT user interface which can be charged per user / per month basis.
We ended up building a cross-platform desktop app in Qt and QML, and it works great.
You are going to have to be willing to stick your neck out a bit though, that’s true.
I suspect even though it was always meant to be a cross-platform UI framework, the initial layout system was designed more toward composing and filling a smaller fixed space than for dealing with large resizable windows.
There’s a ton of potential there and I’m looking forward to having sufficient APIs and documentation to work efficiently with it. At this point it’s kind of painful for a hobbyist like me.
What’s not that hard is managing a bit of state and writing sensible CSS to make it reusable.
as the apps get big, state becomes a mess, fully reusing code is very hard, making anything even slightly reactive becomes not only a lot of code, but a jumbled mess of mutability, usually copy pasted from somewhere else. I will take any other type of app over that - I don't care if it's angular, vue, react, next, whatever.
So i contend that not only is "managing a bit of state and writing sensible CSS to make it reusable" very hard, I haven't even seen it done ever, at least in my personal experience of the code I touched
At a much much smaller scale however, jQuery and CSS or in many cases just HTML and CSS will do just fine. Knowing which approach to take is the mark of someone with some level of experience above junior.
Instead they burn an insane amount of energy (and unfathomable bandwidth) inventing, learning and debugging crazy abstractions and build systems (that change every year or so) on top of the native platform that is the web.
It really feels like a collective bad trip that I hope the industry wakes up from, eventually. But after more than a decade of this insanity, I’m not holding my breath.
Sometimes you choose hypothetically difficult debugging if it eliminates the need to deal with the mechanics of the lowest level of interacting with a system. If you haven't needed to do that, then you'd be inclined to think it's an unlikely situation to be in.
Thanks, I vomited a bit into my mouth.
Resistance to SwiftUI has more to do with the incompleteness and bugginess of the framework than a refusal to embrace modern paradigms.
A common impression of SwiftUI is that it makes hard things easy and easy things hard.
Besides that, many of the “Awards” views frequently show incorrect/ancient/impossible data. For instance I recently saw “You will earn this when you reach you move goal 100 times. You’ve reached your move goal 102 times so far.” with the seat not unlocked. The number sounds only slightly off, but keep in mind that’s 3 days of stale data. I saw similar bugs with the “Perfect Week” award and “Longest Move Steak” one. (At one point I had a move streak of 21 days, the badge said it was 14 days, and the perfect week badge was still not unlocked. You’ll note any 14 day period must contain a full monday-sunday period, not to mention in reality my streak was 3 weeks).
The daily summary view is admittedly fine. Though the refresh interval is something like 15 minutes which is absurd for a pedometer. Not sure if the app or the API is to blame there.
Sight aside, but not really. The settings/Account modal is impossible to discover, and when you do 5/6 menu options have a reasonable flow where you can click to go into the detail view, then hit back to return to the main modal (or exit entirely). Except for the “Change Move Goal” detail, which can only be exited entirely, it is impossible to return to the Account modal directly.
I’ve never used “Fitness+”, their paid offering, but I assume the quality there would be about as bad as everywhere else.
My weekly and monthly sleep averages look about right. The 6 month average is off by about 1.5 hours.
Funnily enough, it’s been off by that amount consistently for at least half a year now.