[Hashex129542]

Mostly nonsense updates.

Swift was my favorite programming language after C++/Java since 2014. I've been faced major updates few times happily. It was one of the most easiest language. But now,

I tried to update a project from Swift 5.x to 6.x which has 150+ source files itself and no external libraries which is written by my own use and it has almost all swift 5.x features. They made up Swift as super hard. I decided not to use Swift 6 anymore and yes I don't need to reduce debugging time, Even though I don't have powerful computer and debugging time isn't matter to me & development time is actual matter to me.

The language itself becomes Rust (the programming language using by aliens). I Hope Swift language is upgrading itself for Aliens or the Swift team is filled with Aliens. Now, I feel ObjC is super easiest language than Swift.

PS: I understand Swift is Corporate Product & upgrading towards SwiftUI than general purpose programming language. I never gonna use Swift 6 even I do use ObjC for my projects.

[wsc981]

I find 'simple' languages charming. Hence, I still like Objective-C. I also like Lua a lot.

I liked Swift when I tried it a couple of years ago, but it seems overloaded with features these days. I haven't tried Swift UI yet, but I did think the Objective-C approach with xibs, struts and such worked fine.

[wingerlang]

There is probably around a decade-long leap between XIB and SwiftUI. XIB files are only found in legacy code nowadays. It might have worked fine in smaller projects, but I think there are good reasons why it was left behind.

In my experience, most XIB files were either so small and easy that it was simply easier to replicate it in ten lines of code. Or so giant an impenetrable that it took thousands of lines of code to replicate it with, and at that point most people prefer to work with code over a dense XIB file.

[rcruzeiro]

xibs were an absolute nightmare if you worked with a team. Even in the Objective-C days a lot of developers were sticking with programatic layout to avoid xibs. Google even had this mandated in their Objective-C style guide.

[cosmic_cheese]

On iOS, code-only UIKit with bits of SwiftUI interspersed for simple components (think collection view cells) is definitely the way to go. UIKit is well equipped to be written that way (unlike Android Framework, which practically forces use of XML layouts in many cases).

For Mac dev, AppKit is still fairly heavily weighted towards use of XIBs, but it’s not nearly as much of an issue there because on average each individual XIB isn’t as overloaded with controls because the UI is more split up.

[rcruzeiro]

I’ve also had a good experience using SwiftUI with hosting confia for my cells. I am now at a point where I mostly use SwiftUI with just the occasional fallback to programmatic UIKit for the bits that are not quite there yet.

[saagarjha]

FWIW Android's XML layout is actually pleasant to use (though Jetpack Compose is also quite good).

[cosmic_cheese]

My experience with Android XML is mixed, but that might actually be more of an Android Studio problem. I did enjoy being able to reasonably hand edit the files, which isn’t practical with XIBs, and so naturally git conflicts aren’t as hairy.

I definitely prefer Compose these days though.

[saagarjha]

Google's style guide is usually not a great reference if you want to write a language that they didn't make. But yes, XIBs kind of suck.

[ardit33]

I don't use the new concurrency features, as they are one of the main culprits of this mess. (so stick with 5.x)

SwiftUI is a wreck, that is still not good for advanced UI and you still have to use UIKit for some parts, and

Taking Objective-C, with DispatchQueue, and some modernization of it, and some new data structures, which it need, was all it was needed to make a good new langue.

It could have been Apple's rival to GoLang, but instead it ended up being hydra/monster with too many pardagimns, and none of them are good.

[myHNAccount123]

> SwiftUI is a wreck, that is still not good for advanced UI and you still have to use UIKit for some parts, and

Skill issue. *ViewRepresentable exists.

[ardit33]

You are making my point... if you have to use ViewRepresentable in half of the app, then SwiftUI failed. It was supposed to completely replace UIKit, but now it is just another framework to work with...

(makes easy things super easy, but harder/complex things harder).

It has some ways to go......

[myHNAccount123]

Many developers have no issue achieving their desired designs with Representable or just swiftui.

[Hashex129542]

> but instead it ended up being hydra/monster with too many pardagimns, and none of them are good.

So true.

[viktorcode]

My guess is you've encountered issues with actor isolation made suddenly explicit in your language upgrade. This is exactly what's addressed in Swift 6.2, so it won't be nonsensical in that case. Speaking from my personal experience of trying to upgrade and stopping.

The moment this language version is released I will move to Swift 6. In our project case it will happen. with no source code changes.

[Hashex129542]

Yes, https://stackoverflow.com/questions/79589648/actor-isolated-...