Skip to main content

Project IDX - A journey into the future of development

Welcome to Project IDX from Google, an experimental cloud-based workspace for full-stack, multiplatform software development. IDX is designed to make it faster and easier to build, ship, and manage full-stack, multiplatform apps from the comfort of your browser.

List of supported technologies

Currently for mobile development the only supported technology is Flutter. Which we will deal with IDX in depth a little later. But it is worth noting that IDX also serves for other technology stacks where the complete list is as follows.

  • Web App:  Angular, NextJS, Astro, React, Simple HTML, Svelte, Vue.js, SolidJS, Preact, Qwik, Nuxt.
  • Backend: Go, Python Fask, Node Express, Rust, LaraVel, Python Django, Gemini API + Go, Gemini API + Python, .NET.
  • Mobile: Flutter.
  • AI & ML: Gemini API, LangChain + Gemini, Gemini API Notebook.
  • Misc: Blank Workspace.

How is IDX built?

IDX uses Nix to define the environment configuration for each workspace to give you flexibility and extensibility in IDX – even our templates and previews are configured using Nix to ensure they’re working correctly inside IDX. 

IDX uses Nix to define the environment configuration for each workspace. Nix is a purely functional package manager that assigns unique identifiers to each dependency, which ultimately means your environment can contain multiple versions of the same dependency, seamlessly. However, the extensibility, programmatic configuration and effective environment caching we get from Nix provides the biggest payoff.

Nix is also reproducible and declarative. In the context of IDX, this means you can share your Nix configuration file across workspaces to load the same environment configuration. IDX defines the preview environment and workspace package configurations directly in the code repository with the .idx/dev.nix file. So, if you want to jumpstart your pair programming, you can share your Nix configuration file as part of your code repo and your teammates can dive right in with minimal setup. This is also a cornerstone of how we build templates for a wide variety of frameworks and languages in IDX.

If you are familiar with Nix, however, you might notice that the IDX implementation does not follow a strictly traditional Nix model. The Google team incorporated Nix into IDX workspaces as a way to manage packages and configure virtual machine environments connected to them, not as a pure, full-fledged NixOS installation. 

 It may look like you are looking at Visual Studio Code but what you are actually looking at is Code-OSS. Code-OSS is an open source project without any proprietary code. In other words, it is the open source part of Visual Studio Code without Microsoft's proprietary code.

How do you use Nix on IDX?

When you create a new workspace, a .idx folder with a dev.nix file is automatically added to your root directory. (If it isn’t, you can create it yourself to enable Nix.) You can define packages and your preview environment configuration here, following the Nix attribute set syntax. You can see a list of IDX-specific packages and a detailed sample in the IDX technical documentation.

Importing an existing Flutter repository

A very interesting advantage is that we can import an existing project from GitHub. In this particular case I will try to start adding Learning Tests Flutter App repository in IDX.

After following the configuration process and adapting the dev.nix file we can see that we have the project working perfectly. I have to say that it was not 100% intuitive, as I had to solve some packages like Java and Flutter as well as the installation of the Dart and Flutter extensions. But the biggest advantage is that resolving it only once, since the dev.nix file hosted inside the repository will contain all the necessary packages. Now, the whole team will be able to download the repository and be up and running without wasting time configuring their development environment.


In conclusion, Project IDX offers an innovative solution to developers, allowing them to work entirely from a web browser. This opens up a lot of possibilities by allowing them to work from low-cost, low-performance computers. If that wasn't enough, hardware setup times are reduced to one. Because once you have a machine set up it is shared across all developers. Last but not least, most of this technology is 100% open source. 

It is important to stress that this technology is experimental, but that this is a turning point in how we have approached our tools as developers. I have no doubt about that.

See you in other posts!


© 2020 Mobile Dev Hub