41–50 of 257 posts
The tooling will always be less mature than you can find elsewhere. And in the end, all you have is a thing that works only in the walled garden.
Of course this observation is not limited to any particular garden.
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.
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.
Earlier quoted context omitted.
There is no evidence to suggest that Apple are deprecating AppKit and UIKit
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.
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, it was still much easier for me (complete newbie to Mac App at the time) to learn and develop in SwiftUI than UIKit.
Hope SwiftUI keeps getting better and keeps investing in the team.
The post didn't go into much detail as to why it seems to be so slow. Is SwiftUI recreating an entire UI's worth of components when a state update happens?
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…
But if you don't keep track of the impurity dependencies on your language, you will need to rediscover those dependencies during compilation, and besides surprising the developer all the time, that's a really nasty problem to solve. That's why it's always solved badly.
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.
Either that, or Electron/Xamarin/React Native.
I am not really a fan of the hybrid apps. I was just watching Slack go crazy on my iPad, a few minutes ago.
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…
Earlier quoted context omitted.
> but at the same time the docs are terribly lacking at how to handle any kind of edge cases. I agree that Apple’s documentation needs help (this year’s improvements are a nice step) but can we really expect them to provide extensive documentation for handling edge cases (you’re telling me UIKit docs offer that)?
Yes, I expect a trillion dollar company to invest in good documentation of their dev products.
Forcing myself to be rational "hate" is probably too strong a word. If you are down the Apple cul-de-sac there is really no turning back. So investing in things like code examples for all of their API (there are a few, a very few) is a waste for Apple. It does not attract new developers and the old ones are stuck in the cul-de-sac.
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.