by Brian Gesiak

Swift compiler and swift-corelibs-xctest committer. Creator of Quick, the Swift (and Objective-C) testing framework. Former Japanese literature translator.

Read this first

Contributing to Nuclide’s Swift Integration: Why and How

Nuclide <3 Swift

I was surprised by the amount of interest in my hackathon project to add Swift support to Nuclide. I’d love it if you helped me complete my vision for the project.

  • Why are people interested in nuclide-swift?
  • Why contribute?
  • What are good resources for getting started with Nuclide package development?
  • How does nuclide-swift work?
  • What’s left to do?

 Why are people interested in nuclide-swift?

  • There are only a few choices when it comes to Swift editors. I imagine most people use Xcode, and some use AppCode. In time, Nuclide could be another option.
  • Nuclide is open-source. You can see exactly how each feature is implemented. This encourages collaboration. For example, I was thrilled to see Ryan Lovelett release a VS Code extension inspired by Nuclide.
  • By using Swift tooling, like SourceKit, Nuclide provides useful feedback to the Swift team. I’m excited to work on testing framework

Continue reading →

My Hackathon Camp Project: Building a Swift IDE

Hackathons are the longest running tradition in Facebook’s engineering culture. This hackathon featured a “summer camp” theme and spanned three days. I decided to use that time to build an IDE for Swift.

Three days isn’t enough time to build an IDE application from scratch. Instead, I built a relatively small package that integrated into Nuclide, which itself is a package for the Atom editor. I call the package nuclide-swift.

Atom and Nuclide are “hackable”: they expose APIs (called “services”) that allow plugins (called “packages”) to interact with every single part of the editor. In fact, nearly every feature of Atom – its file tree sidebar, its open file buffer, its panes – is implemented as a package.

Scroll down for some demos of what I was able to accomplish in three days of Nuclide development. Scroll further for things to come, and for details on when and how you’ll be able to

Continue reading →

Using Nuclide as an IDE for Swift Compiler Development

Nuclide in action

I’ve started using Nuclide when working on the Swift compiler source code. Why?

  • Nuclide provides type-aware autocompletion. That means that, as can be seen in the GIF above, the only autocompletion candidates for StaticSpellingKind:: are members of that enum.
  • Nuclide also displays the documentation for its autocompletion candidates inline.
  • Hovering over a symbol in Nuclide displays its documentation.
  • Nuclide can jump to any symbol’s declaration. And on OS X, this is even mapped to Cmd-Click, just like Xcode.
  • Nuclide integrates with lldb. I can set breakpoints on a particular line, and I can print debugger values from within Nuclide.

Nuclide's lldb intergration

  • Nuclide works in both of my development environments: OS X and Linux.
  • Nuclide supports syntax highlighting and diagnostics for Python, and I can download plugins for CMake and Swift support, too.
  • Nuclide displays C++ and Python errors inline. It

Continue reading →

Compiling Swift: What Hardware is Best?

I have two machines on my desk at work: a Mac Pro (Late 2013) and a MacBook Pro (Retina, 15-inch, Mid 2014). Let’s see how quickly they each compile Swift from source.

I checked out the swift-DEVELOPMENT-SNAPSHOT-2016-06-06-a branch of each of Apple’s Swift repositories, then performed a clean build, using the following commands:

$ cd apple/swift
$ rm -rf ../build
$ time utils/build-script -R

Here’s the average of five builds on each of my machines, plus some readers have contributed, arranged from slowest to fastest:

Model Processor Memory User System Real
MacBook (12-Inch, Early 2016) 1.2GHz 2-Core Intel Core m5 8 GB 1866 MHz LPDDR3 SDRAM 12992.81s 436.32s 59:56.48
MacBook Pro (Retina, 15-inch, Mid 2014) 2.8 GHz 4-Core Intel Core i7 16GB 1600 MHz DDR3 8885.34s 471.48s 22:49.55
Mac Pro (Late 2013) 3.5 GHz 6-Core Intel Xeon E5 32 GB 1866 MHz DDR3 ECC 9623.72s 593.88s 18:06.0

Continue reading →


最近XCTestを担当しているアップル社員と話す機会によく恵まれています。その方々が言うには、Xcode/XCTestの担当部署の任務は「テストを書く習慣を広め、App Storeにあるアプリの品質向上に貢献する」そうです。



チュートリアルは英語で書かれていますが、今年はそのチュートリアルを日本語に訳したいと考えています。 そしてそのチュートリアルは、@takecianのおかげで全部日本語訳できました。

