Uniswap/interface: the public mirror of the Uniswap front end, and what you can actually do with it

What Uniswap/interface is, and who the public repository is for

This is the public repository for Uniswap Labs' front-end interfaces. The README lists three: the Web App at app.uniswap.org, and the Wallet as a mobile app and a browser extension at wallet.uniswap.org. The protocol underneath is described in the README as a protocol for decentralized exchange of Ethereum-based assets. The repository itself is TypeScript, licensed GPL-3.0, and the last push was on 2026-08-17.

The audience is narrower than the name suggests. This is not the protocol. It is the client software that talks to it. If you want to read how a production swap interface handles routing, token lists or wallet connection, or if you want to run that interface yourself, this repository is the source. If you want to build on Uniswap at the contract level, you are in the wrong repository; the README points to uniswap.org/docs/ and the V1 through V4 whitepapers for that.

The publishing model matters more than any single file. The README states that all front-end interfaces are developed in a private repository, and that at the end of each development cycle the latest production-ready code is published here, with releases tagged automatically. So the commit history you see is a series of snapshots, not a live development log.

How the monorepo is laid out: apps, config and packages

The README's directory table is short and worth taking literally. apps/ holds each standalone application. config/ holds shared infrastructure packages and configurations. packages/ holds shared code covering UI, shared functionality and shared utilities.

That three-way split is a normal Nx monorepo shape, and the tooling confirms it. The root package.json is named "universe", marked private, and depends on nx 22.5.4 alongside @nx/js, @nx/plugin, @nx/workspace and @nx/s3-cache. The presence of an S3 cache package tells you builds are expected to be cached remotely, which is a CI concern rather than a local one. The root is a workspace root, not a publishable package: version 0.0.0, private true.

The engines field is the constraint most likely to bite you. It pins node to exactly 22.22.2, requires bun at >=1.3.14, and answers npm with the string "please-use-bun". That is not a suggestion. A .bun-version file and a bun.lock sit at the top level, and bunfig.toml configures Bun's behaviour. If your environment resolves a different Node patch version, expect the workspace install to be the first thing that complains.

The rest of the top level is the usual heavy-monorepo furniture: commitlint.config.js and lefthook.yml for commit and hook enforcement, oxlint.config.ts and oxfmt for linting and formatting, knip.json for unused-code detection, syncpack for dependency version alignment, and a patches/ directory for patched dependencies.

Installing Uniswap/interface and running the web app for the first time

The README gives a three-command install block. Clone the repository over SSH, install the workspace with Bun, then start the web application through the Bun script.

git clone [email protected]:Uniswap/interface.git
bun install
bun web start

The third command is the interesting one. bun web start is not a Bun built-in; it is a script defined in this workspace that dispatches to the web application. Because the root is an Nx workspace, the same dispatch pattern is what you would expect for other targets, but the README only demonstrates the web one, so treat the others as undocumented at this level.

What you should see after bun web start is a local development server for the web app. The README does not state the port, so read the terminal output rather than assuming a number. For anything beyond the web app, the root README explicitly delegates: apps/web/README.md, apps/mobile/README.md and apps/extension/README.md each carry their own instructions. The mobile and extension targets are not covered by the three-command block, and the root README does not claim they are.

The private-development model is the real limitation

The most consequential fact about this repository is stated plainly in the README: development happens in a private repository, and this public repository receives production-ready code at the end of each cycle. Everything else follows from that.

A pull request against main is not a contribution to the codebase in the usual sense. There is no visible branch where feature work lands first, no public review trail for how a change was designed, and no guarantee that a fix you write here will be carried into the private tree. The CONTRIBUTING.md guide exists and the README points to it, but the release process section makes the direction of travel one-way: private first, public after. If your goal is to shape the product, this repository is the wrong surface. File the issue, but do not expect your patch to be the thing that ships.

The release tags reinforce the cadence. The three most recent are web/5.157.3 on 2026-08-10, web/5.157.2 on 2026-08-08 and web/5.157.1 on 2026-08-07. Two of those landed within three days of each other, which is consistent with patch releases being cut from a cycle rather than with continuous public development.

There is a second, quieter limitation. The README documents the install path for the web app and nothing else at the root level. Mobile and extension builds depend on their own READMEs, and the root README does not describe what those builds require. If your interest is the wallet rather than the web app, the root document will not get you there.

Licence and what GPL-3.0 means for a fork

The repository is GPL-3.0. That is a copyleft licence, and the practical consequence for anyone deploying a modified interface is that the modified source has to be made available under the same terms. This is not a permissive licence with an attribution clause; it is the stronger kind.

For a team that wants to run the Uniswap web app internally with local changes, GPL-3.0 is workable as long as you are prepared to publish your modified source. For a team that wants to take this interface, restyle it and ship it as a closed product, the licence is the obstacle, not the code. The README does not discuss licensing implications, and nothing in the repository suggests an alternative licence is available.

One structural detail is worth separating from the licence question. The root package.json is private and versioned 0.0.0, so the workspace root is not a published npm package. The GPL-3.0 terms attach to the repository as given. Whether any individual package under packages/ carries different terms is not stated, so check the package you intend to reuse rather than assuming the root licence covers every directory identically. This is a description of what the licence says, not legal advice; talk to someone qualified before shipping a derivative.

Maintenance, upgrades and the cost of tracking a moving front end

The last push was on 2026-08-17, and the newest tagged release is web/5.157.3 from 2026-08-10. The version numbering is dense: three releases inside four days, all under the same 5.157 minor. That tells you patch releases are frequent and small.

The upgrade cost is mostly in the dependency surface, not in the application code. TypeScript is pinned at 7.0.2, Node at exactly 22.22.2, and the workspace uses syncpack to keep versions aligned across packages. A monorepo that pins Node to a single patch version and runs syncpack means upgrades are deliberate events, not something you absorb by running an update command. If you fork, you inherit that pinning discipline along with the code.

Tracking upstream has its own shape. Because releases are tagged automatically and published per cycle, you can follow tags rather than commits, which is cleaner than a normal repository where main moves continuously. The cost is that you cannot see intermediate work, so a change that affects you will appear fully formed in a cycle release with no public discussion before it. Budget for reading diffs between tags rather than following development as it happens.

Two files at the top level, RELEASE and VERSION, look like the workspace's own record of which cycle it is on. Their contents are not documented, so treat them as the first thing to read after cloning rather than as something with a described format.

Editorial conclusion

Adopt it if you need to read the production front end, build it locally, or fork it under GPL-3.0 for your own deployment. Do not adopt it if you expect to contribute features upstream in the ordinary open source way, because the README states that development happens in a private repository and only production-ready code is published here at the end of each cycle. Before you build anything on it, clone the repository, run bun install and bun web start, and read apps/web/README.md, since the root README delegates per-application instructions to those files. Then check the RELEASE and VERSION files and the newest web/5.157.x tag to see which cycle you are actually sitting on.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. Uniswap/interface on GitHub