It is annoying, but they had far bigger problems to fix from release until now. When Swift was released SourceKit would crash all the time. The compiler would crash when code wasn't correct. The error messages were terrible. The language had was missing essential parts. Apple had to do a lot of fixing to get to where we are now. The things they have fixed has been a lot more important to get right than the refactoring support. Crash free IDE, good error messages, stable compiler, user friendly handling of optional types has been far more important IMHO. But now the language is looking good, so I think starting with Swift 3.0 I think we will start to see xCode getting fixed.

It might also be intentional to give a marked to AppCode and others. xCode has always been pretty slim in the offerings when it comes to refactoring. But xCode contains a lot more tools than what you get in e.g. AppCode. There is considerably more effort going into creating good GUI designers, UI Automation tools, performance diagnostic tools, debugger, playground etc.

AppCode has a much smaller scope and can thus focus more on being a great tool for refactoring.

> When Swift was released SourceKit would crash all the time

it still does that if your code is sufficiently broken.

Def agree that AppCode belongs in any iOS dev's toolkit, exactly for this purpose (and some helpful others, e.g. code formatting, unit testing).

And I also agree with your assessment on language evolution - but to provide a fair counterpoint; Jetbrains' pet language, Kotlin, has evolved with the host IDE (Intellij) since inception; though the language changes, the IDE was mostly able to help you do smart things with whatever code you had at the time, not just migrate it between versions. I believe the comparison to be somewhat fair as with Apple - both entities develop both the language and the toolkit/IDE around them.

One of the really sad/annoying things here is the obvious misdirection: editing a swift file does not disable the Refactor context and submenu entries, so clicking on any one option will trigger that nasty message essentially saying "You tried to do something we actually know you shouldn't even be allowed to click on, but we'll just resort to telling you this feature is ObjC only".

I'm fine with the IDE displaying such messages temporarily when it's figuring out whether or not there is an actual super class implementation a method can be "pulled up" to or not, but not disabling those context menus after the context clearly has been established isn't exactly good UX in my opinion.

Swift will reach 2 years in the public in June 2016. There has only been 1 major release of Xcode after Swift was announced. Hopefully, we'll see something more then. Personally, I'd like to see an official Plugin system. Then we get everything. :-)

There have been two major Xcode releases since Swift was announced, 6 and 7.

Totally agreed on an official plugin system. There are a bunch of interesting unofficial ones out there, but I hesitate to even try them if I can't count on them to keep working.

> There have been two major Xcode releases since Swift was announced, 6 and 7.

That's overstating things, I think. Xcode 6 was the first version of Xcode with Swift in.

> Totally agreed on an official plugin system. There are a bunch of interesting unofficial ones out there, but I hesitate to even try them if I can't count on them to keep working.

I try and give up occasionally. It tends to make Xcode even more unstable than normal. I'm always wondering if Apple have a replacement they are working on. It doesn't seem like it's built in such a way that it can grow in a stable manner.

I forgot that Apple leaked the news to the entire Xcode team a year early and the team sat down and planned the Swift feature set for Xcode 6 </sarcasm>

Mike Ash, you should know better.

I'm not making a statement about what features should or should not be there, I'm just counting....

You are counting incorrectly. Xcode 6 and Swift were introduced at the same time. The point is that you can't count 6 because its feature set was already finalized once Swift was announced.

Anyway, I'm sure you understand Apple's process.

There's a way to edit all instances of a variable name in Xcode already. I haven't tried it with constants, though as I usually take time to think of the names for my constants so I don't have to rename.