Just MHO, and it’s not going to stop the juggernaut, but there’s just no appeal in moving there for me :( If (when ?) Apple drop ObjC, that’s the day I move to Linux
Just MHO, and it’s not going to stop the juggernaut, but there’s just no appeal in moving there for me :( If (when ?) Apple drop ObjC, that’s the day I move to Linux
Unfortunately although Swift seemed promising at first, by the time Swift 3 rolled around a lot of people were actively frustrated and moved on from iOS development. Having actual experienced hands guiding that ship could have led to something great instead of the mess that is there today.
Agree that SwiftUI was just jumping on a bandwagon and would say that the design of SwiftUI clearly strains the poor language design choices in Swift.
Memory management, Generics, Fast enumeration, Properties were seamlessly added to ObjC over the years without adding to the cognitive load of the language, which is minimally more than that of C. It’s a small superset of C and (for me) hits that complexity/expressiveness sweet spot. YMMV, of course.
I hated the properties addition in Objective-C. Why add that and not a dot syntax for all messages? Having a dot operator in a pointer blurred too much of the line between C and Obj-C syntax for my taste.
Swift is incredibly better than ObjC on so many ways it’s just not comparable. I used it since day one and never looked back. (And I was deep into the ObjC ecosystem, having written very low-level frameworks, and having loved it.) Yeah, first versions of Swift were raw, but now it’s just THE language; I used for everything (obviously Apple soft frontend, but also the web, the backend, etc. Even android dev I would do with Swift though I do not have the occasion for now.)
Apple will never drop ObjC support IMHO. But most new frameworks will be Swift-only.
SwiftUI is a step backwards from AppKit in the sense that we lose control over what’s possible when using it exclusively. But 1/ it’s much simpler for doing simple things and 2/ we can drop down to AppKit when needed. All in all, it’s good that we have it.
New things (especially 12 years on) shouldn't be "do simple things simpler, and drop down to old ways for complex stuff". It should be "do complex things simpler".
You strongly disagree with what? That new tools shouldn't just make simple things simpler?
> Make me write less code, make me spend less time fixing it.
But that's exactly where SwiftUI fails, doesn't it? The moment you step outside the "the only UI you can do is lists", you are exactly in the "write more code with weird failures" territory with "just fallback to AppKit for anything even slightly outside of the extremely limited sandbox".
SwiftUI is not Swift. It is implemented using complex Swift features, but it is a huge step backwards in dev-ex from autolayout and UIKit.
If you don't think that way, or you're debugging somebody else's layout, then yeah, it's a nightmare. But it's shockingly easy to just redo the whole layout in that case.