Parts of OS X El Capatian are written in Swift . Source :<p><a href="http:&#x2F;&#x2F;daringfireball.net&#x2F;thetalkshow&#x2F;139&#x2F;federighi-gruber-transcript" rel="nofollow">http:&#x2F;&#x2F;daringfireball.net&#x2F;thetalkshow&#x2F;139&#x2F;federighi-gruber-t...</a><p>&quot;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.<p>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.&quot;