# flow writes one UI codebase for HTML, iOS, Android and the desktop

> flow9 is a platform with its own strongly typed functional language, a self-hosting compiler written in that language, and a standard library that compiles the same source to HTML, iOS, Android, Windows, macOS and Linux. It suits teams that want one UI codebase with a Material Design toolkit across platforms, and its cost is a language and toolchain you have to adopt wholesale.

**area9innovation/flow9** — Platform for safe, easy and productive programming of complex, multi-platform apps with a modern user interface

- Repository: https://github.com/area9innovation/flow9
- Stars: 574 · Forks: 39
- Language: C
- License: NOASSERTION
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/area9innovation-flow9

## The platform is a language, a compiler and a standard library

The readme lists three parts, and the design depends on all three being present. The flow programming language is described as a safe, functional, strongly-typed language, and the flowc compiler is an incremental compiler for multiple targets, and the flow runtime and standard library provide a complete cross-platform library including mature UI components. That third part is where the difference lies from a general purpose language, since a runtime that ships UI components means the button, the list and the layout are part of the standard library rather than something you import from a widget toolkit per platform. The targets are listed as production quality, and they are HTML through JS, iOS, Android, and Windows, Mac and Linux. The claim in the language section is the same code compiles and runs on HTML5, iOS, Android, Windows, macOS and Linux, which is the property that makes the platform worth the adoption cost rather than a curiosity.

## A functional language with C syntax and subtypes

The Meet flow section describes the language in a way that tells you who it is for. flow is a simple, functional language in the ML family with C-family syntax, so the surface reads like the language most people already know while the semantics are ML, with strong typing, polymorphism and subtypes. The stated design intent is that it is designed to look like other languages and be easy to learn, and that it is minimalistic to reduce complexity and ease porting to new platforms. The minimalism is doing real work here, since every language feature is a cost that has to be paid again for each new backend. The safe part is what the type system buys, and for a UI framework that means the compiler can reject a whole class of mistakes before a device is involved. The library is written in flow itself with natives for each backend, and the UI toolkit is based on Functional Reactive Programming, which is a coherent choice for a language in that family and explains how a single code path can drive reactive UI state on six platforms.

## The compiler is written in the language it compiles

The tooling section contains the most unusual fact in the project. flowc is the current compiler and it is written in flow itself, and it can work as a compile server. The older compiler, flow, is written in haxe and lives in its own tools directory. The self-hosting detail is not a curiosity, it changes what incremental compilation means for a project of this size, because the compiler that has to start up before you can edit is the same code path that has to be fast. Around it sit the tools a development team would expect: a single-step debugger using the gdb protocol, a profiler covering time, instructions, memory and garbage collection, a JIT compiler for x64 with an interpreter for ARM and others, and the ability to compile to C++ and Java for performance-critical code, typically server side. So the same source can be a portable interpreted program on one platform and a native binary on another, which is how the platform reconciles one-codebase with per-platform performance work. Two small notes in the readme are worth taking seriously. On licensing, the flow compiler is licensed under the GNU General Public License version 2 or any later version, and the flow standard library is released under the MIT license, and for the licence of other components you are pointed at LICENSE.txt. A split like that is common in toolchains where the compiler is a separate work from the libraries, and it has a practical consequence, since a company with a policy against GPL in its build tooling cannot take the compiler without a review, while the standard library is not a problem. On the name, flow was started in 2010 and this predates the flow typechecker from Facebook, and the project elects to keep the name since it came first, is a full platform and the risk of confusion seems small, and notes that flow9 can also be used to refer to the language should the need arise. So the repository name flow9 is the disambiguated form of a language that predates the more famous one.

## Linux installs with one script, and it tells you what it does

The Linux install path is a script that does the work, and the details about how it behaves are what make it usable. On Linux you clone the repository and run the setup script.

```bash
	git clone https://github.com/area9innovation/flow9.git
	cd flow9
	./bin/setup-linux
```

It installs what your distribution needs, builds the C++ runner and runs a hello world to check that everything works. The distribution handling is worth noting, because it is where a setup script usually becomes unreproducible. The script knows pacman, apt and dnf, it prints every command before running it, and it asks before it uses sudo. The last two properties are the ones a reviewer cares about, since a script that installs packages with root privileges is exactly the kind of thing people are trained to distrust, and printing each command first plus prompting for sudo makes the run auditable. The documentation points at doc/linux.markdown for what the script does and how to do the same by hand, which is the escape hatch for a machine where a package install is not acceptable.

## Windows and macOS need Java 21, Python 3 and Git LFS

The manual path on Windows and macOS is a numbered list, and two of the requirements are sharp edges. You need Git LFS installed, and you need the 64 bit version of OpenJDK 21 or newer, with the readme noting that flowc will not start on anything older. You also need Python 3 on your path, and you add flow9/bin to your path so the compiler is callable. The final step compiles and runs the first program from the flow9 directory.

```bash
    c:/flow9> flowcpp demos/demos.flow
```

The Git LFS requirement has a specific failure mode, and the readme names it. If the clone does not work, make sure Git LFS is installed, and you have to re-clone the flow9 repository after installing Git LFS or use git lfs pull. In other words, a clone performed before LFS was present leaves large files as pointers, and the fix is to re-clone rather than to patch. The demos/demos.flow file is the program that gets compiled, and the readme points at it for reading the code. There is also a third option that avoids all of this, since on any platform you can use VS Code with Dev Containers and install nothing at all.

