There were a lot of people actively complaining about ObjC in the lead-up to the unveiling of Swift. In fact I recall one prominent blogger in the iOS community begging Apple just a few months earlier to consider replacing it.

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.

Most of the complaints about ObjC seemed to be from the “weird bracket syntax” folks, at least the loud ones.

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.

It would be interesting if instead of a new language the Objective-C compiler enforced a a memory safe version of C. That’s the biggest advantage of Swift, imho.

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.

Are you talking about the unveiling of Swift or SwiftUI? My recollection was that some people hated ObjC and wanted a more modern language. Apple gave them Swift. But I don’t recall people hating AppKit (maybe I wasn’t remembering correctly) and SwiftUI was basically Apple following the hipster trend.

Just referring to Swift.

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.

Having written actual apps with AppKit, it is horrendously complicated for simple things.

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.

> But 1/ it’s much simpler for doing simple things and 2/ we can drop down to AppKit when needed.

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".

I strongly disagree.After many years in software development, I'm sick of resolving the same issues all over again.Make me write less code, make me spend less time fixing it.That's what is increasing productivity and scope for my projects.

> I strongly disagree.

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".

Apple will likely never drop Obj-C, but it's been a secondary language for years now. New frameworks are all written in Swift, Obj-C is only used for existing Obj-C codebases.

All of Swift's complexity is opt-in, thoughtful, and domain-specific. It's the exact correct type of complexity.

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.

Ah yes, the glory days when you had to sift through 200+ lines of NSLayoutConstraint just to fix a simple layout bug.

This is the main "problem" with autolayout. It's an amazing experience that "just works" if you think in the way that autolayout asks you to (relativity, declarative, the idea that each dimension is fully defined by exactly two constraints, isolation of dimensions aside from aspect ratio, etc).

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.

Just use manual layout / frames dude, like a caveman. (ps. Many successful large apps do just that, including Instagram, and some of Spotify, where I worked).