Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SwiftUI After 7 Years

ykvm.com

Post reply on HN
Print view View original

231–240 of 343 posts

Re: SwiftUI After 7 Years

#231

Post by mpweiher »

jay_kyburz wrote: post #205
mpweiher wrote: post #159

Earlier quoted context omitted.

Yeah, M-V-C are all roles, not concrete objects. The C mediates between the input devices and the model, but in practice views can and often do fulfill that role as well. Cocoa views, for example, also fulfill the C role. Different formulations of M-V-C have the C deal with more complex interactions, with sequences of interactive prompts like wizards. The update is essentially automatic, and yes: MVC already solved t…

I like my Controller to be responsible for all the "business logic" so that its all in one place. It's the important part. The View layer is always fairly verbose and full of fluff. Especially if you have a lot of animation and formatting type code.

> I like my Controller to be responsible for all the "business logic" so that its all in one place.

Business logic is supposed to go in the model. All of it. Because it's the important part.

Controller these days can be largely empty.

"MODELS Models represent knowledge. A model could be a single object (rather uninteresting), or it could be some structure of objects.

There should be a one-to-one correspondence between the model and its parts on the one hand, and the represented world as perceived by the owner of the model on the other hand. The nodes of a model should therefore represent an identifiable part of the problem.

The nodes of a model should all be on the same problem level, it is confusing and considered bad form to mix problem-oriented nodes (e.g. calendar appointments) with implementation details (e.g. paragraphs)."

https://web.archive.org/web/20090424042645/http://heim.ifi.u...

Re: SwiftUI After 7 Years

#232

Post by pjmlp »

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…

So just like Objective-C?

Rescued by NeXT's acquisition, having failed to gain market adoption otherwise.

Re: SwiftUI After 7 Years

#233

Post by pjmlp »

mbishop wrote: post #215
sirwhinesalot wrote: post #165

Earlier quoted context omitted.

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…

Gotta take issue with the characterization of “bolted on”. That’s a design feature and it’s huge. It made interoperability trivial. You can write C, C++, and Objective-C within the same source file .

Including the CVEs from C style coding, a desgin feature it shares with C++.

Re: SwiftUI After 7 Years

#234

Post by MichaelZuo »

jstsch wrote: post #195
ksec wrote: post #145

Earlier quoted context omitted.

While reading this comment, two of Steve Job's line pops up in my head. I think it was the Apple Park opening, and Steve response to insult in WWDC 199x. > "We need to be true to ourselves, and remember what is important, that is what going to keep Apple Apple, is if we keep us, us." > "You have got to start with the customers experience and work backwards to the technology. Right now it feels a lot like Apple withou…

I remember this video, from way back. Then, it was impressive, but it also felt logical that machines of that era were able to do it. So it wasn't magic. Just good engineering. Now everything is jank & stutter and my 64GB 25 times more powerful machine just refused to play back a YouTube video in my Safari tab since I have too many windows open.

My base 2019 macbook pro 15 on Mojave is actually faster than new macbook pros today on some tasks.

There’s no way Apple doesn’t know about that internally. So I don’t see any other explanation… other than a lack of care, or a bozo explosion.

Re: SwiftUI After 7 Years

#235

Post by steve1977 »

mort96 wrote: post #226
mpweiher wrote: post #168

Earlier quoted context omitted.

Yes, they don't ever openly admit mistakes. But they do quietly drop or fix them, covertly acknowledging they were mistakes. Often with this messaging: "we have this new shiny thing that is even better than the old shiny thing (that was really a turd)". Remember "garbage collection"? Or "modern syntax"? Or CocoaJava? And with hardware they had their "come to Jesus" moment a while ago. And then hit it out of the ballp…

SwiftUI is too big to silently drop. It is too difficult to silently fix.

So the only way out is something new again.

Re: SwiftUI After 7 Years

#236

Post by iainmerrick »

steve1977 wrote: post #220
iainmerrick wrote: post #175

Earlier quoted context omitted.

