Live data from Hacker News

Why I quit using SwiftUI

chsxf.dev

121–130 of 257 posts

Re: Why I quit using SwiftUI

#121
post #53
post #38

Earlier quoted context omitted.

I wonder what is the technical justification for it too, if any. I mean, sure - you can save space by making it a dynamic library that is shipped with the OS but considering how immature it is, shipping a specific version of it with the app should be an option IMHO.

It's probably the same as the technical justification for why Safari updates are bundled with iOS and not separate, why XCode only runs on macOS, why no other browsers are allowed on iOS, why macOS can't have separate scroll directions between mouse and touchpad and many many others. It's Apple's ecosystem, nobody is asking you, you're holding it wrong.

It certainly can have separate scroll directions between (in my case) trackball and touchpad. You have to download a free menubar widget to get it, but so what.

This is in contrast to focus follows mouse, which you really can't do, and I wish it weren't so. In general though? The OS provides a lot of affordances for automation and customization, it exposes some of that through preferences and leaves the rest for developers.

A good example is what you can do to the keyboard from System Preferences (which is quite a bit) vs. what you can do using Karabiner.

Re: Why I quit using SwiftUI

#122
post #96

Earlier quoted context omitted.

You can't put it at the side, the cable will interfere with the keyborad or the laptop that is on the left and won't work at all for the left handed people. I mean, if you really think that charging a few minutes a day or leave it charging overnight once a month is a deal breaker, simply don't buy it but this is not a bad design. It is very unrealistic to expect that the mouse will be used 24/7 every day forever. If…

Won't work at all for left-handed people, as opposed to now where it works for no one during the same period? Seems like an improvement, despite my doubts that it truly wouldn't work for left-handers. Anyway, hopefully we can avoid wild mischaracterizations here. My expectation obviously isn't that things work 24/7 indefinitely. Think about how the typical user is going to discover that the battery is low. Either the…

A few observations here. The first: this product is an optional thing. There are many mice manufactured, they all work with Macs. I, personally, have a Kensington. The last Apple mouse I had possessed a tail, and was only okay, not, for instance, good.

The next one: the charge lasts a month to six weeks with normal use.

Next one after that: it's your unlucky day and you didn't idly think "oh, hey, I'll plug this in over lunch" on week three like a normal person. What you do is plug it in, and take a ten minute break. Everyone has ten minutes worth of things they can do. This gets you to a real break, and now you're good for another six months. Yes, I said months, just plug the damn thing in sometimes. Set yourself a reminder. Don't be a vegetable.

The amount of time you've dedicated to being irritated online about a product you don't use, is longer than the irritation a typical user of that product will experience the entire time they own it.

Congratuations, I guess.

Re: Why I quit using SwiftUI

#124

It sounds like SwiftUI is capable, but not performant for his use case. Fair enough.

It's also not capable right now (macOS 12/iOS 15/Xcode 13) for some parts. For example, there is no simple way to declare initial focus for a text field in a view. One has to resort to "onAppear" hacks, such as:

   .onAppear {
     // 0.05 is a guess. anything lower seems to run too early
     // and does not have the desired effect.
     DispatchQueue.main.asyncAfter(deadline: .now() + 0.05) {
       focusTextField = true
     }
   }
Similarly, dismissing text field focus & on-screen keyboard upon scrolling/tapping away is a source of programming pain. It seemingly was bad in the old APIs. It is worse in SwiftUI in my limited experience. Same for scrolling a view such that an active text field isn't covered by the on-screen keyboard.

Re: Why I quit using SwiftUI

#125
post #38

Earlier quoted context omitted.

I wonder what is the technical justification for it too, if any. I mean, sure - you can save space by making it a dynamic library that is shipped with the OS but considering how immature it is, shipping a specific version of it with the app should be an option IMHO.

My guess would be a monetary justification. After all you can't just have developers working on year old laptops and devices when you can make them buy new ones by making this one simple change.

You don’t have to buy a new laptop or phone to install a software update and start developing for the latest version of iOS / Mac OS.

Re: Why I quit using SwiftUI

#126

Built an  macOS app ( https://posturenet.app ) to monitor my posture in real time with SwiftUI last year for fun. The lack of support for Video and Camera from SwiftUI was the most challenging part for me as a newbie  Mac dev. Took me a few weekends to get the core part done (ML and algorithm), but hooking up all the UI components and connecting them with the video stream gave me so many headaches. With that said,…

You're getting downvoted because HN filters emoji, and because people who aren't on Apple devices won't see the icon you expect, because the codepoint is in the Private Use Area, so they'll see tofu.

Just an FYI.

Re: Why I quit using SwiftUI

#127

I just don't get what purpose it really solves over UIKit. Everything seems far more complicated in SwiftUI, and the data dependence problems it solves did not ever really seem to be a huge issue in UIKit anyway. Apple's sell for SwiftUI was "it's like going to a chef who knows how to cook for you" instead of "cooking yourself". But is that really a good thing? Do we really want to be taking less control of our appli…

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 worried!

So say what you will about Flutter/Dart, love it or hate it, the docs and community are excellent!

Re: Why I quit using SwiftUI

#128
post #97
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..

>"...however mac os remain the best dekstop OS..." I would say this is a matter of opinion.

Certainly not one I agree with.

Re: Why I quit using SwiftUI

#129
post #102
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 view it a different way: macOS and many of Apple's built-in apps/utilities are, at the very least, a less bad option compared to many others. OS utilities like Image Capture, Preview, Apple's screenshot utilities, Spotlight, Quick Look, and quite a few others have been basically "killer apps" that make me want to use macOS over Windows for decades now. Even basic areas like system settings have been a point of frus…

The only one of those apps I used when I was on mac for a few years was iMovie (actually my wife used it, I didn't use any of those apps).

Finder on the other hand...

Re: Why I quit using SwiftUI

#130
post #31
post #4

Earlier quoted context omitted.

It's a great idea but not fully baked yet. My former colleague is using it for internal apps and it seems to work fairly well (UI is not fancy), but not for anything going into the high volume apps, which has much more complex behavior (designers are asking for stupidly complex UI). It's much better in the upcoming OS since they added better navigation, but requires the latest OS, which is not supportive for many com…

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.

We are also in the middle of a rewrite to SwiftUI, did you include the multiplatform option in Xcode 14? Or is automatic. We are just like 5% progress.
Post reply on HN