Open CAD Studio: a Rust CAD application that reads and writes DWG natively

One editing core behind both a desktop app and a browser app

The pitch is in the subtitle: open source 2D drafting and 3D modeling for desktop and web, built with Rust. What makes that more than a marketing line is the release cadence behind it. Each of the three most recent releases, 2026.37 on 2026-09-13, 2026.38 on 2026-09-20 and 2026.39 on 2026-09-27, describes itself as a weekly release for web and desktop from the same source revision. The repository's last push was on 2026-09-28, so this is a project on a one-week cadence rather than one that batches changes for months.

The README splits the two targets explicitly. The web app at opencadstudio.com is for immediate access with no installation, with drawings selected through the browser and saved as local downloads. The desktop application is for native file associations, file manager thumbnails, system printing, PDF output, external plugins, command scripts and headless automation. Release builds exist for Windows, Linux and Apple Silicon macOS.

That split is the honest architectural claim in the project. A browser build that is genuinely the same core as the desktop build is unusual, because most web CAD products are viewers that import and then hand off. Here the boundary is capability rather than code: both targets edit, and the desktop target adds the things a browser sandbox cannot reach. The 2026.38 release notes mention opening a drawing from bytes on the web target, which suggests the gap is narrowing from the drawing side rather than from the feature side.

What the file format table commits to, and what it does not

The README's most useful section is a table of formats and workflows, and it is worth reading closely because it distinguishes read from write and states version ranges. DWG is read and write, with versioned save targets from R14 through 2018. DXF is the same. BAK and SV$ files can be opened as drawing backups and autosave files. OBJ and LandXML come in as imports, with LandXML specifically importing `CgPoint` survey points. STL and STEP AP203 are exports. PDF is a desktop-only capability for plotting layouts and selected geometry. CSV extracts entity property data, and CTB and STB plot style tables can be loaded and edited.

Two things stand out. First, no current-version DWG is named. The newest save target stated is 2018, which means a drawing produced by a recent AutoCAD release may open but may not round-trip losslessly, and the README's instruction to keep backups of important production drawings is doing more work than it appears to. Second, the export side is mesh-based: STL and STEP AP203 are both listed as exporting 3D mesh data. STEP AP203 carrying mesh rather than exact B-rep is a meaningful limitation for anyone who intends to hand a solid to another CAD system and keep working with it.

The README's own framing is that the project is under active development and asks readers to report reproducible problems through GitHub Issues. With 139 open issues at the time of writing, that channel is where format fidelity questions get answered, not the README.

wgpu rendering with a fallback path for older GPUs

Rendering is the part of the architecture you can inspect in the source tree rather than read about in prose. The README states that the 2D and 3D viewports are accelerated through `wgpu`, with orthographic and perspective cameras, and the repository carries a `snap/` directory alongside `crates/`, `benches/` and `tests/`. The versioned release notes add detail: 2026.38 includes a GPU backend probe with automatic fallback for older GPUs, and 2026.37 adds a user-facing message when the scene is drawn without a GPU.

An automatic probe with fallback, plus a visible notice when the fallback is in use, is the correct shape for this problem. Software rendering of a viewport that is not told it is on a software rasteriser is how you get a CAD application that appears to hang. It also means the interesting question about performance is not what the GPU path does but what the fallback does, and the README does not say.

The 2026.37 notes mention introducing a standardized 25-metric CAD and UI benchmark suite. A benchmark suite in the repository is a reasonable signal, though the release notes list it as an addition rather than reporting results, so it tells you measurement is possible rather than telling you where the numbers landed.

The Cargo.toml pins a fork and three geometry repositories to exact revisions

The root `Cargo.toml` is where this project's real dependencies are disclosed, and it is unusual in a way worth noting. The user interface is `iced`, but it is pulled from a git repository at a specific revision, with `iced_runtime` and `iced_core` at the same revision and `iced_aw` from the maintainer's own fork of iced_aw on a branch named `agent/fix-iced-fonts`. Alongside those sit `bytemuck` and `glam` for data transfer and vector maths, `rfd` for file dialogs, `clap` for argument parsing, and `env_logger` with `log`.

The geometry stack is three separate repositories, all pinned by revision: `opencadcodec` for file formats, `opencadkernel` with the `acis` and `offset` features enabled, and `opencadkernel-constraints` at the same kernel revision, plus `opencadgraph` for the node graph. The release notes describe these in operational terms rather than promotional ones: 2026.39 moved the node graph overlay to opencadgraph and pinned cadcodec at dd1d7bf and cadkernel at 6eae7c9, and an earlier entry synced an upstream acadrust change into cadcodec.

