4 ms·

A friend of mine have been working with porting to iPhone some Android and web apps. I recently asked his opinion of Swift. He said he had no idea as the essent

A friend of mine have been working with porting to iPhone some Android and web apps. I recently asked his opinion of Swift. He said he had no idea as the essential libraries the apps use are in C or Objective-C, so there were no choice but to use Objective-C for the apps. This was surprising, as I thought that calling Objective-C from Swift should be transparent. But it turned out it was not as many small but important details make the whole thing rather messy. So I also wandered what exactly Apple wanted to get with Swift if it lacks even in Objective-C interoperability.

seandougall 8y ago
I'm not sure where your friend was getting that information, or what small details he was referring to. Calling Objective-C from within Swift is remarkably transparent -- where you might have called `[foo bar:baz];`, you call `foo.bar(baz)`. In some cases, wordy Objective-C names will get mapped to Swift's tidier conventions, but the public APIs are all documented in both languages, and Xcode's auto-complete is pretty good at helping you figure it out.
- fpoling 8y ago
  The issue was with exceptions.
dwaite 8y ago
Swift was designed to have very good Objective-C and C compatibility, using the clang compiler to understand headers and generate any Swift binding/bridge at compile time. It will punt on trying to support some things, such as inline functions which are declared as C macros, but generally will try to expose everything. Typically a maintained Objective-C library will evaluate their ability to be used from Swift, and use attributes/macros where necessary to tweak the code import to generate a higher quality Swift interface. Examples would be declaring that a method never returns a nil value, or creating a clearer function name, or switching to the newer Objective-C enum/set styles to have the enumerations generated as Swift types rather than having their API take a raw integer constant or string. AFAIK, all of apple's frameworks are C or Objective C interfaces, and the swift interface is nearly all generated based on the code and public annotations.
valuearb 8y ago
Objective C from Swift is trivial, don’t rely on that friend for technical advice.

seandougall 8y ago

I'm not sure where your friend was getting that information, or what small details he was referring to. Calling Objective-C from within Swift is remarkably transparent -- where you might have called `[foo bar:baz];`, you call `foo.bar(baz)`. In some cases, wordy Objective-C names will get mapped to Swift's tidier conventions, but the public APIs are all documented in both languages, and Xcode's auto-complete is pretty good at helping you figure it out.

fpoling 8y ago
The issue was with exceptions.

dwaite 8y ago

Swift was designed to have very good Objective-C and C compatibility, using the clang compiler to understand headers and generate any Swift binding/bridge at compile time. It will punt on trying to support some things, such as inline functions which are declared as C macros, but generally will try to expose everything. Typically a maintained Objective-C library will evaluate their ability to be used from Swift, and use attributes/macros where necessary to tweak the code import to generate a higher quality Swift interface. Examples would be declaring that a method never returns a nil value, or creating a clearer function name, or switching to the newer Objective-C enum/set styles to have the enumerations generated as Swift types rather than having their API take a raw integer constant or string. AFAIK, all of apple's frameworks are C or Objective C interfaces, and the swift interface is nearly all generated based on the code and public annotations.

valuearb 8y ago

Objective C from Swift is trivial, don’t rely on that friend for technical advice.