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

swift-llvm and swift-clang

When Apple released the apple/swift repository on GitHub, they also released apple/swift-llvm and apple/swift-clang. Why?


Apple’s Swift fork of LLVM has only three sets of minor changes:

  1. Convenience wrappers for LLVM bitcode. These are used by Swift’s fork of Clang, as part of the implementation of APINotes (more on those below).
  2. A specialization of the LLVM abstract data type llvm::DenseMapInfo. This allows std::tuple<T...> to be used as a key in an llvm::DenseMap. Some helpers to hash tuple values have also been added. Again, this is used by Swift’s fork of Clang in its implementation of APINotes, to store tuples of information about Objective-C properties.
  3. Slight adjustments to ensure a mangled name is used as a “linkage name” for debug info. (I know very little about debug info, but I read that certain tools don’t work if the “linkage name” isn’t correct.)

All of these

Continue reading →

Paying Down Technical Knowledge Debt

Programmers frequently encourage one another to “pay down technical debt”: spend a little time cleaning up the mess your team made when they implemented a new feature. That way, it’ll be easier to implement the next feature – you won’t be bogged down by cruft left behind.

An example of technical knowledge debt in the wild.

Recently I’ve been accruing a lot of what I call “technical knowledge debt”. Here are some examples from my open source work on the Swift compiler:

  • “On Linux, Swift object files are linked in between ‘begin’ and 'end’ object files: /usr/bin/ld swift_begin.o SourceOne.o SourceTwo.o swift_end.o. These begin and end object files aren’t used on Darwin. I don’t know why this is. When modifying the Swift build system for Android, I sometimes see errors if I make a change that doesn’t put these begin and end objects where they’re supposed to be. But I’m focused on getting Swift on Android to work, so I’ll look into what

Continue reading →

Swift on Android, Part Two: What Now?

I wrote about the technical details of porting the Swift runtime to Android in my last post. This post discusses the implications for mobile developers.

 Should you write iOS/Android cross-platform code in Swift?

Writing cross-platform Swift source code that can run on both iOS and Android is technically possible, but practically very inconvenient.

The only successful deployment that I know of is described by Geordie Jay in his marvelous series of blog posts. His team successfully overcame esoteric linker errors…

As we soon found out, the Android linker ignores LD_LIBRARY_PATH when loading libraries from within Java via System.loadLibrary().

…and developed a method to interface with the JNI from Swift:

We needed a bit more control though: to truly interface with our web app […] we still had to use the JNI to pass around some strings and arrays to and from Java.

Some teams are

Continue reading →

Porting the Swift Runtime to Android, Part One: The How

In June 2016 something I worked on was featured in Apple's WWDC State of the Union.

Shortly after Swift was open-sourced, Zhuowei Zhang sent an email to the swift-dev mailing list, introducing his fork of Swift, which could produce code that ran on Android devices. I worked on his fork, to adapt the code so that it could be merged into the Apple Swift repository. In February 2016 I sent a pull request, entitled simply “Port to Android”. It was merged in April.

 What does it mean to “port” the Swift runtime to Android?

The Swift compiler is a program that simply translates Swift source code into an intermediate representation, called LLVM IR. LLVM is a program that translates LLVM IR into assembly code. Assembly code is a slightly more readable version of the 0’s and 1’s that are used to represent machine instructions. LLVM can generate assembly for many different platforms, including Android, PS4, and Windows.

LLVM can convert IR into executable code that runs on many different platforms, including Android.

Swift already generates LLVM IR, and LLVM can already

Continue reading →

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 →

Subscribe to ⌘U

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