
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.<p>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.<p>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&#x27;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).<p>Which language would HN choose? Which reasons would you guys give to some experienced architect to try out Apple&#x27;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.