もしテストにご興味があったら、チュートリアルを読んでみてはいかがでしょう?OS X・iOSアプリのテストを書く経験が全くない方でもお役に立つと思います。

Continue reading →

A Humble Proposal for swift-corelibs-xctest

EDIT (March 8, 2016): I’ve since reconsidered some of the APIs I proposed in this post from last December. My number one priority right now is achieving feature parity with Apple’s XCTest, but once that’s accomplished I still think swift-corelibs-xctest development can help shape the future of testing on Apple’s platform.

  1. Have XCTMain take a list of test closure/run option tuples. XCTestCase is merely an API compatibility layer for people used to Apple’s XCTest.
  2. XCTMain also takes a configuration object as a parameter. Based on the configuration, it runs the test closures in parallel, in separate processes, and more. Alternatively, it can be configured to run the tests sequentially, as Apple’s XCTest does. Sub-processes for tests would make it easy to implement performance testing, Swift assert tests, parameterized tests, add a timeout on each test, and more.
  3. The configuration object

Continue reading →


Xcode 7 includes a project setting named “Apple LLVM 7.0 - Warnings - All languages > Incorrect Uses of Nullable Values”, or CLANG_WARN_NULLABLE_TO_NONNULL_CONVERSION.

You can pass it as a compiler flag using -Wnullable-to-nonnull-conversion.

 What does it do?

To demonstrate, consider the following command-line app:

#import <Foundation/Foundation.h>

void welcomeToClowntown(NSString *_Nonnull greeting) {
  NSLog(@"%@, welcome to clowntown!", greeting);

int main(int argc, const char * argv[]) {
  // Warning: Null passed to a callee that requires 
  //          a non-null argument
  return 0;

Notice that we’re passing a nil literal to our function welcomeToClowntown(), even though it takes a parameter of type NSString *_Nonnull. This always emits a warning, regardless of whether CLANG_WARN_NULLABLE_TO_NONNULL_CONVERSION is enabled.

But what about

Continue reading →

SenTestingKit: How Does it Even?

Have you ever wondered what used to happen when you hit ⌘U to run your unit tests in Xcode 4.6 and prior? Here’s a step-by-step sequence of events detailing how tests are loaded and run using SenTestingKit.

As I explain in Probing SenTestingKit, XCTest (née SenTestingKit) has changed surprisingly little since it was first adopted by Apple in 2005. Although what follows is based on the 2005 source code to SenTestingKit, I assume Xcode 7 and XCTest still operate very similarly. I’ll test that assumption in future blog posts.

 1. Xcode invokes a command-line tool called otest to run your tests.

In XCTest, this tool has been renamed to xctest. You can run it yourself from the command line:

$ /Applications/Xcode.app/Contents/Developer/usr/bin/xctest

otest is a simple program that loads a bundle at a given path.

$ xctest /path/to/bundle

The loaded bundle is assumed to have a class

Continue reading →

Probing SenTestingKit

Using class-dump and a short script I wrote, I dumped the SenTesingKit and XCTest Mach-O files included in every version of Xcode since Xcode 3.

Even years after SenTestingKit was included in Xcode, its API barely changed. For years the API was nearly identical to the last open-source release by Sen:te.

In fact, based on the class-dump headers, the implementation didn’t change very much either. The first major change doesn’t occur until the introduction of XCTest in Xcode 5.

It stands to reason, then, that a good understanding of how SenTestingKit used to work will help us demystify how XCTest works now.

I’ll write a summary of the entire system once I’ve had a chance to look at the command-line interface, otest. In the meantime, below are my debugging notes for SenTestingKit v41.

What follows is pretty much stream of consciousness, so don’t expect much.

 Diving In: Finding a

Continue reading →

Diffing APIs with class-dump

In order to stay abreast on the latest changes to XCTest, I run class-dump on it whenever I download a new version of Xcode.

You can download the latest version and try it out yourself. From the command line:

$ class-dump -H /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/Library/Frameworks/XCTest.framework

This creates a list of headers found in the framework:

// ...and so on.

This allows me to see what’s changed between two versions of XCTest on a per-file basis. It’s fun to see how XCTest changed between Xcode 7.0 and Xcode 7.1b2, for example.

Because the changes are split up into files, I can clearly see that there’s a brand new interface named XCUIRecorder_tvOS.

Try it out on a framework you’re interested in!

Continue reading →

Subscribe to ⌘U

Don’t worry; we hate spam with a passion.
You can unsubscribe with one click.