Refactorator: Xcode Plugin That Refactors Swift | Hacker News Reader

Refactorator: Xcode Plugin That Refactors Swift

github.com

43 pointsingve19 comments

Very cool. But the fact that a (fairly complex!) third party plugin was required to do things like rename constants is tragic. Where is the first-party support for basic edits in Xcode, two years after the release of the language?

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.

An Xcode tip which I didn't discover until recently was that if you hover over a variable for a moment, a small down arrow will appear next to it. If you click on that arrow, you'll get a menu which includes "Edit all in scope". This provides very basic variable renaming.

Without using the mouse and hovering you can press Cmd-Ctrl-E.

Be careful with that, there is a bug in the editor itself that somehow inserts your new name between the letters of the word (variable) you're changing. Not sure if it's the same bug, but it's been there pre-Swift.

lblName -> lbllblUserNameName

The lack of these refactorings is the main reason I bought AppCode. It comes with it's own set of problems, so I find myself using two IDEs a lot of the time. Does this plugin at least support Extract Method, or is it just Rename?

I'm curious, being a fan of keeping a copy of AppCode just for refactorings: What problems?

Let me preface by saying I like AppCode a lot more than XCode; given the choice I always work on AppCode.

But, my complaints are:

-Much slower startup time

-All in all, it feels less responsive than XCode when my computer is struggling(I do cross-platform development with Android, so on occasion I'm running Xcode+AppCode+Android Studio at once)

-For projects with multiple targets, changing a file from one target to another does not have a good UX. I work in projects with several targets, and I have to do this more than most developers, and it always takes me to XCode

-Choosing and editing launch configurations has a better UX in XCode

-Editing plist files, project configurations and Storyboards is significantly easier in XCode

-AppCode will occasionally show spurious errors and warnings. It warns me any time I call [UIImageNamed:] with an image in my asset catalog, for example, saying the resource does not exist.

-The update cycle lags behind XCode's by necessity.

This summary is useful for me as I'm planning to get my personal license soon.

Reply on news.ycombinator.com