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

171–180 of 257 posts

Re: Why I quit using SwiftUI

#171

Post by Longhanks »

ricardobeat wrote: post #101
kitsunesoba wrote: post #15

The main issue with SwiftUI is sheer lack of maturity. People don't think about it, but UIKit now has ~15 years of effort put into it, and got a serious boost from its shared roots with AppKit (even though big chunks of UIKit were freshly written, its structuring and API design were largely informed by AppKit), which has history tracing all the way back to the 1980s. Of course something as fresh out of the oven as Sw…

It is already three years old. I doubt AppKit, UIKit or any of the predecessors were in a bad state for three whole years after their launch.

AppKit was so not mature that Apple shipped its whole legacy UI framework Carbon for a decade to come, with even the Finder itself taking until 2009 to be rewritten in AppKit.

Re: Why I quit using SwiftUI

#172

Post by fuckstick »

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…

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

Re: Why I quit using SwiftUI

#173

Post by pjmlp »

saagarjha wrote: post #164

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…

Not only spurious updates, this kind of architecture generates tons of garbage every couple of seconds, which at least Swift can improve thanks to its support for value types.

React and Jetpack Compose aren't so lucky, having to rely on the underlying optimizations of JS engines and ART, on escape analyis and GC algorithms.

I never understood the love for reactive for interactive GUIs, when they are so bad in memory management and its effects to jank.

Re: Why I quit using SwiftUI

#174

Post by pjmlp »

guelo wrote: post #33
mrtksn wrote: 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…

Tying the SwiftUI version to the iOS version is seriously asinine. In the Android world Compose is a regular library so devs can pick the version. That's partly why there has been much more adoption of Compose even though it was released years later than SwiftUI.

Google was forced to do it, because contrary to iOS, Android updates only take place when one buys a new phone, for all pratical purposes, even if Google pretends we have lots of nice OEMs doing updates.

Re: Why I quit using SwiftUI

#175

Post by pjmlp »

bowsamic wrote: post #28
rudedogg wrote: post #21

Earlier quoted context omitted.

> They are pretty wise for keeping SwiftUI be the "for kids" vanity UI toolkit to lure in React webdevs, while keeping UIKit and AppKit for serious stuff. At WWDC 2022 they specifically said that Swift+SwiftUI is the best way to build apps, and the future of their platforms. I thought AppKit/UIKit would stick around, but I guess not. --------------------------- Edit: Here's the direct quote from the "Platforms State…

There is no evidence to suggest that Apple are deprecating AppKit and UIKit

From the same WWDC,

> The Objective-C language, AppKit & UIKit frameworks, and Interface Builder have empowered generations of developers. These technologies were built for each other, and will continue to serve us well for a long time to come, but over time new abstractions become necessary. For a while now, you've seen us hard at work defining the next generation of integrated language, frameworks, and tools: Swift, SwiftUI, and Xcode Previews.

>

> Tight integration in a development platform like this requires that all three pieces be designed and evolved together, both driving and driven by one another. Swift result builders were inspired by SwiftUI's compositional structure. SwiftUI's declarative views were enabled by Swift value types. And Xcode Previews was specifically designed for, and enabled by, both. Now, the result is the best development platform that we have ever built. And this year, Swift, SwiftUI, and Xcode all have fantastic updates that take this vision further, and make it even easier for you to build great apps for all of our platforms. And it all starts with Swift. Now Ben from the Swift team is gonna tell you all about what's next.

-- https://developer.apple.com/videos/play/wwdc2022/102/

Re: Why I quit using SwiftUI

#176

Post by pjmlp »

aaaaaaaaaaab wrote: post #43
ChrisMarshallNY wrote: post #36

Earlier quoted context omitted.

It'll be around for many years. I know, for a fact, that some AAA applications are still using ObjC. Also, I am quite sure (but don't know ) that Apple still has a plenty big ObjC codebase at home.

Some? More like all AAA applications use ~100% ObjC. I'm talking about apps like Facebook, Messenger, Instagram, YouTube, etc.

Those use mostly C++ alongside Objective-C, or nowadays Swift, unfortuly what most use is something like React Native, Flutter,....

Re: Why I quit using SwiftUI

#177

Post by wzwy »

WanderPanda wrote: post #103
dpmitu wrote: post #31

Earlier quoted context omitted.

At my company we've been slowly rewriting our UIKit app in SwiftUI. We were due for a rewrite when SwiftUI dropped. I'd say we're about 75% done. For those "stupidly complex UIs", SwiftUI just doesn't have enough hooks for customization. And the improvements are too slow. Using SwiftUI has been bitter-sweet. It feels like you just can't use it to craft a high quality app that doesn't look like a generic iOS app.

Is looking like a generic iOS app that bad?! Especially here on HN where the sentiment is pro plain html etc. a generic iOS UI should be well received

I’m new to HN. Why the inclination towards plainness? Is it because of performance or look or something else?

Re: Why I quit using SwiftUI

#178

Post by andrekandre »

saagarjha wrote: post #145
bradgessler wrote: post #144

Earlier quoted context omitted.

There’s a back port of the nav view at https://github.com/johnpatrickmorgan/NavigationBackport

Obviously, this should be something Apple invests into itself. But they're not going to do it because their culture does not value it; actually, they're often culturally blind to the fact that it might even be useful to provide this. With SwiftUI this kind of nearsightedness really hurts the platform.

i think they have a very strong momentum to pushing os releases since... forever...

decoupling is hard to do and i was shocked (and gratified) they backported async/await... but swiftui is ui-level, im guessing there must be some real pushback for backporting it...

as a customer/developer, the whole os release every year is getting kind of old tbh...

Re: Why I quit using SwiftUI

#179

Post by bowsamic »

pjmlp wrote: post #175
bowsamic wrote: post #28

Earlier quoted context omitted.

There is no evidence to suggest that Apple are deprecating AppKit and UIKit

From the same WWDC, > The Objective-C language, AppKit & UIKit frameworks, and Interface Builder have empowered generations of developers. These technologies were built for each other, and will continue to serve us well for a long time to come, but over time new abstractions become necessary. For a while now, you've seen us hard at work defining the next generation of integrated language, frameworks, and tools: Swift…

Indeed

Re: Why I quit using SwiftUI

#180

Post by ohgodplsno »

NonNefarious wrote: post #167
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…

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 dribb…

Welcome to the wonderful world of ARM and driver blobs. Half of the waiting time is waiting for Qualcomm to release a blob (and that's if they even want to), the other half is including it in your build, and eventually making your fork's changes if you want to do so. For every single SoC in your lineup. Then testing if they can support the new requirements of Android.

Apple would have the same problem if iOS was open source and distributable by anyone, their chips being able to be made by anyone. Once again, Apple has picked the easiest (and least open) path, so, yeah, they can upgrade easily.

Post reply on HN