1) If some developers still prefer to develop in Obj-C, good for them. Of course Obj-C still has the broadest support, Swift is still in the process of taking it's training wheels off.

2) Why should Apple want to replace any of their Obj-C code? If it's good code and works well and a lot of other code depends on it, replacing it just for the sake of it would be pointless.

Partly all this depends on what you consider to be long term. Swift is coming to 3 years old. To my mind 5 years hence is the immediate future. Long term is like 20 years plus.

2) code rot. As new feature development is started, if all the Devs are more comfortable with Swift, it is practical that it should be done in Swift. The obj-c libraries will languish. This is just a statement that if Swift becomes the default language, then Apple should only build new features in Swift. You're correct that code doesn't need to be replaced... if it ain't broke don't fix it, though in my experience eventually someone will find a way to break it, and it's at that point that someone ideally replaces it.

What I'm arguing against is not the idea that new code or new versions of things shouldn't be in Swift. Maybe they should, maybe they would be better in Obj-C on a case by case basis. I'm arguing against the idea that all the existing Obj-C code is an embarrassing legacy that must be purged as a matter of urgency or else we should all start panicking about it.

Heck, large scads of the OS and the application services frameworks are written in plain old C - HealthKit is plain C. Long may that continue. Same for Obj-C.

https://devforums.apple.com/message/986257#986257

"13 of the security issues fixed in 10.9.4 could have been prevented or mitigated by Swift (9 buffer overruns, 2 int under/overflows, 2 null derefs). That alone makes it worth it from my point of view.

As for performance, that's a work in progress but is improving rapidly; Swift is already faster than ObjC in some cases."