Hello there!

I’ve been using Buck to build the project I work on for over six months now (ballpark over here). I’ve gotten a bit more used to it, have tested a few stuff, still cry when I have to deal with build rules, but it’s all about the learning, eh?!

Some say the best way to assimilate an information is to pass if forward. Probably because you’ll read a lot about it and think of different ways you can explain the same thing.

So here we go! Let’s talk about the basics of Buck today. Just a disclaimer: I might not use the most correct terms and even commit some failures throughout the way, just keep in mind that I’m also continuously learning as I produce the content.

First and foremost, what is Buck? Out in the woods, it is a sympathetic male deer, but in the technology sphere it is described as:

“a build system developed and used by Facebook.”

Basically, it is an organized set of files describing the configurations of a project, that will be used to build and run an application. And why use it, you may ask? On big teams and projects, as well as in monorepos, it can facilitate the process of creating, building, duplicating, configuring dependencies, and so on.

Check buck’s main page for more details on benefits

The first thing you need to understand is that the build tool is completely based on paths to folders, build files, and build rules. So the order of the files and how they communicate is directly related to how the project will be built. On to the definitions:

Build Rules

Build rules are basically functions. They will take a given input and produce an output. You’ll use them to create an apple library, for example.

Build Files

Build files are files that contains build rules. Let’s say your module has sources, tests and assets. The build file will declare all the build rules necessary to create each piece for the module.

As a standard, build files are named BUCK.

Build Target

Build targets are like paths to identify build rules. They will be used within buck commands.

Final definitions

With that said, we can say that a buck package is represented by a directory with a build file and its source files. A cell is a directory tree with one or multiple buck packages. And finally, a buck project is defined by a file .buckconfig where Buck is actually invoked.

Check the diagram from the key concepts page.

Phew! That’s a lot to take in, right?! Don’t forget we are just beginning.


Let’s stop this introduction here, go to the Buck official pages linked below, re-read the definitions, absorb the information and we will come back later to talk about further subjects, such as:

  • building buck locally and the “get started tutorial”
  • main iOS build rules
  • Airbnb’s buck sample and their buck rule macros