HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
rust-windowing
winit
Rust2019–2025
rust-windowing / winit

winit

Window handling library in pure Rust

12Distinct people
15Mentions
0Explicit recommenders
6.3KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Window handling library in pure Rust

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year15 dated mentions

Observed mentions: 2019-02-28 01:28:18 UTC to 2025-12-22 02:14:32 UTC.

0123452019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments20222023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments2025

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC303
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC000
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC303
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC211
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC101
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC505
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC110

What Hacker News says

15 sources
rekireki·Dec 22, 2025Submission

Build Android apps using Rust and Iced

Some time ago I decided to try building an Android app using Rust. After a few weeks I got it working. There was a new iced release recently, so I've just updated the example to new iced and wgpu. I'd like to share my experience to attract more attention to Rust on Android. First things, I want to thank all the people who work on the foundational crates and tools such as: - https://github.com/rust-mobile/android-activity - https://github.com/jni-rs/jni-rs - https://github.com/gfx-rs/wgpu - https://github.com/rust-windowing/winit - and many others When I started I had to learn what tools and examples already exist. Luckily, there's a good set of examples using both NativeActivity and GameActivity: https://github.com/rust-mobile/rust-android-examples The basic approach is that we take android-activity, winit and wgpu and that's it. On top o
Read the rest
f that you can find a few egui examples in the rust-android-examples repo. Alright, so after I've got the basic examples running, I wanted to combine them with iced. Iced is a crossplatform gui library focusing on desktop and web. The mobile support is explicitly a non-goal, as far as I can tell at the moment of writing. Yet, there's an issue where some people posted their experiments. That's how I knew it was possible: https://github.com/iced-rs/iced/issues/302 There's a way to integrate iced in wgpu applications, so called integration example: https://github.com/iced-rs/iced/tree/0.14.0/examples/integra... Above I mentioned that using winit and wgpu in combination with android-activity is enough to build the app. Putting together 1 + 1 I got 2: let's use iced integration example with android-activity. It was quite easy to compile with almost no errors. First issue I encountered is that there was no text rendered. I solved this by loading fonts the way it was shown here: https://github.com/pop-os/cosmic-text/issues/243#issue-21899... Then I patched a few widgets to add touch support. And that's it. My role here was to take all the prior work and combine it together in a way that there's a working example. Some other ways of building Android apps using Rust: - xilem has an explicit goal to support mobile https://github.com/linebender/xilem - egui supports mobile https://github.com/emilk/egui - game engines such as Fyrox and Bevy support mobile: - https://github.com/FyroxEngine/Fyrox - https://github.com/bevyengine/bevy - pretty much anything built on top of winit and wgpu All of the above is related to building native apps using either NativeActivity or GameActivity. I'm leaving webview out of scope of current post. What about iOS? As far as I know it should be similar or maybe simpler compared to Android. I haven't built it yet, but the next time I have a sizeable amount of free time, I'll try to make it work. The plan is the same: pick winit, wgpu, iced integration example, mix it together until it works. It'll require the same trick to load fonts, and maybe something else, but no visible blockers as of now. Once again, thanks to all the people who made it possible and I wish you have a great time building mobile apps with Rust!
173 points · Open discussion
> Is this something Flutter doesn't do? Flutter does do this (at least to some extent) on Desktop/Mobile. It attempts to create a hidden DOM tree for accessibility on web. Which generally doesn't seem to be thought to work very well. > One of the most jarring experiences I have with Flutter Desktop was it lacked MacOS Emacs-style key bindings for text editing (ctrl-a, ctrl-e, etc.). Not sure if Dioxus solved this? Ah, we're nearly there on that one. We have a PR [0] accepted into Winit (the underlying windowing library we use) which will allow us to access those events. We're just waiting on Winit to do a new release and then we can integrate it into Dioxus. [0]: https://github.com/rust-windowing/winit/pull/3824)
In Dioxus 0.6 – Crossplatform apps with Rust
> The consortium aims to develop guidelines, tools, libraries, and language subsets to meet industrial and legal requirements for safety-critical systems. > Moreover, the initiative seeks to incorporate lessons learned from years of development in the open source ecosystem to make Rust a valuable component of safety toolkits across various industries and severity levels Resources and opportunities for a safety critical Rust initiative: - "The First Rust-Written Network PHY Driver Set to Land in Linux 6.8" https://news.ycombinator.com/item?id=38677600 - awesome-safety-critical > Software safety standards: https://awesome-safety-critical.readthedocs.io/en/latest/#so... - rust smart pointers: https://news.ycombinator.com/item?id=33563857 ; LLVM signed pointers for pointer authentication: https://news.ycombinator.com/item?id=40307180 From h
Read the rest
ttps://news.ycombinator.com/item?id=33563857 : > - Secure Rust Guidelines > Memory management, > Checklist > Memory management: https://anssi-fr.github.io/rust-guide/05_memory.html Rust OS projects to safety critical with the forthcoming new guidelines: Redox, Cosmic, MotorOS, Maestro, Aerugo - "MotorOS: a Rust-first operating system for x64 VMs" https://news.ycombinator.com/item?id=38907876: "Maestro: A Linux-compatible kernel in Rust" (2023) https://news.ycombinator.com/item?id=38852360#38857185 ; redox-os, cosmic-de , Motūrus OS; MotorOS - https://news.ycombinator.com/item?id=38861799 : > COSMIC DE (Rust-based) supports rust-windowing/winit apps, which compile to a <canvas> tag in WASM. > winit: https://github.com/rust-windowing/winit - "Aerugo – RTOS for aerospace uses written in Rust" https://news.ycombinator.com/item?id=39245897 - "The Rust Implementation of GNU Coreutils Is Becoming Remarkably Robust" https://news.ycombinator.com/item?id=34743393 From a previous Ctrl-F rust,; "Rust in the Linux kernel" (2021) https://news.ycombinator.com/item?id=35783214 : - > Is this the source for the rust port of the Android binder kernel module?: https://android.googlesource.com/platform/frameworks/native/... > This guide with unsafe rust that calls into the C, and then with next gen much safer rust right next to it would be a helpful resource too. From https://news.ycombinator.com/item?id=34744433 ... From "Are software engineering “best practices” just developer preferences?" https://news.ycombinator.com/item?id=28709239 : >>>>> Which universities teach formal methods? /?hnlog "TLA" and "side channel"
In Industry forms consortium to drive adoption of Rust in safety-critical systems
Hi! I’m Aloke, an engineer at Warp. I’m really excited to share that Warp is now available on Linux! If you’re interested in trying it out, you can download Warp at https://www.warp.dev/. We've gotten 2-3 reports of authentication issues like the one the author mentions. We are actively looking into it; we believe its an issue with a library we depend on to open URLs. If anyone is experiencing these issues, please contact us at support@warp.dev so we can better understand the issue and further debug! Building Warp on Linux was quite an undertaking. Warp uses a custom Rust-based UI framework that we built in house and renders natively on the GPU. To get Warp running on Linux, we built a version of our UI framework that supports winit [1] as a windowing backend. We also built a version of our renderer that uses wgpu [2]. Reducing complexity
Read the rest
by using these well-supported, cross platform, frameworks let us bootstrap a version of Linux quicker than expected and should make it easier to build Warp for other platforms (like Windows). Please let me know what you think! Happy to answer any questions, either about the product or about technical challenges. [1] https://github.com/rust-windowing/winit [2] https://github.com/gfx-rs/wgpu
In Warp Terminal is now available for Linux
Hi! I’m Aloke, an engineer at Warp. I’m really excited to share that Warp is now available on Linux! If you’re interested in trying it out, you can download Warp: https://warp.dev/ Building Warp on Linux was quite an undertaking. Warp uses a custom Rust-based UI framework that we built in house and renders natively on the GPU. To get Warp running on Linux, we built a version of our UI framework that supports winit [1] as a windowing backend. We also built a version of our renderer that uses wgpu [2]. Reducing complexity by using these well-supported, cross platform, frameworks let us bootstrap a version of Linux quicker than expected and should make it easier to build Warp for other platforms (like Windows). Please let me know what you think! Happy to answer any questions, either about the product or about technical challenges. [1] https:
Read the rest
In Linux version of Warp terminal is here
There are a number of up-and-coming Rust-based frameworks in this niche: - https://github.com/iced-rs/iced (probably the most usable today) - https://github.com/vizia/vizia - https://github.com/marc2332/freya - https://github.com/linebender/xilem (currently very incomplete but exciting because it's from a team with a strong track record) What is also exciting to me is that the Rust GUI ecosystem is in many cases building itself up with modular libraries. So while we have umpteen competing frameworks they are to a large degree all building and collaborating on the same foundations. For example, we have: - https://github.com/rust-windowing/winit (cross-platform window creation) - https://github.com/gfx-rs/wgpu (abstraction on top of vulkan/metal/dx12) - https://github.com/linebender/vello (a canvas like imperative drawing API on top of wgpu
Read the rest
) - https://github.com/DioxusLabs/taffy (UI layout algorithms) - https://github.com/pop-os/cosmic-text (text rendering and editing) - https://github.com/AccessKit/accesskit (cross-platform accessibility APIs) In many cases there a see https://blessed.rs/crates#section-graphics-subsection-gui for a more complete list of frameworks and foundational libraries)
In XUL Layout is gone
On MacOS "pulling in complex UI framework" amounts to "#[link(name = "AppKit", kind = "framework")]" somewhere in my Rust codebase. On Windows it's similar. With Gnome it seems unclear how to do something equally simple to get decorations that match the OS look and feel. The most popular Rust windowing library ended up implementing their own client-side decorations rendering that imitates GTK: https://github.com/rust-windowing/winit/pull/2263. And if every framework / app is doing this in their own subtly different way then the result is an OS where many apps have slightly different UX, buttons, text rendering, shadows, etc. A horribly unpolished experience.
In Blender: Wayland Support on Linux
I agree wgpu is great, but wgpu isn't a substitute for SDL. The Rust project that replaces SDL is called winit https://github.com/rust-windowing/winit One can use wgpu with winit (which is more common) or, if they prefer, wgpu with sdl2. Here is an example: https://github.com/Rust-SDL2/rust-sdl2/tree/master/examples/... edit: but, the "next-gen Vulkan API" the article refers to, that SDL will be developing, it would be a competitor to wgpu.
In SDL gets an Epic MegaGrant to work on next-gen Vulkan API
Good to see more alternatives in this space. If I can make one big app design request it would be this: Don’t assume that apps can always create their own windows. This has been a snag for winit and several others. Allow creating a GUI given an existing window handle. See e.g. https://github.com/rust-windowing/winit/issues/159 If you create a rust ui framework that supports the VST windowing/event loop model and just supports one GUI backend on Win32/MacOS, then many people in the audio plugin community would be very happy.
In Show HN: Sauron-native – A native cross-platform GUI for Rust
As I mention in the post, users of glutin should update their application to use the new glutin release candidate. Back ports are a PITA, and I'd hate to have to do one. I should also mention, I'm the current maintainer of glutin. Feel free to ask me any questions, or join us at our chat: https://crates.io/crates/glutin Here's our crate io, too, fwiw: https://crates.io/crates/glutin Please also consider taking a stab at some of the tasks in our and/or winit's bug tracker. I'm grateful for every bit of help. https://github.com/tomaka/glutin/issues https://github.com/tomaka/winit/issues
In Glutin v0.21.0 Release Candidate Season
Browsers do a lot of blacklisting of drivers with known problems. Things are slowly improving, especially as browsers themselves, especially Firefox, steadily do more GPU stuff (putting pressure on the driver makers to fix things), but there’s a reason why it’s been very rare for non-game UIs to target GPUs for rendering: GPU drivers are atrocious. Even if they don’t crash, the number of absolutely fundamental and critical bugs that they have is very impressive. As an example of a fundamental thing being broken, try https://github.com/tomaka/winit/pull/332#issuecomment-341383... and later on down in the thread where a driver update fixed it.
In Gpu.js – GPU Accelerated JavaScript

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.