Hacker News Reader

Comment by melling | Hacker News Reader

It's trivial to add Swift to an Objective C project. Create a bridging file then either create a new Swift class or extend an existing Objective C class.

extension MyViewController {

  func myFirstSwiftFunc() -> Bool {
     return true
  }
}

View on HN

Mixing both adds complexity to the codebase, though. Might as well stick to Objective-C for legacy projects and Swift for new projects.

I think you're overstating the complexity. The real problem is once you see how visually noisy Objective C is compared to Swift, you'll get the urge to translate your ObjC code.

    NSString *s = @"Swift is the future";
    UIViewController *vc = [[UIViewController alloc] init];
    NSArray *names =  @[@"John", @"Paul", @"George", @"Ringo"];

    let s = "Swift is the future"
    let vc = UIViewController()
    let names = ["John", "Paul", "George", "Ringo"]

But the "noise" also reduces ambiguity. For example, you can search the code and see s is a NSString in Objective C. You can't do this in Swift.

Can't say that I see the value in that but you do have the option of adding types the old fashion way.

    let s = "Swift is the future"
    let s:String = "Swift is the future"

It's just a matter of making a coding convention.

You can just alt-click on the variable in Xcode and see the inferred variable type instantly, no matter what the type is or where the variable is declared. No need to search. You can't do this in Objective-C.

Well you can see that s is a string because of the assignment, and if you want you can also add type annotations like

let s: String = "Swift is the future"

Reply on news.ycombinator.com