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

Why I quit using SwiftUI

chsxf.dev

Post reply on HN
Print view View original

161–170 of 257 posts

Re: Why I quit using SwiftUI

#161

Post by int_19h »

aaaaaaaaaaab wrote: post #18

People burn an astounding amount of CPU and brain cycles pretending that UIs are something they are not. (i.e. "pure" functions) I hope Apple never goes the way Microsoft did with their fad UI toolkits that utterly destroyed developer trust in native Windows development (MFC, WinForms, WPF, UWP, WinUI, .Net MAUI). They are pretty wise for keeping SwiftUI be the "for kids" vanity UI toolkit to lure in React webdevs, w…

MFC is a thin wrapper around Win32. I don't recall it ever being a fad, either.

WinForms is basically Delphi's VCL ported to .NET. And back in 90s, Delphi was one of the most popular ways to make native Windows desktop apps.

Re: Why I quit using SwiftUI

#162

Post by hota_mazi »

dangus wrote: post #113
ohgodplsno wrote: post #83

Earlier quoted context omitted.

iOS lacks many features that have been standard on Android for years and the only reason it feels so smooth is because the UI thread has pretty much the highest QoL that anything can ever have. iOS would rather drop your network call than drop a single frame. Android variants all have things that iOS can only dream of having in five years (notifications was a fun one), just spread very unevenly throughout manufacture…

The copying of features isn't one-sided. Both companies have had firsts there: https://www.popsci.com/story/diy/stolen-features-android-app... When I switched from Android to iOS in 2016, I was shocked at how little was different, and I can only assume gulf has narrowed since then. A lot of features Android users just assume iOS users don't have are there: vendor-agnostic password manager integration, Safari browser…

iOS still doesn't let you place icons anywhere you want on the home screen, though. It's been fifteen years.

Desktops, and Android, have allowed you to do this for decades.

Re: Why I quit using SwiftUI

#163

Post by abiro »

jph wrote: post #2

SwiftUI is a big opportunity that Apple's not investing enough in, IMHO. It's good tech, and the reactive approach is excellent for many typical view-based needs, but at the same time the docs are terribly lacking at how to handle any kind of edge cases. Success to me looks like steering clear of SwiftUI for now, and advocating for Apple to hire documentation editors/leaders who can 1) create SwiftUI documentation of…

They should just acquihire the Big Mountain Studio guy. It’s crazy that you have to pay $300 for proper docs.

Re: Why I quit using SwiftUI

#164

Post by saagarjha »

This is an interesting article, because SwiftUI has a lot of constraints and quirks (which I definitely will not go into here) but it identifies performance specifically as something they ran into problems with. SwiftUI, like all "reactive" frameworks, specifically tries to make your UI a function of state, trying to "logically" redraw everything so that it's always up-to-date. Obviously, this kind of UI is untenable so it will try to form a dependency graph of what needs updating and change only that.

The issue is that Apple sort of claims that this is all you really need to do, and that the framework will kind of handle it for you. In reality you need to be really careful about what's being updated to avoid spurious updates. Actual SwiftUI code for anything non-trivial necessarily requires some manual debouncing and equatable checks. I hear React Native often has the same issue, but there people have experience with applying memo when necessary. With SwiftUI it's considered "advanced" and bites people before they really know how to deal with it. And, of course, that's assuming that the dependency graph is working correctly: if it's not, you're often stuck and there's often not much you can do.

Re: Why I quit using SwiftUI

#165

Post by NonNefarious »

jph wrote: post #2

SwiftUI is a big opportunity that Apple's not investing enough in, IMHO. It's good tech, and the reactive approach is excellent for many typical view-based needs, but at the same time the docs are terribly lacking at how to handle any kind of edge cases. Success to me looks like steering clear of SwiftUI for now, and advocating for Apple to hire documentation editors/leaders who can 1) create SwiftUI documentation of…

We've been hearing this for years now, though. And we've seen SwiftUI takedowns on here before, a year or more ago, and even then SwiftUI wasn't exactly new.

Meanwhile, my team has built an entire cross-platform desktop app in Qt with QML, which has been around for years and works refreshingly well. You're telling us that Apple, starting fresh and with several years under its belt now, still hasn't gotten its shit together with SwiftUI?

And the word is that nobody at Apple even understands how Xcode works at this point. It's a patched-together shitshow that desperately needs a ground-up rewrite... but we all know how those go. Remember the "ground-up rewrite" of Finder we were promised several major OS releases ago? Still waiting.

Re: Why I quit using SwiftUI

#166

Post by NonNefarious »

bsaul wrote: post #19
retskrad wrote: post #7

