Hacker News Reader

Comment by melling | Hacker News Reader

It has been 6 years since the debate of using Swift or Objective C for iOS development began.

It was like pulling teeth trying to convince developers to use Swift.

https://h4labs.wordpress.com/2016/02/09/should-i-use-objecti...

The “shiny new toy” argument doesn’t hold for long with Apple. You quickly get left behind in the Apple ecosystem if you don’t move with Apple.

While every language, environment, etc doesn’t need to move this fast, I personally prefer to jettison legacy sooner.

View on HN

> It was like pulling teeth trying to convince developers to use Swift.

Huh? That was not what I witnessed at all. A lot of people were quick to adopt Swift when starting new projects, but still didn't replace Objective-C on the older ones. IMO it was one of the sanest language migrations I ever witnessed in this industry. (Java to Kotlin in Android also as nice and same, IMO)

Considering Apple still has a large Obj-C legacy, I doubt we'll see it deprecated any time soon. Carbon for example took almost 12 years to be removed!

I've seen plenty of people getting all upset that they think Swift 5.3 is still as broken as Swift 1 or 2 back when they last tried it. There are also those, some in this thread, who are proclaiming their high level language of choice as superior just because they're more familiar with it.

> You quickly get left behind in the Apple ecosystem if you don’t move with Apple.

The number of binaries and frameworks in iOS 14 using Objective-C vastly exceeds this relatively small list. Objective-C hasn't been jettisoned by Apple by any stretch of the imagination.

No, but they're releasing new frameworks with Swift-only APIs. They're not "jettisoning" Objective-C, and I'm sure teams at Apple will continue to write stuff in Obj-C for years to come. It'll likely never disappear entirely. But that number will continue to shrink.

That's only because WidgetKit uses SwiftUI. Granted, if more and more APIs become reliant on preexisting Swift-only APIs like SwiftUI or Core ML, that certainly leaves Objective-C out of the cutting edge.

> Objective-C hasn't been jettisoned by Apple by any stretch of the imagination.

True, but melling didn't say that Objective-C has been jettisoned.

My understanding is that you can't iOS home screen widgets in Objective-C, correct? If so, isn't that a reasonably-clear signal that Objective-C developers are starting to be left behind?

> My understanding is that you can't iOS home screen widgets in Objective-C, correct?

I don't know, I haven't looked into them. But Swift is now more than 6 years old, and iOS home screen widgets are literally only days old, so I'd say "You quickly get left behind in the Apple ecosystem" is an exaggeration.

If you're a fan of obj-c it's perfectly reasonable to pretend that swift is just a DSL for describing views and write all of the logic for your widget in obj-c. In that setup SwiftUI is replacing interface builder xibs rather than obj-c.

I started writing Swift within minutes of it being announced. I released my first Swift app on the store just about fifteen minutes after the RC of Xcode was released.

I did a lot of ObjC, but I've enjoyed using Swift. When I create frameworks and modules, they are Swift-only (no ObjC headers), because I like to leverage native Swift stuff, like enums and whatnot.

But I am writing app code. I think ObjC is a better systems language, so I don't think it's going anywhere, any time soon. It's a lot safer than "raw" C.

If you mean Objective-C code with minimal usage of C functions/structs/etc., then IMO Swift is actually the better systems language. Cf. the just-announced System library.

That is the ultimate goal, yet stuff like Metal gets written in a mix of Objective-C and C++14, with Swift bindings.

Correct me if I'm wrong, but I'd bet Metal is almost entirely C++ with a little Obj-C sprinkled on top for the API. And of course C++ is still a better systems language than Swift.

My point was that Swift is better than pure Obj-C for systems programming. Admittedly, that might be a poor comparison, since Obj-C was specifically built to be used alongside C as the systems language.

But yes, I think the ultimate goal is that Swift will be better than C/C++ for systems programming too. It still has a ways to go, and there are a lot of libraries that will need to be written, but I do think it's possible.

> Metal is written in Objective-C, is based on Foundation, and makes use of Grand Central Dispatch to synchronize between the CPU and GPU.

https://www.objc.io/issues/18-games/metal/

C++ is used for Metal shaders.

I love Swift, and it would be a great systems language, but it is important for system languages to have some kind of "bare metal" interfaces, with solid, predictable binary expression. Even C generally needs to be implemented in some kind of specialized embedded form for a lot of tools.

To me, Swift is a fairly high-level language, and I like that. I cut my teeth on the bare metal, and don't really miss working at that level.

I get this, but I also see people I'd describe as real experts saying "SwiftUI isn't ready for production, too buggy for serious apps."

I'm probably going to be all-in on SwiftUI but it does make me nervous -- what if Apple decides the bugginess level is acceptable and you should just code around it if you don't like it? That's a pretty terrible outcome for people like me who are investing now in the ecosystem.

>I get this, but I also see people I'd describe as real experts saying "SwiftUI isn't ready for production, too buggy for serious apps."

Well, there are all kinds of apps written in SwiftUI.

It might not be ready to write Photoshop or Final Cut Pro in it, but most apps aren't "serious" like that. Heck, apps written in even less supported/mature environments (like React Native) will be just fine...

Jettison?

In what language do you think Metal and Core Audio are implemented?

Certainly not objc. Maybe objc++ where everything but the interface is cpp.

> Metal is written in Objective-C, is based on Foundation, and makes use of Grand Central Dispatch to synchronize between the CPU and GPU.

https://www.objc.io/issues/18-games/metal/

C++ is used for Metal shaders.

I very much doubt Metal or Core Audio are implemented in ObjC. C++ or C are much more likely candidates, and is what Apple is generally using for low level code like that...

And Core Animation is all C++ under the hood.

NeXT drivers were in Objective-C.

Yes, 30 years ago.

Those went away along with DriverKit (and the performance issues for drivers due to Obj-C), when Apple created OS X.

Though DriverKit has been now re-used as a name, it's C++.

And you will find plenty of Apple folks at WWDC that resent that decision and would gladly have it back in Objective-C.

As for performance issues, that is the same talk about C devs regarding using C++ on kernel space, go figure.

> Metal is written in Objective-C, is based on Foundation, and makes use of Grand Central Dispatch to synchronize between the CPU and GPU.

https://www.objc.io/issues/18-games/metal/

> Shading Language: C++14, Runtime/API: Objective-C

https://en.wikipedia.org/wiki/Metal_(API)

>And you will find plenty of Apple folks at WWDC that resent that decision and would gladly have it back in Objective-C.

I'm sure you can find 10 of such folks. I doubt you can find 50.

Those 10 are most likely former NeXTSTEP developers that actually know what they are talking about.

...for the time...

Ask C engineers about DriverKit, Treble drivers, UDMF, mbed, GenodeOS and they will answer exactly the same way about C++.

There are many reasons to favor Swift over Objective-C, but "Swift is less visually noisy" is both subjective and not weak. Conciseness and expressiveness can be a reason, sure, but the article also lobs the tired "look at all those square brackets and lack of syntactic sugar" critique.

Reply on news.ycombinator.com