Live data from Hacker News

Why I quit using SwiftUI

chsxf.dev

251–257 of 257 posts

Re: Why I quit using SwiftUI

#251

Earlier quoted context omitted.

Why do your icons move around so much? I've added or removed applications from my iPhone and the only limitation I see is that they have to be in a grid with no empty spaces between them. Otherwise the same application icons are in the same place, every day, year after year. Do you have a screen shot that could illustrate what it is you want to be able to do?

Man... I don't know what's so hard to understand. You put icons on your desktop anywhere you want all the time, don't you? They're not all stacked up starting at the left corner, are they? Imagine that all I want is three icons on my home screen, all lined up on the right edge of the screen, where they are easy to reach by my thumb. You can't do that on iOS.

To answer your question: No, I do not, ever. I don't want shit all over my desktop. I have them auto-arranged in a grid. On Windows they start on the left, on Mac they start on the right. So when I (for example) take a screen shot and it gets deposited on the desktop, I know where it's going to be.

But now that you finally gave a concrete example of what you want to do, I can at least picture it.

Re: Why I quit using SwiftUI

#252
post #226

Earlier quoted context omitted.

I assume you mean Instruments? What have you tried doing? Do you have past experience with how to profile and optimize applications?

> What have you tried doing? Following the instructions from "blogs", official videos, and what official documentation exists > Do you have past experience with how to profile and optimize applications? Yes. About three decades

The first step is usually to figure out what is actually taking all the time, Instruments is good at this. What did it say? Was it your code, or AttributeGraph stuff? Or maybe layout code in UIKit/AppKit? Once you find that you will probably want to isolate which part of your UI is actually triggering this. Ideally identifying if it's a "I got called once and SwiftUI freaked out" or "SwiftUI keeps calling me for changes and I don't have any changes, but this is still bad for performance".

Re: Why I quit using SwiftUI

#253
post #13

The author talks about SwiftUI on macOS, which I also find to be much much more buggy than what's on iOS. Very unexpected things happen, like items in a specific region in the App UI stop responding to clicks next time once you interact with them. However I find it fine on iOS and the issues are usually around Apple changing something in the behaviour of the UI or API and breaking it, then you need to fix it for spec…

> Very unexpected things happen, like items in a specific region in the App UI stop responding to clicks next time once you interact with them.

I've been able to workaround this by sticking a .id() on the view in question, I've seen similar issues with views falling out of the keyviewloop when you have a bunch of dynamic forms.

Re: Why I quit using SwiftUI

#254

Earlier quoted context omitted.

Android has been years behind having a framework for low latency audio and it has always struggled with power efficiency.

The need for low latency audio on your phone is... debatable. Power efficiency, absolutely, and a lot of this is due to them not really giving a damn for a while. Which was great! You truly could do anything with your phone, run things in the background forever, etc. Nowadays, Doze, Android Resource Economy and the need to go through Foreground Services/WorkManager makes it quite a bit harder to do.

> The need for low latency audio on your phone is... debatable.

No, it's just not important to you.

Garageband seems to be pretty popular on all the iOS form factors. iOS has for most of its life had a strong offering of music composition and production apps. iOS has had a high quality media framework for years, Android has not.

And if the need is so questionable, why did Android finally get around to addressing it?

And this seems like an odd argumentative path for an Android fan to go down - downplaying the importance of more niche needs outside social media and cow clicking as not important. iOS does just as well or better for messaging, Instagram and TikTok. If you only care about the smart phone basics for the masses iOS ecosystem is pretty hard to beat with better battery life and support.

Re: Why I quit using SwiftUI

#255
post #253
post #13

The author talks about SwiftUI on macOS, which I also find to be much much more buggy than what's on iOS. Very unexpected things happen, like items in a specific region in the App UI stop responding to clicks next time once you interact with them. However I find it fine on iOS and the issues are usually around Apple changing something in the behaviour of the UI or API and breaking it, then you need to fix it for spec…

> Very unexpected things happen, like items in a specific region in the App UI stop responding to clicks next time once you interact with them. I've been able to workaround this by sticking a .id() on the view in question, I've seen similar issues with views falling out of the keyviewloop when you have a bunch of dynamic forms.

Thanks for the tip!

Re: Why I quit using SwiftUI

#256
post #211

Earlier quoted context omitted.

..and from the crappy excuse for an IDE that they distribute along with their build tooling.

I legit didn’t want to believe my eyes that it takes half a second after each code change before the IDE realizes whether a given change was correct or not. Also, you need clean builds quite often and I even got a “type inference times out” error message once which I haven’t seen in any PL ever even though I did dabble with quite a few static languages with even wider reaching type inference.

Well this isn’t a runtime time language it’s a compile time language they’ve actually done some great work behind the scenes to enable live view debugging (Previews).

Re: Why I quit using SwiftUI

#257

I'm building an IDE in (mostly) SwiftUI, and have been using it since release, so I feel like I've worked with it more than most people. A couple observations: - SwiftUI is really complex It's going to take you at least a year to get used to the declarative way it works, and be able to make UIs without struggling to figure out how to shuffle data around. If you look at SwiftUI examples/code, most of the complexity is…

This isn’t particularly the case changes to the render server are handed off before the runloop iteration ends, and before the runloop iteration ends all changes are aggregated (with the latest evaluated, i.e. @State, etc.) then we see the view invalidated once commits are handed off to the tender server.

What you’d need to be careful off is ensuring your @State or @Published changes don’t too take too long to skip frames

Post reply on HN