Two consequences follow. Building from source means fetching several git repositories at exact commits, so a build is only reproducible as long as those remotes are reachable. And the `acis` feature on the kernel means solid modelling goes through ACIS entity tessellation, which the README lists as a 3D modelling highlight alongside primitives, extrusion, revolution, sweep, loft and Boolean operations. Tessellation is where a CAD application's mesh fidelity is decided, and this is a fast-moving dependency pinned by commit hash.

Installing on Linux, where the AppImage and the Flatpak behave differently

Linux gets the clearest installation story of the three platforms. The README points at an x86-64 AppImage and gives two commands:

chmod +x OpenCADStudio-*-linux-x86_64.AppImage
./OpenCADStudio-*-linux-x86_64.AppImage

Alternatively there is a Flatpak served from FlatPark, which follows new releases automatically:

flatpak remote-add --if-not-exists flatpark https://dl.flatpark.org/flatpark.flatpakrepo
flatpak install flatpark io.github.HakanSeven12.OpenCadStudio

The Flatpak comes with a documented limitation that is worth reading before you pick it. It opens and saves drawings through the file chooser, but external references and underlays that point at other files need explicit home access:

flatpak override --user --filesystem=home io.github.HakanSeven12.OpenCadStudio

In practice that means a Flatpak user editing a drawing with an XRef to a shared folder needs the override command before the drawing renders correctly. The AppImage has no equivalent problem, which is the trade a reader makes when choosing between them.

macOS is the thinnest part of the story. The published package supports Apple Silicon only, you drag `OpenCADStudio.app` into Applications from the disk image, and if Gatekeeper blocks the first launch you approve it in System Settings under Privacy & Security. The README also states plainly that the application is ad-hoc signed but is not currently notarized by Apple, which means every install begins with a manual security approval.

Headless conversion, command scripts and an audited MCP save path

The extensibility story is broader than a plugin system, and it is the part most likely to matter for a pipeline rather than for a drafting seat. The README lists native plugins, command scripts, headless conversion and a line-based JSON automation API under extensible workflows. The repository backs that up with a `plugins/` directory and an `ocs_plugin_api` crate in the workspace, alongside `ocs_web_worker` and the `dwg-thumbnailer` crates.

The release notes show the plugin system being shaped rather than just advertised. Version 2026.39 refactors command dispatch so that plugin dispatch ends through a finish_dispatch path, and records a last_cmd value on plugin dispatch so that pressing Enter repeats the last command. Version 2026.38 extracts and speeds up a layer usage table rebuild. Both entries describe internals, which is a good sign: they are the kind of change a release note only mentions when someone is already depending on the behaviour.

The most consequential line in the 2026.39 notes is the addition of an audited, versioned MCP save workflow. An audited save path matters more than it sounds for an application whose selling point is native DWG writing, because it means the action of overwriting a drawing can be recorded and versioned rather than being a single irreversible click. That is the kind of feature a project adds when it expects people to point it at real files.

The interface ships in 21 languages, listed in the README with Arabic, Brazilian Portuguese, Bulgarian, Czech, Dutch, Finnish, French, German, Greek, Hindi, Hungarian, Italian, Japanese, Korean, Polish, Russian, Simplified and Traditional Chinese, Spanish and Turkish, and the language can follow the system setting. In the browser build, selecting System follows the browser's preferred locale. For a CAD application, localisation is rarely a headline feature, but it is a strong signal about who the maintainer expects to be using the software.

Editorial conclusion

Open CAD Studio is a credible option when the deciding requirement is opening existing DWG files without a conversion step, and a poor one when you need a mature parametric history, a verified kernel or a notarised macOS build. The honest parts of the pitch are the versioned save targets from R14 through 2018, the shared source revision behind the web and desktop builds, and the GPL-3.0 licence that comes with the AGPL-style obligations of a linked desktop application. The parts still being proven are the geometry kernel and constraint solver, which the release notes describe week by week in terms of fixes rather than coverage, and the repository is candid about all of it: it tells you to keep backups of production drawings and to report reproducible problems through GitHub Issues. Install the Linux AppImage or try the web app first, then test it against a real drawing of yours before planning any migration off AutoCAD.

Frequently asked questions

Official sources

1. HakanSeven12/OpenCADStudio on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases