Developer Documentation

From Status Wiki
This is the approved revision of this page, as well as being the most recent.
Jump to: navigation, search

Getting Started

In this page, you will learn what the two main languages used in Status are, how to learn them, & finally how to find tasks to work on.

Status is largely written in two languages: ClojureScript & Golang and builds on React Native for UI. I'll talk about the rationale behind these design decisions and link to offsite resources on learning each of these technologies.

React Native

Status has always aspired to have a single, unified codebase for multi-platform development. This is not so easy to achieve, as many of the non-web-based solutions out there allow you to have a semi-single codebase, but you find yourself creating a lot of separate logic for handling user interfaces on each platform - Status is 80% frontend code and this presents a problem. We tried Xamarin & Java (EthereumJ was the first implementation we got running on Android & iOS - via RoboVM), and we quickly discovered this problem.

Mobile apps built on web-based technologies, such as those done in Cordova, are great for short-term projects or mvp, but you will quickly run into performance issues on resource-limited devices and may need to rewrite your app. In our tests displaying webView DApps in a chat history with iframes and all the other bells and whistles we wanted turned out to be a futile effort.

That limited our options to choosing between NativeScript & React Native. We chose React Native because it is more mature and is being used in production for popular apps like Facebook, Instagram, AirBnB, Baidu & Discord. This gave us the impression that this framework was here to stay with many Fortune 500 companies invested in its continuance.

At this point all we had to do is merge Material & iOS design into our unique look-and-feel so that we could minimize the amount of Android & iOS specific code. Our amazing designer Andrei Mironov elegantly solved the rest of that puzzle.

React Native Learning Resources

If you would like to start learning React Native, check out these resources:

you might want to continue reading and learn more about re-natal, re-frame & reagent.


Re-natal is an invaluable tool to that automates the setup of your re-frame React Native for Android & iOS, it includes figwheel for easy development.


Re-frame is simple but expressive library for writing Single Page Applications in ClojureScript, using Reagent. It is a functional framework for reactive 'MVC-style' applications. To learn more:


Reagent provides a minimalistic interface between ClojureScript and React. It allows you to define efficient React components using nothing but plain ClojureScript functions and data, that describe your UI using a Hiccup-like syntax. The goal of Reagent is to make it possible to define arbitrarily complex UIs using just a couple of basic concepts, and to be fast enough by default that you rarely have to care about performance.


“Lisp is worth learning for the profound enlightenment experience you will have when you finally get it; that experience will make you a better programmer for the rest of your days, even if you never actually use Lisp itself a lot.” — Eric Raymond. To read more quotes on Lisp read Lisp, made with secret alien technology.

Repository Overview

The Status application is divided into 2 core repositories;

  • status-react - our main react native application written in Clojurescript, Java & Objective C
  • status-go - represents our binding to the go-ethereum lib and exposes methods to status-react to Java / Objective


Please make sure your contributions adhere to our coding guidelines:

  • Code must be idiomatic Clojure, please refer to the style guidelines (i.e. use lein eastwood & lein kibit).
  • Code must be documented.
  • Pull requests need to be based on and opened against the develop branch.
  • Commit messages should be prefixed with the root namespace(s) under status-im that they modify.
    • e.g. "contacts, ios: add contact stylistic changes"


Only Github is used to track issues. (Please include the commit and branch when reporting an issue.) is used to overview issues in multiple repositories.

Code formatting

Please run lein eastwood and lein kibit before contributing.

Branch naming

Branch format must be under CATEGORY/PLAIN-TEXT-#ISSUE_NUMBER acceptable branches are;

feature/discover or bug/broken-form-#113

The following categories are:

  • feature/ for implementation of features
  • bug/ for fixing bugs
  • tests/ for unit/UI tests
  • experiment/ for non-features
  • wip/ for longer lived branches
  • junk/ for irrelevant/soon-to-be-deleted branches

Pull Requests

Pull Requests (PRs) should by default use the develop branch as a base. Tags are used for releases. Add new PRs to the project. If a PR is ready for review, put it in REVIEW column (default when adding to project). If a PR is WIP, put it in CONTRIBUTOR column. Each PR must be rebased against develop and squashed into a single commit after all reviewers approve PR.

Code Review

Each PR should have at least 2 approvals from core contributors. Reviewer could request changes during code review. In such case, make additional commits where each commit delivers the change that you and reviewer agreed upon. Please do not squash commits and push force before review is finished. If a PR has undergone review and requires changes from author, move it back to CONTRIBUTOR column. If it is approved, move it to TEST column.

Commit messages

Commit message should help understand why (and what) has been fixed. Add a summary as first line if the message is too long. When fixing bugs the first line should be prefixed with [FIX #123].

As a good practice message starts with capitalized verb in the imperative mood.


Core contributors merge code with code signing. PRs that are ready to be merged should be squashed, passed CI, tested (if applicable) and in MERGE column.
git fetch origin
git reset --hard origin/develop
./scripts/ NUMBER e.g. ./scripts/ 3356
If you have errors like
remote: error: GH006: Protected branch update failed for refs/heads/develop.

remote: error: At least one approved review is required by reviewers with write access.
you can merge it manually
checkout branch; git rebase -i origin/develop; git push -f; git checkout develop; git merge --ff-only branch; git push

or ask contributor to "Allow edits from maintainers."


Fork the repository on Github's web UI.

Clone your fork. Add the upstream as a remote.

$ git clone [email protected]:<you>/status-react.git
$ git remote add upstream [email protected]:status-im/status-react.git

Now you have two remotes: origin pointing to your fork and upstream pointing to the shared repo.

$ git fetch --all

Then isolate the bug/feature work you will do into a topic branch

$ git checkout -b bug/missing-contact-#116 upstream/develop

Keep your branch fresh against upstream

$ git fetch upstream
$ git rebase upstream/develop

If multiple people are working on the same feature branch don't forget to also

$ git rebase upstream bug/missing-contact-#116

When you are ready to make your pull request

$ git push origin

After PR has been reviewed do a final cleanup and squash your commit

$ git rebase -i upstream/develop
$ git push -f origin

See also