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.
30k lines of SwiftUI in production later
51–60 of 124 posts
Re: 30k lines of SwiftUI in production later
#52I 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?
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…
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
#54Why can't people just use boring technology?
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
#55Earlier 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…
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
#56Re: 30k lines of SwiftUI in production later
#57What 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…
Re: 30k lines of SwiftUI in production later
#58TLDR: 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.
Re: 30k lines of SwiftUI in production later
#59Earlier 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.
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…
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”