Live data from Hacker News

30k lines of SwiftUI in production later

blog.timing.is

51–60 of 124 posts

Re: 30k lines of SwiftUI in production later

#51
post #37

Earlier quoted context omitted.

> It’s the same company, they should be able to leverage their past knowledge. It's not the same company. Compare 2023 to 2003. Different CEO, mostly different leadership (only Eddy Cue and Phil Schiller remain), massive employee turnover and new hiring. Even the name is different: Apple Inc. vs. Apple Computer, Inc. https://en.wikipedia.org/wiki/Ship_of_Theseus

I guess that means we should expect AppKit and SwiftUI to never improve.

AppKit has been going downhill for years.

Re: 30k lines of SwiftUI in production later

#52
post #9
post #3

I also fell in love with swift when I had to learn it trying metal. it just succs how you have to use xcode with it.

What's wrong with Xcode? Is it the usual "iPhone is preparing for development" type of annoyances? Is it the bugs that sometimes prevent you from compiling? Or is it something more fundamental like even when everything works fine you don't like it?

> What's wrong with Xcode?

I still have no idea how I can quickly switch back and forth between open files. Either the feature is entirely missing, or completely unintuitive to discover and/or use.

For the record, I am writing this message in 2023.

Re: 30k lines of SwiftUI in production later

#53

> It could — and really should — have been easier, especially considering SwiftUI has had three major updates since it was announced in 2019. Apple (and Next) have been iterating on AppKit for three decades. The UIKit fork of AppKit for iOS is a decade and a half old. Expecting the same level of polish in SwiftUI after three years is a bit overoptimistic. Apple has said that SwiftUI is "where the puck is going" so yo…

Jetpack Compose (Google's alternative on Android, that also works pretty much anywhere you can run a JVM and others like the web [1], terminals[2], powerpoints[3], iOS[4] if you squint, as well as pretty much anywhere you have an imperative API that you want to transform into a functional model[5]) is three years old and is infinitely more polished and has better tools than anything Apple has put out in all of SwiftU…

IIRC the reason why SwiftUI isn’t a separate library is that it’s developed in lockstep with Swift, meaning that each release is dependent on new features in its contemporary release of Swift.

That’s a problem because they stopped building Swift into third party app packages a few years ago in effort to bring down app download sizes, but that means that apps have to deal with whatever version of Swift comes with the user’s system.

The best middle ground would probably be to ship Swift as a periodically updated package.

Re: 30k lines of SwiftUI in production later

#54

Why can't people just use boring technology?

This is why: it's hard to get things right. When I started programming for Apple almost 20 years ago (mainly using Objective C), too many hours of my time were spent making sure that I was dealing with memory correctly. Easier in Objective C than C's primitive malloc/free, but still hard, even with the tools to help. During my time there, new things were tried: firstly garbage collection, and then automatic reference counting. This last got rolled into Swift, and hours spent looking for memory leaks or dangling pointers become a thing of the past. It is still possible to have memory problems in Swift, but mostly they can be avoided.

In the case of UI, use of a library is essential. And of course boring technology has libraries. But the real problem is layout: not just where your elements sit on the page, but where they go after the user resizes a window. In the early years, this was not too difficult because screens were mostly fixed size and in landscape mode. But now there are many aspect ratios, four possible orientations and so on. Apples earlier solution was a system called Layout Constraints. Frankly I found them really difficult to use, even when I stuck with the ones provided within Xcode. SwiftUI seems to me the exactly correct way to deal with layout complexity. Admittedly lots of it needs to be improved (as the article points out), but I would much rather use a declarative approach to layout than any alternatives I know of.

Re: 30k lines of SwiftUI in production later

#55
post #47
post #9

Earlier quoted context omitted.

What's wrong with Xcode? Is it the usual "iPhone is preparing for development" type of annoyances? Is it the bugs that sometimes prevent you from compiling? Or is it something more fundamental like even when everything works fine you don't like it?

1) It's sloooooooooow 2) It's extremely buggy, like on a daily basis where something just doesn't work for any apparent reason that is usually either fixed by killing Xcode or removing derived data & then killing Xcode 3) Lack of plugins for even the most primitive of features like autoformatters 4) XML for build configs inside .xcodeproj 5) Why does it take half a day to update through the App Store? I mean it has s…

