SwiftUI After 7 Years

Post by layer8 » Mon, Aug 03, 2026, 8:39 AM UTC

mpweiher wrote: post #157

kikimora wrote: post #130

Earlier quoted context omitted.

MVC is not bad, but it is not a silver bullet. Calling MVC an ultimate solution to UI is oversimplification. Just looking at the steps you listed I can ask: How do you collect all notifications on step 2 to fire them on step 3 such that UI does not re-render itself too much? E.g. updating a title of each item in a list of 100 items should not trigger 100 renders. Or 100 layout calculations (which I think is harder to…

I never claimed MVC is a silver bullet. Just that it solves "... incredibly easy to forget an edge case in your update logic." > UI does not re-render itself too much? Glad you asked! In my Blackbird reference architecture (which is an instance of MVC), I use a coalescing queue to capture the updates. The coalescing is two-level: first, simple duplicates are weeded out. Second, if the update queue gets very full, it…

Post by mpweiher » Mon, Aug 03, 2026, 8:53 AM UTC

sirwhinesalot wrote: post #165

rayiner wrote: post #3

The problem with complex systems is that you can be dead long before you realize you're dead. Things can continue to seem "pretty good" for a long time just from the inertia of past good decisions and built-up infrastructure. You see some fraying or cracks but everything looks fundamentally sound, until it isn't. Apple's inability to deploy a new UI framework that's better than the previous one is troubling. This is…

The problem with ObjC was mainly syntax, bolted on over many years on top of a C core. It was grown rather than designed, and it shows. But there's nothing wrong with the runtime. Swift should have just been a much improved syntax over that same runtime. It would have avoided so many headaches. For one they wouldn't have made the awful decision to have return-type overloading and completely ruin the typechecker's per…

    #Grid{ frame: (20@20 extent: 400@340), #rows: [
       [ #Label{ text: 'Name' },          #TextField{ stringValue: 'Taylor', frame: (200@24) } ],
       [ #Label{ text: 'Email' },         #TextField{ stringValue: 'taylor@example.com', frame: (200@24) } ],
       [ #Label{ text: 'Notifications' }, #NSSwitch{ state: 1 } ],
       [ #Label{ text: 'Sounds' },        #NSSwitch{ state: 1 } ],
       [ #Label{ text: 'Summary' },       #PopUp{ items: [ 'Daily', 'Weekly', 'Monthly' ] } ],
       [ #Label{ text: 'Color scheme' },  #NSSegmentedControl{ segments: [ 'System', 'Light', 'Dark' ] } ],
       [ #Label{ text: 'Text size' },     #Label{ text: 'Default' } ],
       [ #Button{ title: 'Reset All Settings' } ],
    ] }.
   

Post by bsder » Mon, Aug 03, 2026, 9:15 AM UTC

mpweiher wrote: post #171

bsder wrote: post #137

Earlier quoted context omitted.

> UI is also very much not functional, I disagree, and I believe that the complete stagnation of GUIs is due to ignoring this. There is no good reason why a GUI system isn't: Description->Pack->Apply events->Generate assets->Render assets. At each point you reify the result into an artifact that is everything the next stage needs. This has a couple of nice properties. One property is that everything is deterministic…

>> UI is also very much not functional, > I disagree, and I believe that the complete stagnation of GUIs is due to ignoring this. I disagree with your assessment. >Description->Pack->Apply events->Generate assets->Render assets. 1. What does that even mean? I don't see a UI in there at all, at best some graphics (Render). 2. That's not "functional". If anything, it looks like a pipeline, so dataflow. But then again,…

Post by well_ackshually » Mon, Aug 03, 2026, 9:29 AM UTC

cosmic_cheese wrote: post #84

kodebach wrote: post #68

Earlier quoted context omitted.

Do you have an example of where "the ideas don't combine well"? Or where an imperative approach is truly better? In my experience the solution is often to use the appropriate architecture underneath your UI layer. Basically you build a data structure that represents your UI and always hand this entire structure to the declarative UI layer. Underneath the UI layer, you can still use imperative code to manipulate the d…

One example of where I think imperative generally does better is UI that requires substantial setup or customization. In SwiftUI, that means endless chains of modifiers, and in Compose this means monstrous constructors and modifier chains. Both get really ugly and painful to read quickly, and there's not a lot that can be done about it apart from breaking everything out into smaller views (which only goes so far). Th…

Post by mpweiher » Mon, Aug 03, 2026, 9:38 AM UTC

ardit33 wrote: post #138

ksec wrote: post #122

Earlier quoted context omitted.

7 Years of release on Swift UI, 12 years for Swift. This isn't 7 years of development, but 7 - 12 years after release . And to most these past 7 - 12 years are an ongoing beta development. It is unfinished, unpolished with no end in sight. And I have been extremely critical since the beginning. But the problem runs much much deeper. It isn't the technology that is the problem, not the devs who are making it. It is th…

I agree with you. Swift should have been a modernized Objective-C. It should have kept the best parts of it, which made it a joy to use, and leave the archaic and the weird things behind. it would have been a great language, meanwhile they decided to throw everything out and created a language that it is overcomplex, and it is failing to gain any traction outside iOS / Apple's ecosystem. Basically, if you weren't req…