HN2new | past | comments | ask | show | jobs | submitlogin

No they don't.

If you use swift features then your class is inaccessible to ObjC. If you mark your class @objc then you can't use many swift features.

The only thing that works well is writing most of your app in swift and writing ObjC wrappers for C/C++ code, because dealing with C in Swift is atrocious and many libraries simply don't work in Swift because of initialization issues with complex structs.

Also, having two tools to choose from that do practically the same thing is never really a good idea because you waste time trying to figure out whether Swift->ObjC interop is going to fuck you over more than ObjC->Swift interop for this particular class.

Also, once you start mixing code and have your code importing a Swift header and your Swift bridging header importing your ObjC classes you start getting huge compile times as anytime you change an ObjC header your entire swift code has to be recompiled which takes forever because the swift compiler is dog slow.

My advice, pick one language for your project and stick with it, the language I would advise until Apple writes base libraries in Swift is ObjC, because if you run into performance issues C/C++ is going to save your ass far more than Swift will.

And mostly because

  var cell = tableView.dequeResuableCell("foo") as! CustomTableViewCell
  is MORE typing than
  CustomTableViewCell *cell = [tableView dequeResuableCell:@"foo"];


And what the heck does that exclamation mark even do? Will the program then crash on NULL (more unsafe than ObjC) or will it just liquify to Kentucky Bourbon?

Personally, I find the concept of NULL (though toxic) more comprehensible and manageable than all those question & exclamation marks in Swift.


Yup, [nil anyMessageReturnsNil] is probably the best decision ever made in ObjC.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: