There is no reason to replace perfectly working code that is battle tested if the requirements don't change.

The fact that the new binaries on it are written in Swift is showing their 100% commitment to Swift, which is great to see. And why wouldn't you, Swift is a joy to work with, especially if you're from Apple :)

The article has a lot of very opinionated comments, some of them not true (e.g. ObjC development has not completely stopped). There are definitely some truths in there too, like how fluid the language has been so far (last year’s Swift code probably won’t just compile this year).

In general, I think it’s fair enough to say that Swift hasn’t matured yet. It’s not so stable, and tooling isn’t great. Large projects might suffer from that. ObjC on the other hand is rock solid, but lacks some of the more modern language features of Swift.

Personally, I’m all for Swift, because it’s the future. Tooling issues and stability can (will?) change. Turning ObjC into a modern, next generation language just isn’t something that seems feasible.

Aside from that, Swift is a really neat language - tooling aside, I find that Swift is (mostly) a great language to write in, with features that I’d sorely miss going back to ObjC. That’s purely opinion though, I’m sure there’s others that might say the same from an ObjC standpoint.

Since it's already done I don't want swift to go away at this point. However, if given a choice between keeping objc and having a much better development environment or getting a totally new language (and the division it will bring) and a buggy IDE, I would've picked the former.

I really don't understand how a compiler can crash that much ( actually i've been coding in many client and server languages before and it's the first time i see a compiler crashing while i code). It makes me really nervous, because it shows that unit tests aren't good enough, and that the language is really in alpha stage, not more.

As for compilation time, you may think it's just a matter of optimisation. But the problem is that until those optimisation arrive, you can't rely too much on type inference (main source of slowdowns), which diminishes a lot the beauty of the code.

Now that was for client side. Server side probably adds its share of issues.

I used to be very optimistic for this language, but i'd say the swift team only has one more shot to make it really production grade, before the word spreads that this language is for now just a joke ( maybe apple using it for its own app would help allocate more resources).

This aside - I also disagree with you, Swift is a worse language in a lot of ways, not to mention the extreme compile times and purely unfinished concepts, as well as bugs related to seemingly foundational things like auto-created initializers for structs not getting picked up properly by sourcekit.

ObjC seems a bit cobbled together, and a lot of things look a bit more verbose that they need to be. And there's some type safety issues lurking in various places, too. And then there's the whole having .h and .m files, an inconvenient way to organise things in this day and age. Sure, I was used to it from c++, but that isn't the fastest language to code in, either.

One needs to get over the trepidation of a new language. I was talking to another CTO about this, a guy who's been coding for 30 years. Once you understand the domain and you can solve the problem, language is not a big deal. Of course you need a language that contains the abstractions of the solution, but generally any OO language will be able to do it. What's left then is whether the language lends itself to coding tools, terseness, library availability, and the level of granularity you need.

As a language that's focused on building nice apps, Swift strikes a good balance. If I'm going to be doing UI stuff, I can assume I won't need the fine-tuning that something like c++ gives me. I generally don't want to be bothered by the memory management, and I don't expect performance to be a big deal (people can wait dozens of ms for something, they won't notice). If anything takes a long time, I can use GCD just like in ObjC. I care that things are easy to find in the code, and there aren't many contortions (eg pull out something as an id and cast it. Concat a string by using a ludicrously long function with an unobvious name). There's library compatibility, so I can pretty quickly glue together an app from the same pieces as ObjC, with less glue.

The good and bad of Swift is the regular breaking updates. Sure it’s a pain when things change, but it’s also healthy when they improve, and almost every change has been an improvement.

A language as simple as C can slowly grow without breaking existing source code. But it’s also never been able to address its most significant flaws.

We're getting close to release, so we have less pressing bugs and no new features to implement, so myself and a team mate decided to take a week to perhaps refactor some of the code and update it to Swift. After said week we reach the conclusion that management made the right decision: The written code handled so many edge cases that if we were to rewrite it, even converting from objc to swift could ignore some edge cases.

I'm all for progress and modern ideas in a programming language, just don't break my old code!

Oh yeah, let me increase my compile times, the size of my SDK, add complications for my publishers, see zero performance benefit, build a ton of scaffolding code, add yearly tech debt until Swift is actually a mature stable language. Terrible idea!

It might be the gold standard some day, but for now it's just a kid compared to ObjC, and everything that comes with being a C based language. If you're learning to make apps, by all means, you should learn Swift, but it will be quite a long time before ObjC is dead and gone, so be prepared to learn both young padawan.

Not to mention, the hype train/bandwagon is really muddying the waters. It's probably a bad idea to take advice on how performant/powerful Swift is from a Zealot, or someone that's betting everything on it.

Instead we got Swift, which ironically, given its uptake by external devs, I think was aimed at complaints from internal Apple users. Internal users at Apple were frustrated by how easy it was for external devs to introspect and modify private ObjC framework code. They also wanted performance features like value types and method inlining.

I don’t think many external app devs cared about those things, or to the extent they did C++ was an attractive option because a stable ABI doesn’t really matter internal to application code.

I continue to use ObjC for Mac and iOS dev because it’s a much simpler language than Swift, the system APIs I interact with are still implemented in ObjC, and C++ interop is easier via ObjC++. I suppose the day will come where I need something that is only accessible from Swift, and I’ll write Swift then, but for now Swift doesn’t solve any problems that I have.

Starting with Swift 3 they claim to be source-stable which is why I've dared embrace it wholeheartedly now.

I'd much rather have breaking changes than having to constantly deal with dangling pointers and excessively verbose syntax.

Like Swift is not a perfect language and Apple's developer docs lack useful examples a lot of times, but Objective-C has to be the least approachable language in all of app development.