Live data from Hacker News

Why I quit using SwiftUI

chsxf.dev

181–190 of 257 posts

Re: Why I quit using SwiftUI

#181

Earlier quoted context omitted.

I have some friends at Apple... The story goes something like this: SwiftUI came about because someone who has never been a software engineer, got concerned about losing mindshare to ReactNative et al. So this person created a "task force" to deal with the problem by tacking something on top of UIKit that resembles React, to create a "friendly" ingress funnel into the iOS world.

That sounds about right! I recently began developing with Flutter for a project. And whilst I dont love Flutter/Dart that much, I must admit that Google have done an amazing job of proving resources and documentation for the frameworks! The whole Flutter community and available resources feels very rich, welcoming and embracing! Tech like Flutter is fresh and exciting to a lot of people, and Apple is right to be worr…

I’ve recently began developing with Flutter as well. Although I’m not sure about the community, but you’re right, the resources and guidance provided by Google are excellent especially for beginners.

There’s a lot more variety of learning resources compared to other languages; there are texts, workshops, videos, code labs, etc. It’s also nice seeing members of the Flutter team facilitate some of the workshops themselves; it’s refreshing to see developers being involved in educating users, instead of ‘outsourcing’ everything to others.

Re: Why I quit using SwiftUI

#182

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…

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.

Re: Why I quit using SwiftUI

#183

Ugh. I haven't really coded things since I was a kid and since I have an iPad/iPhone/iMac and wanted to learn how to code again and potentially use it as a side hustle or some sort of future money making opportunity, I decided to learn swift/swiftUI and i'm currently taking an online course, but when I read through hacker news, all I see is articles bashing it constantly.

If you’re just starting out, a lot of those complaints will probably be addressed by the time you start your Swift/SwiftUI side-hustle. Unless you’re a very quick-learner in which case you’ll just have to use it in its flawed state, or learn UIKit I guess.

Re: Why I quit using SwiftUI

#184
I've encountered the problem he describes in WinUI, too. It can happen in any toolkit where you bind to change events of "observables". In my case I had a list view and a details view, and when you pressed down in the list view, it would get janky and struggle to update the detail view in time. To make it worse, sometimes selecting a different row would hit off a HTTP request in the background to update some cached data.

I ended up implementing a similar rate limiter, I think based on this here: https://weblog.west-wind.com/posts/2017/Jul/02/Debouncing-an... (I've never shipped it though.)

The art is to get the behavior just right. You want the first request to go through immediately, so on a single click the user sees low latency. But afterwards you need to throttle it so that it only updates every, say, 500 ms. And you must not forget to display the very latest state, if there is no new event after e.g. 50 ms.

This seems like one of those things that are really hard to get right and the toolkit developer should have solved for you. I've struggled with it a couple of times now.

Re: Why I quit using SwiftUI

#185

In 2022 developing software for iOS (now iPhoneOS) feels like you're working for Apple for free. You have to look closely to new requirements that they roll out every few months. You should use Apple products in your app or gtfo (e.g. login with Apple ID). You have to update your laptop every few years because Xcode (which is monumental PoS) requires new MacOS that your hardware doesn't support. And when you go throu…

Apple’s paywall to write apps for their AppStore is infuriating. On top of that, it’s a subscription.

The only thing I want is to develop an app for my own use, but I need a paid account if I want an app that lasts long.

Re: Why I quit using SwiftUI

#186
post #111
post #82

Earlier quoted context omitted.

Style changes and quickly become usability and accessibility issues. I'd rather my app continues to work well as I tested it, than having to test all of the shit on every other OS patch.

I hope you don’t apply the same philosophy to security patches.

In what world would security critical parts affect the UI. What does my ui care if the system libcurl changes? Swiftui is a ui framework, keep that stuff separate

Re: Why I quit using SwiftUI

#187
post #174
post #33

Earlier quoted context omitted.

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.

They were not forced to do it because of their OS woes. They just did the correct thing.

Apple's not doing the correct thing. SwiftUI just created a barrier where people pre-iOS 13 lose access to a lot of apps, and those apps will be raising their minimum version a lot more often than before. So if anything, you could consider this a ploy by Apple to get people to upgrade their phones.

Re: Why I quit using SwiftUI

#188

I've encountered the problem he describes in WinUI, too. It can happen in any toolkit where you bind to change events of "observables". In my case I had a list view and a details view, and when you pressed down in the list view, it would get janky and struggle to update the detail view in time. To make it worse, sometimes selecting a different row would hit off a HTTP request in the background to update some cached d…

If you mean WinUI 3.0, it is in worse state than SwiftUI, to the point Windows 11 is still making use of plain UWP (hence why WinUI 2.x releases keep happening).

And in both cases, still not up to the set of WPF capabilities in that regard.

Re: Why I quit using SwiftUI

#189

Earlier quoted context omitted.

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.

That was a side effect from the likes of Adobe and Microsoft not wanting to rewrite their Mac OS flagship products into Cocoa than anything else regarding maturity.

Re: Why I quit using SwiftUI

#190
post #19
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..

Even though I really dislike how Google screws Java developers with their Android Java approach, I really appreciate their "my way or the highway" regarding the use of managed languages on the platform.

So I wouldn't consider iOS the best mobile one in that regard, as probably no one that suffers being brought sundenly to the home screen due to pointer errors in Objective-C.

Post reply on HN