At WWDC 2016 Apple announced that Xcode 8, due in the fall but available to developers now as a beta release, will officially support third party extensions.
This is a big deal because although Xcode has offered a plugin architecture for some time the lack of official support meant that the many useful plugins developed by the community – which can add anything from simple editor keyboard shortcuts to completely new features to the IDE – were difficult to maintain and frequently broke, usually when a new version of Xcode was released.
Now Apple is proposing to allow extensions to be signed and even distributed via the App Store, ensuring that they can run as first class citizens on our machines. Running in a separate process to the IDE itself, they are free to work their magic and improve our productivity without any risk to security.
In my opinion, Xcode lags behind other prominent IDEs such as those from Microsoft and Jetbrains when it comes to features that make development quick and easy for the developers who live in them every day. There are some plugins which over the years have saved me countless hours of effort; so much so that I often wonder what Apple is thinking by not bringing them into Xcode itself, such is the impact they have on my work.
So let’s honour our clickbait headline: here are the six Xcode plugins we can’t live without, and hope will now go on to be made available as extensions for Xcode 8:
NCSimulatorPlugin
While there’s no substitute for developing on a real Apple device, it’s often much quicker to test new work in the simulator where crucial things like the filesystem are only a few clicks away. Unfortunately there’s very little integration between Xcode and the Simulator – to know where the Simulator’s data resides on disk we’re reduced to logging paths to the console or inspecting variables through breakpoints.
With NCSimulatorPlugin this pain goes away, as it provides easy navigation from the Xcode menu bar to the data directories of any running simulators. In the last few months we’ve been doing a lot with the filesystem as we’ve been developing image and attachment sync features, and without the ability to quickly see what our app has doing to the filesystem we’ve have found the whole experience much more tedious
If I had to pick one plugin which should be built into Xcode by default, this would be it. Irreplaceable.
XQuit
I’ve lost count of the number of times I’ve hit CMD-W to close a tab, but accidentally hit CMD-Q instead and closed Xcode altogether, shattering my flow – I usually sigh and end up going to make a coffee.
XQuit has kept my productivity high and my caffeine levels low by forcing Xcode to show a confirmation dialog before quitting. I can now close tabs with reckless abandon, like the hedonistic coder I am.
deriveddata-exterminator
Anyone working with Xcode for long enough will have come across seemingly explicable error messages that drives us to Google for answers, where we inevitably find a post on Stack Overflow that recommends wiping the ‘Derived Data’ folder, after which things return almost magically to normal. It appears that sometimes the cached data that Xcode stores regarding a project becomes confused or corrupt, and nothing short of nuking the contents of the containing folder will return the project to a working state.
Xcode does support wiping these folders through its project navigator, however when needing to do this for the umpteenth time it’s all the more frustrating for having to break away from the editor to find your project in a completely separate view. The deriveddata-exterminator plugin adds a handy button to the Xcode toolbar so this action now takes the minimum amount of time, and as a bonus it can also wipe the Derived Data folders for all our projects, not just the current one, which can free up quite a bit of space on disk.
Caching things is hard, and ideally this plugin shouldn’t even be necessary, but in the meantime it makes dealing with Derived Data just a little more tolerable.
ClangFormat-Xcode
If you’re fussy about the way your code looks – and if you have any sort of respect for your codebase you will be – this plugin is crucial. It hooks into the Clang front-end complier, applying a style configuration to your code to ensure its formatting conforms to the chosen standard. The standard itself can either be one of a few well known ones (LLVM, Google, Mozilla) or a custom one, defined in a `.clang-format` file in your project.
When multiple developers are working on a project this plugin is so useful for maintaining a consistent style across the codebase.
Auto-Importer-for-Xcode
One of the most frustrating things about being a “responsible” Objective-C developer and following the “one responsibility per class” rule is that you end up with a lot of classes that then need to be imported into each file that uses them via a header include. Xcode isn’t always up-to-date on its file indexing either, so often I end up typing each one out by hand, jumping up and down the file I’m working on like a frog with a pogo stick – it’s ungainly and overcomplicated.
The Auto-Importer-for-Xcode plugin comes to the rescue by allowing us to correct missing import statements either by selecting the name of the missing class/protocol/category in the source, or invoking a keyboard shortcut to launch a chooser interface.
AMMethod2Implement
Similar to the aforementioned auto-importer plugin, this plugin makes me happy by reducing the amout of code I need to write myself. After defining a set of method interfaces in a class’ header (‘.h’) file, it seems crazy to me that I then need to go into the implementation (‘.m’) file and resolve each missing method individually. Code completion makes this slightly quicker, but it’d be nice to select a bunch of methods and have Xcode add counterparts for each to the implemention file.
And guess what? That’s exactly what AMMethod2Implement does.
There is some bad news though: at the moment Xcode 8 will limit extensions to being able to access only the source code that’s available in the editor. So many of the plugins mentioned above, like NCSimulatorPlugin and XQuit, simply aren’t possible to implement within the current framework. Apple has indicated that they’ll consider adding more extension points if there is demand for them, so I’ll be submitting bug reports to that effect – if there are any plugins that you rely on that fall into this category, I’d urge you to do the same.
Did we miss any plugins that you think should be on this list? Let us know!
