Hacker News Reader

Comment by jshier | Hacker News Reader

You know you don't have to choose one or the other, right? The languages interoperate and there's really no overhead to adopting Swift anymore. On newer OSes you're using tons of Swift under the hood anyway.

View on HN

I have not investigated it, to be honest. If it's as easy as switching the compiler to Swift, and everything remains working as is, but I also get to use all the Swift stuff in addition to Objective-C, then I am clearly missing out!

At my last job, we slowly started adopting Swift in 2016 by writing some unit tests with it. Once we felt comfortable and established some coding conventions, we started adding some production code. By the time I left in fall 2023, we were well over 50% Swift without any big rewrites of Obj-C code. Almost all the new code came in as Swift because developers enjoyed writing it over Obj-C.

Sounds like you rely on Categories a lot. Check out Extensions in Swift. [1]

There are some limitations (e.g., Swift enums lose a lot of their power if they're needed in Obj-C) but overall the interop is great. I don't remember anything in UIKit that couldn't be done with Swift. And if you're dealing with unicode text, doing things in Swift may make your life much easier.

[1] https://docs.swift.org/swift-book/documentation/the-swift-pr...

They are separate compilers. Obj-C is compiled by clang, Swift by the Swift compiler. You enable bridging in Xcode and then get access to your Obj-C code in Swift through the use of a bridging header, and Swift in Obj-C through the use of the *-Swift.h generated header. You can write classes in Swift that are visible to Obj-C and vice versa. You can't expose everything from Swift to Obj-C since Obj-C is missing most of Swift capabilities, but it's easy to call back and forth.

OK. I see.

I'll definitely give it a try at some point.

Thanks!

Reply on news.ycombinator.com