Ask HN: language choice for an iOS SDK in 2018

[alfageme]

During last year, after long and controversial discussions, our iOS team finally agreed to do a full rewrite of our main library.

One of our managers got in touch with a freelance iOS architect to do some consulting on the side while the SDK project gets in initial design and development stages.

Said architect has quite some experience with objC (+10 years) so his language of choice for every discussion. However, the whole team (~3 devs.) is still skeptic on whether to use Swift or its predecessor to start from scratch. The implications of keeping objC. as our library's main language could mean longer development times and less adoption (being an OSS project we also want users to get on board and contribute).

Which language would HN choose? Which reasons would you guys give to some experienced architect to try out Apple's newer language? Would you say, in 2018 Swift is mature enough for this task?

[roop]

If your SDK is meant to be used as a binary framework or in any sort of compiled form (which is probably unlikely because you say it's going to be open source), I'd recommend Obj-C, because Swift's ABI is not stable yet.

If your SDK is meant to be used from source, I'd recommend Swift. I'd even say you should prioritize providing a good Swift API over providing any Obj-C API at all (so if the API would work best if it uses enums with associated values or protocols with associated types, so be it, even if that means it can't be used from Obj-C).

You have mentioned the downsides of picking Obj-C, and they are both valid. There are no upsides to picking Obj-C though - Swift is more popular, and can do anything Obj-C can do (because it can piggyback on the Obj-C runtime when required), and do lots more that Obj-C can't do.

The biggest problems with Swift earlier were (1) Xcode crashing or being too slow and (2) the language changing every year. Both are pretty much fixed now.

At this point, the only reason an Obj-C expert would stick to Obj-C is familiarity - it's faster to code in a language you got to know well over many years. That's however not a reason for _your_ SDK to be in Obj-C.

[codesternews]

In 2017 also you should choose Swift. Swift 4 ABI is very stable(hopefully, I know they are messing some core things with Swift 5 but... ah)

Swift is great language. Apple is also moving their inbuilt apps and frameworks to Swift. No doubt objective-c is compatible but you should choose Swift for sure in 2018.

Reasons:

1) Preferred by apple.

2) Great Community.

3) You will find lots off tutorials and help (after iOS8 etc) in swift.

4) Great language adopted many modern language semantics.

5) It's Swift era.

No doubt, Objc is great language and I have worked many years in it. But when you write the code in Swift language it feels really great and you will find your code less buggy because of many feature provided by Swift (Swift compiler assume you are dumb).

Go for Swift.

[twobyfour]

Not an iOS developer, so please excuse any incorrect details, but:

My understanding is that Swift and Objective-C can each be compiled together with libraries that use the other language. So writing in one language doesn't preclude use by users writing in the other language.

BUT you need to include header files for both. My company actually has to ditch a third party SaaS last year because they'd written a new SDK and header files were available only for Obj-C.