## Hello world in a language with a module system

The hello world in the readme is short and shows the shape of the language.

```
    import runtime;

    main() {
    	println("Hello world");
    }
```

The import of runtime is the module system in action, and the entry point is a function called main with a body that prints a string. What the example does not show is the part that matters for a UI framework, which is that the same source file can also be compiled to native code and that the standard library is written in the language itself with natives for each backend. The demos directory in the repository contains a demo program showing how the UI library can be used, and the sandbox folder contains the hello world. Between those two there is a working reference for the thing a new user actually wants to see, which is a window with something in it rather than a line of output.

## Material Design is the UI layer, and reactive programming is its model

The UI story is built on two external references, and the readme is specific about both. The first is an extensive UI toolkit based on Google Material Design guidelines, and the wiki carries a Material library page with the main UI building blocks, documented separately for the language and the platform. The second is that the toolkit is based on Functional Reactive Programming, which is what makes a single reactive codebase work across six backends. The platform claims pixel precision with high-design, responsive UI on all platforms with identical code, which is the strongest form of the promise, and the history section gives the timeline that makes it plausible rather than aspirational: the first program ran on Flash and HTML5 in August 2010, the first app was approved in the iOS store in November 2013, the first Android PlayStore app in April 2014, Flash was retired and completely migrated to HTML5 in November 2015, the Material guidelines were implemented in January 2016, x64 JIT was added in November 2016, and the self-hosted compiler arrived in May 2018.

## Where flow is the wrong choice

The first wrong case is a team that does not want to own a language. The flow toolchain includes a compiler written in flow, a PEG parser generator, a debugger, a profiler and a JIT, and a project that adopts it inherits the responsibility for a stack that is not maintained by a foundation or a hyperscaler. The second is a platform set that does not include the six targets. The value of a single codebase that compiles to HTML, iOS, Android, Windows, macOS and Linux comes from that list, and a project shipping only to the web is paying for a cross-platform toolchain it does not use. The third is a team whose components come from the wider ecosystem, since a complete standard library written in the language itself with natives per backend is self-contained by design, so components built for another ecosystem's runtime do not plug into it. The fourth is a hiring constraint, since a functional ML-family language with C syntax is learnable but it is not a language any new hire arrives knowing, unlike a JavaScript or TypeScript UI project. The fifth is a project that needs a browser runtime today, because the Flash and HTML5 history shows the platform has lived through a runtime transition before, and a language that compiles to JS in the browser is a different proposition from one that targets a native app store.

## Conclusion

Teams maintaining one user interface across a web front end, mobile apps and desktop, who are willing to adopt a language and toolchain outside the mainstream, are the people flow is for, and the fact that the compiler is written in the language it compiles makes the bootstrap story unusual and convincing. It is the wrong choice for a team whose platform set does not include the targets the readme lists, since the same code compiling to all of them is the whole argument, and it is the wrong choice if you need a mainstream language with a large hiring pool. Check three things before you commit: that you can satisfy the toolchain requirements, since flowc needs the 64 bit build of OpenJDK 21 or newer and will not start on anything older, and that Git LFS is installed before you clone rather than after, because the readme is explicit that you have to re-clone or run git lfs pull, and that the split licensing is acceptable, since the compiler is GPL-2.0-or-later while the standard library is MIT. The repository publishes no GitHub releases, the last push was on 2026-10-22, and the project was first open sourced in April 2019.

## FAQ

### What is flow9 and what platforms does it target?

flow is a platform for programming complex, multi-platform apps with a modern user interface, made up of a safe, functional, strongly-typed language, the flowc incremental compiler, and a runtime and standard library with a complete cross-platform library including mature UI components. The production quality targets are HTML through JS, iOS, Android, and Windows, Mac and Linux.

### How do I install flow on Linux?

Clone the repository, change into the flow9 directory and run ./bin/setup-linux. The script installs what your distribution needs, knows pacman, apt and dnf, prints every command before running it, asks before using sudo, builds the C++ runner and runs a hello world to check the setup.

### What does flow need on Windows and macOS?

Git LFS installed before cloning, Python 3 on your path, flow9/bin added to your path, and the 64 bit version of OpenJDK 21 or newer, since flowc will not start on anything older. You then compile and run the first program with flowcpp demos/demos.flow from the flow9 directory.

### Which compiler should I use, flowc or flow?

flowc is the current compiler, written in flow itself and able to work as a compile server. flow is the original compiler, written in haxe. The tooling also includes a single-step debugger using the gdb protocol, a profiler, a JIT for x64 with an interpreter for ARM, and the ability to compile to C++ and Java for performance-critical code.

### What licence does flow use?

The flow compiler is licensed under the GNU General Public License version 2 or any later version, and the flow standard library is released under the MIT license. For the licence of other components, the readme points at LICENSE.txt, and the repository publishes no GitHub releases.

## Sources

- [area9innovation/flow9 on GitHub](https://github.com/area9innovation/flow9)
- [Issues](https://github.com/area9innovation/flow9/issues)
- [README](https://github.com/area9innovation/flow9/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/area9innovation-flow9