Hacker News Reader

Comment by Hamuko | Hacker News Reader

>a very niche market of 100% native mobile development

I mean, it also works for native desktop development. And is there really an issue with that? Objective-C basically had no reason to exist beyond iOS/Mac programming and at least now we don't have god damn [myString stringByAppendingString:@"another string"].

View on HN

I suspect that we'll be seeing ObjC for a long time, as the lower-level system language for Apple devices. I know that Apple still uses it for much of their system programming. No idea if that's by choice, or legacy (possibly both).

I was looking at the upcoming async/await stuff for Swift, and it's still not comparable to some of the lower-level threading systems.

That said, I have not done system programming for a long time (unless you count drivers). I think Swift is an almost ideal application-level language.

I'm not especially bothered by it being Apple-only. It works on all Apple-supported hardware, has a new application toolkit coming into play (SwiftUI), and has a very active development community. Spend some time on the Swift discussion forum to see some pretty heady discussions.

We'll see it in legacy code for a long time, sure, but there's every indication that all new Apple frameworks are being written in Swift. Anyone starting a new project in Objective-C is in the minority.

> there's every indication that all new Apple frameworks are being written in Swift

There's no such indication. "The number of binaries using Objective-C is still growing with each iOS release." https://blog.timac.org/2020/1019-evolution-of-the-programmin...

The number of binaries of all languages in iOS (except C) increases year over year, so that doesn't really mean anything. It's more telling that the number of Swift binaries in proportion to the number of Objective-C binaries is increasing year over year.

> The number of binaries of _all languages_ in iOS increases year over year

This is not true either. "the number of binaries written entirely in C is now stagnating"

> the number of Swift binaries in proportion to the number of Objective-C binaries is increasing year over year

This is true. But it's a much weaker claim than the one I was replying to.

In other words, the reports of Objective-C's death have been greatly exaggerated. ;-)

If you look closely at how that data was collected, what it's actually measuring is whether a binary links against the ObjC runtime library, which will be the case if a binary transitively depends on any ObjC framework, so even if all new frameworks and executables were written in Swift, we would still expect to see the number presented in that post to continue to grow until most or all of the important frameworks using ObjC are rewritten entirely in Swift. I don't think this data is sufficient to say one way or the other to what degree that is occurring.

Fair criticism. I'm not sure why the author didn't try to detect the use of objc_msg functions, for example. So the ObjC binaries may be overcounted a bit.

Still, the test for Swift binaries seems accurate, and if you look at iOS 13.1 vs 14.0, for example, according to the chart there was an increase of 157 Swift binaries and 446 Objective-C binaries. If we assume there are 157 "false positives" in the ObjC binaries, that's still an increase of 289 ObjC binaries that don't use Swift at all.

Swift frameworks that use ObjC system libraries will still use objc_msgSend.

D'oh, right. A good test might be difficult. In the absence of that, I guess the safe bet is just to count every Swift binary as a false positive for ObjC, though that's not quite fair, since you can mix the two in the same code base.

We'll see. Off the top of my head, only Combine and SwiftUI are Swift only for now. And Combine has specific features that are explicitly meant to make it interop with ObjC (and @objc Swift) objects, e.g. KeyValueObservingPublisher. The other "hot new" Apple frameworks, like CoreML, ARKit, HealthKit, ResearchKit, etc. are all still written in and usable from Objective-C. They _are_ starting to use Swift(UI) in UIKit, but so far continue to wrap it in an Objective-C interface.

Metal is written in Objective-C and C++, with Swift bindings, it isn't going away.

The annoying thing is that all these new libraries can only be used from swift. As interop with swift is a pain from any other language.

I'm a little bit confused by this comment. Obj-C is, in a lot of ways, the _higher_ level language on Apple systems now, and most of what I would consider "systems" programming on macOS and iOS is in C, assembly, and C++.

Probably right, but ObjC inherits C (and ObjC++ inherits C++), so you get all that low-level goodness, as well as the SmallTalk stuff.

You can more or less write C in Swift as well, though. Some pointer operations get more verbose, but the standard library also makes some stuff easier. The only thing that's really missing is a nice fixed-size array syntax (they get imported from C as tuples, which is not ideal).

Const and variadic generics would be nice, yes :)

I suspect we will hit an inflection point where Objc is bridged to swift code rather than the other way around - no reason to let Swift be the one taking the interoperability hit.

There are already controls in Big Sur and iOS 14 (Color Picker) which are SwiftUI and bridged to UIKit/AppKit.

Reply on news.ycombinator.com