3 ms·

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

by ksec 2mo ago

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 the person making the decision as to WHY this was allowed from the get go. WHY this was allowed to be released, or even before all that WHY resources for development of these ideas were allowed in the first place. For every yes that are a thousand no. 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. If you look back into Jobs era of Apple software, ( and not just software ) Apple manage to have done most things 2x better with half the resources. The whole Apple now is bloated. And yet everyone is chanting Craig Federighi all the way. And it is funny because for the vast majority of these 7-12 years I was the only few on HN and Twitter that was extremely skeptical of it, to the point I gave up writing ( or ranting ) about it before majority Swift and Swift UI developers negative sentiment emerged. And I have often asked the same question every single time, what if they just spend one fifth of the resources to iterate and improve C / Objective-C and Cocoa. All the resources on Swift and everything adjacent to it could have been better spent somewhere else. I have high hope for John Ternus, hopefully he gets his political game right and manage to change course for Apple software somewhere down the line.

ardit33 2mo ago
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 required to use it, nobody would, which makes it a failure. SwiftUI, should have been a rendering template/library integrated with UIKit. Also, cleaning up some of the UIKit syntanx and framework (simplifying it), and use SwiftUI as a template for UI, would have been ideal. SwiftUI instead was pitched as replacement, yet it is not near as capable as UIKit, and it is not feature parity even 7 years later. Just bad leadership by Apple in this case. (probably many of these decissions were 'promo / resume padding driven' as it happens in many large companies).
- ksec 2mo ago
  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 without Steve Jobs the first time round. On paper there are a lot of cool tech being worked on. But in the end it was tech from NeXT that really shines. And a lot of these tech don't actually benefits the customers. If the choice was a language and framework that is slightly harder to developers but brings overall higher quality Apps because the barrier is higher. Compared to a language that wants to replace Assembly to Javascript while being easy to learn like Visual Basic and for everyone to code. I would much rather pick the former. Edit: I suddenly remember I also submitted a Core Animation introduction video from Steve a while ago on HN [1]. 20 years later we have gone backwards on a lot of things. [1] https://x.com/lucaslovexoxo/status/2082098579632783441 https://x.com/lucaslovexoxo/status/2082098579632783441
  - jstsch 2mo ago
    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.
    - MichaelZuo 2mo ago
      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.
      - simlevesque 2mo ago
        Which tasks ? I don't believe your claims.
DarkNova6 2mo ago
I left Swift and SwiftUi behind be 5 years ago when I switched jobs. I had fond memories and always eyed going back. What were the emerging problems that you talk about? I am actually curious because I was quite fond of the DevEx
rayiner 2mo ago
> 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.
- deleted 2mo ago
  [deleted]
pjmlp 2mo ago
It only worked that way for Steve Jobs, because under him, as it was at NeXT as well, either you dedicate your life to the cause, or go work elsewhere.
lenkite 2mo ago
My opinion is that good old UIKit based on MVC (Model-View-Controller) is simply excellent for building scalable, complex and performant UI's in traditional, compiled languages. The declarative, state-driven UI works wonderfully on the small keynote-demo scale but needs a specialized language to support it on the large scale. Otherwise you waste a LOT of time debugging. And Swift is simply just not that language. Apple should have just invented a specialized UI DSL to support SwiftUI. And continued to support good old MVC first-class. Explicit Constraints, Lifecycle Clarity and Programmable Control make UIKit apps easier to debug and fix. SwiftUI should cleanly extracted out its reactive framework as a standalone, public framework for non-UI or decoupled use-cases. That would have helped in fixing a lot of issues.

by ksec 2mo ago

ardit33 2mo ago

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 required to use it, nobody would, which makes it a failure. SwiftUI, should have been a rendering template/library integrated with UIKit. Also, cleaning up some of the UIKit syntanx and framework (simplifying it), and use SwiftUI as a template for UI, would have been ideal. SwiftUI instead was pitched as replacement, yet it is not near as capable as UIKit, and it is not feature parity even 7 years later. Just bad leadership by Apple in this case. (probably many of these decissions were 'promo / resume padding driven' as it happens in many large companies).

ksec 2mo ago
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 without Steve Jobs the first time round. On paper there are a lot of cool tech being worked on. But in the end it was tech from NeXT that really shines. And a lot of these tech don't actually benefits the customers. If the choice was a language and framework that is slightly harder to developers but brings overall higher quality Apps because the barrier is higher. Compared to a language that wants to replace Assembly to Javascript while being easy to learn like Visual Basic and for everyone to code. I would much rather pick the former. Edit: I suddenly remember I also submitted a Core Animation introduction video from Steve a while ago on HN [1]. 20 years later we have gone backwards on a lot of things. [1] https://x.com/lucaslovexoxo/status/2082098579632783441 https://x.com/lucaslovexoxo/status/2082098579632783441
- jstsch 2mo ago
  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.
  - MichaelZuo 2mo ago
    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.
    - simlevesque 2mo ago
      Which tasks ? I don't believe your claims.

DarkNova6 2mo ago

I left Swift and SwiftUi behind be 5 years ago when I switched jobs. I had fond memories and always eyed going back. What were the emerging problems that you talk about? I am actually curious because I was quite fond of the DevEx

rayiner 2mo ago

> 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.

deleted 2mo ago
[deleted]

pjmlp 2mo ago

It only worked that way for Steve Jobs, because under him, as it was at NeXT as well, either you dedicate your life to the cause, or go work elsewhere.

lenkite 2mo ago

My opinion is that good old UIKit based on MVC (Model-View-Controller) is simply excellent for building scalable, complex and performant UI's in traditional, compiled languages. The declarative, state-driven UI works wonderfully on the small keynote-demo scale but needs a specialized language to support it on the large scale. Otherwise you waste a LOT of time debugging. And Swift is simply just not that language. Apple should have just invented a specialized UI DSL to support SwiftUI. And continued to support good old MVC first-class. Explicit Constraints, Lifecycle Clarity and Programmable Control make UIKit apps easier to debug and fix. SwiftUI should cleanly extracted out its reactive framework as a standalone, public framework for non-UI or decoupled use-cases. That would have helped in fixing a lot of issues.