People nowadays praise Apple for their hardware, mainly their silicon - not their software. Maybe it's time for Apple to shake things up and promote someone else to VP of Software engineering?

I’m with you, however mac os remain the best dekstop OS and iOS remain the best mobile one, even after all those years. So, they must be doing something right..

Not really. Remember that their "competition" at the time the iPhone came out was utter shit, and Android (although a far cry from those days) is still pretty much shit.

Re: Why I quit using SwiftUI

#167

Post by NonNefarious »

ohgodplsno wrote: post #83
bsaul wrote: post #19

Earlier quoted context omitted.

I’m with you, however mac os remain the best dekstop OS and iOS remain the best mobile one, even after all those years. So, they must be doing something right..

iOS lacks many features that have been standard on Android for years and the only reason it feels so smooth is because the UI thread has pretty much the highest QoL that anything can ever have. iOS would rather drop your network call than drop a single frame. Android variants all have things that iOS can only dream of having in five years (notifications was a fun one), just spread very unevenly throughout manufacture…

You must be kidding. There's no excuse for Android's incompetent architecture, which orphans millions of devices with every release because it apparently lacks a competent hardware-abstraction layer and driver model.

You can install creaky old Windows on millions of devices with disparate hardware configurations on the day of its release, but Android users must wait weeks, months, or forever for their telcos to dribble out hacked, proprietary versions of Android for every model of device ONE AT A TIME. Seriously, WTF? And this is from the great "open-source" OS that was supposed to free us all from vendor and telco tyranny.

What a fraud.

Re: Why I quit using SwiftUI

#168

Post by NonNefarious »

hota_mazi wrote: post #162
dangus wrote: post #113

Earlier quoted context omitted.

The copying of features isn't one-sided. Both companies have had firsts there: https://www.popsci.com/story/diy/stolen-features-android-app... When I switched from Android to iOS in 2016, I was shocked at how little was different, and I can only assume gulf has narrowed since then. A lot of features Android users just assume iOS users don't have are there: vendor-agnostic password manager integration, Safari browser…

iOS still doesn't let you place icons anywhere you want on the home screen, though. It's been fifteen years. Desktops, and Android, have allowed you to do this for decades.

You mean it forces them to be lined up in a grid? Otherwise, I have no idea what you're on about.

Re: Why I quit using SwiftUI

#169

Post by coldtea »

int_19h wrote: post #160
coldtea wrote: post #62

Earlier quoted context omitted.

> I wonder what is the technical justification for it too, if any. Well, apps using it get a uniform look, that uniformly changes when the OS look is updated so that it matches it, and more importantly, they and also get to have the same widgets and widget functionality [1]. Unlike, say, Windows where you have 20 generations of MS GUI lib versions, with different looks and behavior, running at the same time, even fro…

Windows also ships many of those generations of GUI libs with the OS. Your Win11 install will have user32.dll, VB6, WinForms, WPF, and WinRT (might also have MFC, not sure about that one). This is completely orthogonal to look-and-feel.

>This is completely orthogonal to look-and-feel.

Not completely orthogonal, as several different generations of MS GUI APIs implement different look and feels.

And bundling it with the OS means devs aren't forced to update their apps to the new APIs. It also makes it impossible for MS to automatically switch the look and feel (they could try for trivial things, but they wouldn't be able to properly accomondate old UIs based on pixel positions, nor would they be able to offer many of the new features given older widget designs).

https://segmentfault.com/a/1190000040213084/en

https://ntdotdev.wordpress.com/2021/02/06/state-of-the-windo...

Re: Why I quit using SwiftUI

#170

Post by coldtea »

mrtksn wrote: post #93
AlotOfReading wrote: post #88

Earlier quoted context omitted.

I've worked on mice before and frankly I have no clue what sort of technical requirement would lead to an upside down charging requirement and disabling the functionality in the meantime. Can you explain what that reason might be? Also if most people can't just pick up the mouse and use it, it's a broken design. In my particular case, it's so much smaller than my palm that I'm sure any grip would result in RSI.

Simple, the front is not thick enough to accommodate a common port like USB or Lightning. If you put it on the sides, it defies the purpose. Changing the design to accommodate a port in the front doesn't make sense because the primary function of the device is to act as a human-computer interface and optimising the design for that purpose is paramount, charging is not a primary function but something that we have to…

>Simple, the front is not thick enough to accommodate a common port like USB or Lightning

Well, that's the broken design part.

>Changing the design to accommodate a port in the front doesn't make sense because the primary function of the device is to act as a human-computer interface and optimising the design for that purpose is paramount

There's nothing about HCI that prevents a different design.

In fact, the Magic Mouse is one of the least ergonomically optimized mice out there...

Post reply on HN