On Apple Silicon it's quite performant, I'm sure there are faster things but I don't have complaints on speed o M1 Air. I had complaints on my Intel based mac though.

The bugs can be annoying but they usually go away after restart and cleaning the junk.

> 5) Why does it take half a day to update through the App Store?

But this one is really annoying. Also for some reason in downloads and installs TWICE.

Re: 30k lines of SwiftUI in production later

#57
post #38
post #2

What amazes me is that scrolling has never really been an issue in any native app? And yet here we are in 2023, with a native framework built for modern devices (where scrolling is the main interaction) that... inherits the worst behaviors of web of all things?

Scrolling is hardly a solved problem. On iOS, for example, using UIKit which is very mature and performant, to avoid performance issues with a scrollabe table of, for example, thousands or tens of thousands of items, you use an api that recycles UI components to support lazy loading and the lowest memory usage possible in such a scenario. If you jump in to do this naively, it will destroy the user experience and the…

Infinite scroll on web also rarely recycles elements. It’s more common for sites to leave elements sitting in the page with memory usage gradually creeping up as you scroll. They largely depend on you not scrolling far enough for that to become a problem.

Re: 30k lines of SwiftUI in production later

#58

TLDR: 1) Don't watch too much state with Observable/EvironmentObject. When any watched property changes EVERYTHING RELOADS every time. 2) ScrollView.scrollTo is bugged with ForEach. 3) TextField and keyboard-interactions can be slow and buggy.

EvironmentObject is a total foot gun for performance and causes a bunch of other issues. Core Data and SwiftUI are also awkward together. We ended up keeping Core Data at arms length and building our own internal framework to do dependency injection.

Re: 30k lines of SwiftUI in production later

#59
post #39
post #38

Earlier quoted context omitted.

Scrolling is hardly a solved problem. On iOS, for example, using UIKit which is very mature and performant, to avoid performance issues with a scrollabe table of, for example, thousands or tens of thousands of items, you use an api that recycles UI components to support lazy loading and the lowest memory usage possible in such a scenario. If you jump in to do this naively, it will destroy the user experience and the…

Descriptions like these makes me wonder how we ever made a single computer game with millions of polygons that are in view or not and must be rendered accordingly.

Completely different problem. Rendering millions of polygons is almost trivial to parallelise, and there’s plenty of hardware around that’s capable of providing the needed parallel compute. You’ll note that games have loading screens, those exist so the games can get everything it needs into working memory, order it to enable extreme levels of parallelism. And only then do you get buttery smooth 60fps, and games, of course, stutter and jump if they need to dynamically load new content in, but can’t quite get it into working memory before it’s needed for rendering, usually resulting in entire frames being delayed.

Scrolling on the other hand is a very sequential task, if you don’t want to have a loading screen before displaying the list. The location of every item in the list depends on the location and size of the item before it, those data dependencies make parallelism pretty close to impossible. Made worse when each item is loaded on demand, and needs to execute code to determine how it should be rendered.

Of course, you could load all your scroll data into memory, precompute all the needed render parameters, arrange the results for parallel rendering, then have blazing fast and stable scrolling. Just like a video game loading screen, but then every scrollable view would have a loading screen…

Re: 30k lines of SwiftUI in production later

#60

> It took a few hours to fall in love with SwiftUI. > It was in development for 12 months. It would have been less if SwiftUI just gave. > At the end, we didn’t drop it for a couple of reasons. We were too deep into the process. Being a bootstrapped operation that was already severely behind schedule, we couldn’t afford to restart. This may be useful to someone trying to create something: In terms of software enginee…

Flutter has massive performance issues, is based on a dead end language nothing else uses that lacks basic features, and worst of all is essentially Google developed.

Native devs are going to make a lot of money rebuilding apps for companies foolish enough to base their entire company on a Google “product”

Post reply on HN