Lapce's Makefile builds macOS only, and its newest numbered release is still v0.4.6
Lightning-fast and Powerful Code Editor written in Rust. Lapce Lightning-fast And Powerful Code Editor Lapce (IPA: /l ps/) is written in pure Rust, with a UI in Floem.
At a glance
- What is it?
- Lapce is a code editor written in pure Rust with a Floem user interface, wgpu rendering, WASI plugins, and remote development delegated to a separate tool called Lapdev. The parts worth reading before you build are the macOS-only Makefile with its hardcoded signing fingerprint, a rust-version floor of 1.98.0, and the distance between the v0.4.6 release and the nightly tag.
- Who is it for?
- Lapce suits someone who wants an editor written in Rust, is willing to track a project whose newest numbered release is v0.4.6, and either installs a prebuilt binary or builds on macOS with their own signing identity. It does not suit a Linux or Windows packager looking for a maintained build recipe, because the Makefile in the repository is macOS-specific and its default target only prints help.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 5 days ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 25, 2026, and from our analysis. They are not legal advice.
Editorial analysis
Four workspace members, two binaries, and a Rust floor of 1.98.0
The Cargo workspace has four members, `lapce-app`, `lapce-proxy`, `lapce-rpc`, and `lapce-core`, and it produces two binaries: `lapce` from `lapce-app/src/bin/lapce.rs` and `lapce-proxy` from `lapce-proxy/src/bin/lapce-proxy.rs`. A `default-run = "lapce"` entry decides which one a bare invocation picks, so `cargo run` gives you the editor and not the proxy. The shared package block sets version 0.4.6, edition 2024, and `rust-version = "1.98.0"`. That floor is a hard constraint rather than a suggestion, and it is newer than the toolchain shipped by most Linux distributions, so a source build on an older rustup toolchain stops before anything is compiled. The proxy existing as a separate binary is also the clearest hint at how remote development is split.
The Makefile's default target only prints its own help text
The build recipe at the repository root declares itself intended only for building macOS binaries, because it uses `lipo`, `codesign`, and `hdiutil`. Its first target is `all`, and `all` depends on `help`, which greps the Makefile for commented targets and prints them with `awk`. So running `make` with no arguments does not build anything. The macOS targets set `MACOSX_DEPLOYMENT_TARGET="10.11"` and build a `release-lto` profile, then combine slices with `lipo` for a universal binary. Linux and Windows packaging is not in this file at all. The one cross-platform piece it carries is a dependency list for Ubuntu:
apt-get update -y
apt-get install -y clang libxkbcommon-x11-dev pkg-config libvulkan-dev libgtk-3-dev libwayland-dev xorg-dev libxcb-shape0-dev libxcb-xfixes0-devA Linux contributor has to read that target by hand, because the automation that exists is for a different platform.
A hardcoded codesign fingerprint gates the macOS build
Beyond the default target doing nothing, the macOS path also hardcodes `CODESIGN_IDENTITY = FAC8FBEA99169DC1980731029648F110628D6A32` and states the requirement in its own header comment: a valid Apple Developer signing identity must be installed and available in the system Keychain under that fingerprint. The build assembles `Lapce.app` from a template in the `extra/macos` directory and packages it as `Lapce.dmg` with `hdiutil`. What this cannot do is produce a locally signed build for a developer whose identity has a different fingerprint, and it cannot produce an unsigned one either, since the file offers no unsigned path. The consequence is that a macOS source build is gated on someone else's certificate being installed, which is why the documentation points most people at the prebuilt releases instead.
Remote development is only half in this repository
Remote development is built in and described as inspired by VSCode Remote Development, with the aim of keeping a local-feeling experience while getting the power of a remote system. The tooling that manages those remote environments is a separate product, Lapdev, published at lap.dev. In the workspace that split shows up as the second binary, `lapce-proxy`, which lives alongside the editor instead of inside it. So what this repository cannot give you is the environment side of the story. Choosing Lapce on the strength of its remote workflow means adopting Lapdev as well, and judging the remote path from the editor source alone will tell you very little. The README treats this as a feature rather than a caveat, which is worth keeping in mind when you weigh switching costs.
Plugins have to compile to WASI, which closes off the native extension route
The extension boundary is a WebAssembly one. Plugins are written in languages that compile to the WASI format, and the named examples are C, Rust, and AssemblyScript. That is a real sandbox, and it is also a constraint that rules out the other common editor extension models. A plugin that expects a native dynamic library, or that expects a Node or Deno host, cannot be dropped into Lapce as written, and a plugin ported from another editor becomes a rewrite against a WASI target rather than a settings change. The README does not enumerate a compatibility list for existing plugin ecosystems, so the practical way to find out whether an extension you rely on has a WASI port is to look for it yourself. For a team whose tooling is already written as native editor extensions, that migration cost is the number to estimate first.
wgpu rendering pulls eleven system libraries into the build
Rendering goes through wgpu and the user interface is built with Floem, which means the editor is a GPU client rather than a terminal program with a pane on top. The Ubuntu dependency target shows the shape of that floor: `clang`, `libxkbcommon-x11-dev`, `pkg-config`, `libvulkan-dev`, `libgtk-3-dev`, `libwayland-dev`, `xorg-dev`, `libxcb-shape0-dev`, and `libxcb-xfixes0-dev`. The `libvulkan-dev` entry is the notable one, since it points at a Vulkan-capable path rather than a plain OpenGL fallback. What that build cannot avoid is a native graphics stack, which is why the list includes both Wayland and X11 development packages plus two XCB extensions. In headless containers, on remote desktops without a GPU, and on older hardware, that stack is where a first run tends to stop, and the README does not describe a fallback.
v0.4.6 is the newest numbered release, and the nightly tag carries the rest
The release history is thin at the top and uneven below. The most recent numbered tags are v0.4.6 on 2026-01-21 and v0.4.5 on 2025-09-05, while a nightly tag is dated 2026-09-30, and the workspace version is still 0.4.6. The repository is not archived and its last push is dated 2026-09-25, so the work is continuing even though it is not landing in numbered releases at the same rate. The consequence for anyone installing is a split decision: the releases page gives you January code, the nightly gives you current code, and the two will not behave identically. The README does not describe a release cadence or a stability policy for the nightly channel, and it also does not document a rollback path, so picking a channel is a judgement call rather than a documented one.
Editorial conclusion
Lapce suits someone who wants an editor written in Rust, is willing to track a project whose newest numbered release is v0.4.6, and either installs a prebuilt binary or builds on macOS with their own signing identity. It does not suit a Linux or Windows packager looking for a maintained build recipe, because the Makefile in the repository is macOS-specific and its default target only prints help. Before committing, check the releases page against the nightly tag, read docs/building-from-source.md, and confirm whether the WASI plugin boundary works for the extensions you already use.
Frequently asked questions
Is Lapce free?
It is released under the Apache License Version 2, an open source license. You may contribute to the project or use the code as you please as long as you adhere to its conditions, and pre-built releases for Windows, Linux, and macOS are published on the releases page.
Is Lapce a Rust code editor?
Yes. It is written in pure Rust with its user interface in Floem, and the Cargo workspace declares edition 2024 with `rust-version = "1.98.0"`.
Which code editor is better, Lapce or Zed?
The project publishes no such comparison. What it states about itself is that it is written in pure Rust, uses a Floem user interface, is designed with Rope Science from Xi-Editor, and renders through wgpu.
lapce vs zed vs vscode
Its remote development is described as inspired by VSCode Remote Development, with Lapdev available to manage remote environments. Beyond that reference, the documentation does not compare it with VS Code or with Zed.
What is the best IDE based on Rust?
Lapce is a code editor written in pure Rust with a Floem user interface. It includes built-in LSP support for completion, diagnostics, and code actions, modal editing that is toggleable, and a built-in terminal.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/lapce-lapce)