Cocoa and Objective-C are both great, but I think there's one huge problem that they never managed to solve well: responsive layouts. Classic iPhone apps have fixed layouts, and classic Mac apps have a big dynamic document in the centre with mostly fixed toolbars around the sides, and dialogs with fixed layouts. Making a really dynamic layout with OS widgets is a huge pain, so most apps sidestepped it. As Apple gradu…

Maybe responsive layouts are part of the problem? I get their appeal (in the sense of only having to develop one layout), but IMHO, in many cases more strict layouts would be the better choice. You mention classic apps having a fixed layout, I think that's a good thing. Not every user interfaces makes sense in portrait AND landscape mode for example. And the slightly different sizes of iPhones are not really that pro…

Well, you can still have breakpoints, and switch between different structures for e.g. mobile vs desktop, or landscape vs portrait.

But I don't think you can cover all requirements with a set of fixed layouts, they do need to be somewhat flexible. Even if all screens were the same size, you'd want to be able to boost the font size for accessibility, and that essentially means scaling the whole UI.

And the slightly different sizes of iPhones are not really that problematic with something like autolayout.

I think something like flexbox is a better fit. There are tradeoffs in each approach, but I usually find a local, modular, bottom-up approach easier to work with than global constraint solving, even though it seems in principle like it should be nice to be able to say "keep this button here in relation to this other button". As you add more constraints like that your layout slowly turns to mush and doesn't actually resize nicely. (Edit to add: I'm probably conflating a few different generations of iOS toolkits here, I realise autolayout is somewhat separate from constraint-based layouts.)

I don't think it's a coincidence that most other UI toolkits have added something like flexbox (including iOS) -- it's not perfect but it fits how people generally think about UIs. Was HTML/CSS the first major UI framework to use flexboxes? That's how I remember it, but maybe it was copied from somewhere else.

Re: SwiftUI After 7 Years

#238

Post by rayiner »

ksec wrote: post #122
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…

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…

> Instead a lot of Apple's software development can be summarised as resume or KPI bonus driven development. It is not as bad as Google and Microsoft, but it is clear Apple have this problem a well.

When did the term “KPI” come into use at Apple? I’m aware it was used in management circles decades ago but I don’t remember it being so common say in 2005. The underlying concept is sound, but the problem with abstracting it under an acronym is that it treats KPIs as somewhat fungible regardless of importance. It’s like “lines of code” as a productivity measure all over again.

Re: SwiftUI After 7 Years

#239

Post by rayiner »

jstsch wrote: post #195
ksec wrote: post #145

Earlier quoted context omitted.

While reading this comment, two of Steve Job's line pops up in my head. I think it was the Apple Park opening, and Steve response to insult in WWDC 199x. > "We need to be true to ourselves, and remember what is important, that is what going to keep Apple Apple, is if we keep us, us." > "You have got to start with the customers experience and work backwards to the technology. Right now it feels a lot like Apple withou…

I remember this video, from way back. Then, it was impressive, but it also felt logical that machines of that era were able to do it. So it wasn't magic. Just good engineering. Now everything is jank & stutter and my 64GB 25 times more powerful machine just refused to play back a YouTube video in my Safari tab since I have too many windows open.

My iPhone 16 Pro is the jankiest user experience I’ve had on a new iPhone ever. On my Mac the settings app pauses and stutters. Jobs would have thrown things if he ever saw this.

Re: SwiftUI After 7 Years

#240

Post by polyterative »

troupo wrote: post #223
frizlab wrote: post #86

Earlier quoted context omitted.

Having written actual apps with AppKit, it is horrendously complicated for simple things. Swift is incredibly better than ObjC on so many ways it’s just not comparable. I used it since day one and never looked back. (And I was deep into the ObjC ecosystem, having written very low-level frameworks, and having loved it.) Yeah, first versions of Swift were raw, but now it’s just THE language; I used for everything (obvi…

> But 1/ it’s much simpler for doing simple things and 2/ we can drop down to AppKit when needed. New things (especially 12 years on) shouldn't be "do simple things simpler, and drop down to old ways for complex stuff". It should be "do complex things simpler".

I strongly disagree.After many years in software development, I'm sick of resolving the same issues all over again.Make me write less code, make me spend less time fixing it.That's what is increasing productivity and scope for my projects.
Post reply on HN