
Swift, definition of version 1.0 and ABI stability - zhiel
I don&#x27;t have any opinions on Swift itself, just their versioning. Why would you release 1.0 without a stable ABI? We just had a choice of Swift or Obj-C in our project and Obj-C won by a landslide because its stable. Swift just seems like a toy language that Apple screwed up a long time ago by releasing it way too early. It is basically useless if you need to do anything else than source based integration. I am baffled and confused.
======
melling
Wrong choice.

[https://h4labs.wordpress.com/2016/02/09/should-i-use-
objecti...](https://h4labs.wordpress.com/2016/02/09/should-i-use-objective-c-
or-swift-for-writing-ios-apps/)

You are placing too much emphasis on compatibility. You'll do less work
writing in Swift and fixing any changes than writing all that Objective C
code.

------
rdsnsca
Parts of El Capitan are written in Swift. See :

[http://daringfireball.net/thetalkshow/139/federighi-
gruber-t...](http://daringfireball.net/thetalkshow/139/federighi-gruber-
transcript) From the Link :

"FEDERIGHI: We have all types here within Apple. They start out with the “I
love Objective-C. I don’t want to change” to “OK, maybe there’s something to
this Swift thing” to “Let me give it a try” to “I love it.” We’ve gone through
all the phases internally. You know, we’ve had some really great adoption by
teams like … the team that does the Dock and the window management on OS X,
implemented all their new features for El Capitan in Swift and started mass-
converting all of their code, and say that they couldn’t imagine going back
and that they’re more productive with it. Part of what our internal teams need
to deal with, though, is that they’re working on, let’s say, the current
version of Swift 2.0 while it’s not done yet. I mean, while it’s not even
WWDC-level done yet, right? And they’re working on the interfaces in terms of
our internal frameworks that haven’t been modernized for Swift. And so,
they’ve got it rough. They’ve got to really love it to make that leap because
they’re working on a very, very bleeding-edge environment when we use it
internally. Thankfully, with Swift 2.0 now well out the door, that’s
stabilized things a good bit and they’re really open to it.

But there’s been just lot of feedback. And a lot of it has helped with the
impedance, making sure the impedance between Objective-C and Swift is
absolutely minimized because of course we have and will continue to have and
continue to write more Objective-C code, and so the ability of Swift and
Objective-C code to work together completely naturally is a huge focus. A
bunch of things like generic collection, support for lightweight generics in
Objective-C, were big pain points internally and something we fixed in the
language, and is now great for all of our app developers externally. So, it’s
been a not dissimilar road for us internally to what you see outside. But in
terms of Swift and writing big apps, it’s certainly the case that when Swift
1.0 came out — heck, we didn’t support incremental compilation in the very
first update. And so that was going to be a limiting factor for productivity
for people who had big apps. A lot of that stuff has changed. And then in 2.0
having a good error-handling model, having the availability check so you could
span API versions — these sorts of things. I think it really addressed the
vast majority of pain points that we were experiencing, that I think the
community was experiencing about writing larger apps. And so much about Swift
is actually inherently better for building big apps because it handles modules
and namespaces in a way more naturally than in Objective-C. It makes the API
contracts a little more clear, the code more obtainable. So, we’re very
comfortable."

