Beautiful. No more manually arrow-key-ing around to get rid of those.
Next, let's look at a common feature of many IDEs and text editors: the ability to "jump" the cursor multiple lines up or down. Xcode can't really do that... until now. Thanks to Jump, we're given a few new menu items in our Editor menu to move the cursor up or down by 2 or 5 lines. Neat.
Pro Tip: We can use the Key Bindings tab of Xcode'sPreferences window to customize the keyboard shortcuts for each of these movement commands (or any other commands).
This extension allows us to select some text, and then insert a new function definition into our code, complete with documentation comment, and placeholders we can press tab to jump between.
This allows us to employ a workflow of:
1.) Call a function that doesn't yet exist when writing some code as a sort of "placeholder".
2.) When we're done with that chunk of work, select the name portion of the function call and press a keyboard shortcut to "generate" the function and insert it into our file.
Integrating our apps with HTTP APIs often involves a fair amount of "busy work". Writing models to match API responses, manually iterating each field in a JSON object, and typing each in as a Swift property can be a bummer. Today we'll check out a great new tool from Josh Smith called json2swift that can help us here. It can generate Swift model code from a JSON object. Let's give it a try.
After we've installed json2swift, we can run it like this:
This will create a new file called Spaceship.swift in the same directory as our .json.
This means if our Spaceship.json file looked like this:
The resulting json2swift-generated Swift model would look like this:
First up, Equatables. We can use XcodeEquatableGenerator from Serg Dort to quickly generate the long list of property comparisons often required when adopting the Equatable protocol in our Swift Structs or Classes:
Last but definitely not least, is XcodeWay by Khoa Pham. This one is a bit different in that it doesn't modify or generate any code, but rather lets us quickly open a bunch of commonly used directories, by adding them to our Editor Menu:
Nice! No more hunting around in Finder or Terminal for these.
Xcode Source Editor Extensions are really starting to come into their own. Today we'll look at one that solves an age-old annoyance for Xcode users: Importing.
We've all been there. We're deep down in the depths of file, and we realize we need to import a module. We dutifully scroll all the way up, type the import, then scroll back down trying to find our place, and get back in "the zone". Yuck.
The Swift language is always evolving. Bugs are being fixed, new proposals are implemented, etc. It'd be great if we could try out these features out as they're being implemented, without having to wait for official releases.
Today we'll take a look at how to download, install, and try out the latest Swift Toolchain in Xcode. Let's get started!
We'll begin by heading to https://swift.org/download/ and looking for the "Snapshots" section. Here we can also find many other preview releases, etc.
Click "Xcode" to download an installer:
We'll run open the installer, and complete its steps.
We can now open Xcode and select our new Toolchain.
We can also manage Toolchains in Xcode's preferences:
With our new Toolchain selected, all builds will use it, neat!
Getting involved with Swift's development is a great way to stay informed on where things are headed. We'll look at getting even more involved in future Bites!
WWDC brought us a whirlwind of changes all over Apple's platforms. One interesting announcement was Xcode Source Editor Extensions. These allow us to add commands to Xcode that can work with the contents of the code we're working on. Yes, Apple also announced that Xcode won't load plugins (like Alcatraz, etc.) anymore. Bummer.
Today we'll try to shake off our feels about plugins going away by making our first Source Editor Extension, let's do it!
We're going to make a super-simple Extension that lets us easily "sign" our code comments. Like this:
// - @jakemarsh
We'll start by creating a new macOS app. Then we'll add a new target to it, and choose Xcode Source Editor Extension.
Xcode gives us a nice template of files to start with. We can head into SourceEditorCommand.swift to implement our command.
We start by looking at the invocation'sselection and guard'ing to make sure there's a valid insertion point for us to append to, then create a new comment using the handy NSUserName() function in macOS.
Finally, we use the provided XCSourceEditorCommandInvocation one more time to insert the new comment text into the buffer. We call the completionHandler with a nil to let Xcode know we've completed our work without any errors, and we're done!
We can customize the name of our command in our Info.plist, like this:
Now, how are we going to test this thing out? Well, Xcode has some nice support built in for debugging these, but first we'll have to endure a little pain to get things working (at least during this first beta, later Xcode 8 releases will hopefully not need these steps).
We'll only need this while running OS X 10.11, macOS 10.12 users can skip this step:
We'll need to run sudo /usr/libexec/xpccachectl in Terminal, then reboot our Mac.
Once it's back up, we can open Xcode 8 again, and Build & Run our Extension. We'll be asked to choose which app we'd like to run it in. We'll choose Xcode 8 (be careful not to choose an older Xcode version as the icons are easy to miss).
Another instance of Xcode 8 will launch in our dock and… Boom! Xcode's dark heart is revealed!
Just kidding, Xcode is displaying itself this way to help us differentiate between the one that we're debugging, and the "real" one.
We can head to the Editor menu to test out our new command. That's not all though, we can go back to the other Xcode instance and set breakpoints, inspect variables, etc. Neat!
Plugins may be gone, but Source Editor Extensions still offer a ton of interesting possibilities. Looking for inspiration? Here'safewonGithub already.
Plugins are a great way for us to extend Xcode, adding functionality that Apple didn't ship with it. We've covered Xcode plugins a bit here in the past, notably in Bite #147, where we learned about using Alcatraz to install plugins. Today we'll look at a new plugin called BuildTimeAnalyzer from Robert Gummesson. It can help uncover why are code is compiling slowly. Let's dive in.
We'll start by completing the steps in Bite #147 to install Alcatraz. (If we're going to be installing and trying out plugins Alcatraz is a good way to organize and manage everything).
Once installed, we'll open the Alcatraz Package Manager by going to Window > Package Manager.
We can search for "BuildTimeAnalyzer" in the search field to find the plugin and install it. Once installed, we'll restart Xcode and open our project.
We can open the analyzer window by selecting View > Build Time Analyzer from Xcode's menu.
Next, we'll need to add some compiler flags.
(Remember to add these to any other targets your app may depend to see compile times for those too).
We'll add -Xfrontend and -debug-time-function-bodies to the "Other Swift Flags" in our app's target's build settings.
After that, one last clean and build and we should start to see a list of how long each bit of our code is taking to compile. Neat!
We can click on each result to jump straight to the line of code that's causing the slow down. The results are often surprising!
For example: Adding Collection types together seems to bring the Swift compiler to a slow crawl.