We're excited to announce that our experiments with KDE Plasma have yielded positive results, both the X11 session via XWayland and the Wayland session.

How to​

Please visit this document for detailed instructions. In simpler terms, just add the following configuration to your localdesktop.toml file:

[command]
try_check = "pacman -Qg plasma"
try_install = "stdbuf -oL pacman -Syu plasma --noconfirm --noprogressbar"
# X11 session via Xwayland
try_launch = "XDG_RUNTIME_DIR=/tmp Xwayland -hidpi :1 2>&1 & while [ ! -e /tmp/.X11-unix/X1 ]; do sleep 0.1; done; XDG_SESSION_TYPE=x11 DISPLAY=:1 dbus-launch startplasma-x11 2>&1"
# Wayland session
try_launch = "XDG_RUNTIME_DIR=/tmp WAYLAND_DISPLAY=wayland-0 /usr/lib/plasma-dbus-run-session-if-needed startplasma-wayland 2>&1"

The outcome has been so promising that we're considering setting KDE Plasma as the default desktop environment in Local Desktop. This aligns with our long-term goal: replacing XWayland with a native Wayland session for better performance. We'd love to hear your thoughts on our GitHub repository, and toss us a ⭐️ to help keep us motivated to improve KDE Plasma compatibility!

According to Android Authority, Android Canary 2507 now supports native GUI Linux apps.

After installing the July 2025 Canary build, a new icon appears in the Linux Terminal app that opens a display activity. Inside it, running weston launches a full Wayland-based Linux desktop session. It even has GPU acceleration and audio support 🤯

This is exactly, and technically, what we're building. I believe we had the same approach: Wayland, as I haven't checked the code, but the fact that they shipped weston says everything.

In some way, we just got sherlocked, since people are less likely to pick a third-party app if there's a built-in alternative (at least that's what I would do). However, as an Android user, I'm actually delighted. It's a win-win situation: this validates what we've believed all along, Android devices can be more than phones. With official support, more people will explore desktop-style workflows, and more manufacturers will build hardware to support them.

This built-in feature will likely be available starting from Android 16, but Local Desktop will continue to do its best to support all devices from Android 5 and beyond. We've always been about unlocking possibilities before they go mainstream - and we're not stopping now.

Please star our GitHub repository and follow our adventure 🐻‍❄️

I'm excited to share and express my gratitude for Sentry's approval of our application to their Open Source Sponsorship Plan 🎉

If you're maintaining an open-source project, you can apply here. Having Sentry for telemetry helps more than you might expect. Before using Sentry, we had to ask users to connect their devices to a PC via USB, capture logcat output, and send it to us via email or GitHub. Now, panic reports are automatically sent to us with detailed context, helping us quickly identify which assumptions or expectations went wrong, and take timely action.

We also plan to make further use of Sentry by leveraging traces and spans to monitor FPS and frame delays. This will help us optimize the app's smoothness even more. Follow our progress on GitHub!

Local Desktop just reached 100 stars on GitHub 🎉 What surprised me even more was a sudden wave of traffic from Brazil. Obrigado 🇧🇷

Your support means the world to us, and we will keep working hard to make Local Desktop better every version. We are working on handling better mouse/trackpad input, and our next plan is to support an Android storage mount point.

This is not a technical guideline about how to write an Android app in Rust, we might write another article for that. Also: this approach does not fit every application, as onscreen keyboards won't work on such apps.

The app​

Local Desktop is an Android app for running a Linux desktop environment, like Xfce4 on your device. Its name is a pun in contrast to Remote Desktop, my personal pain whenever I wish to write some code or inspect some webpage on my big screen tablet.

Where did the idea come from?

86% of new product ideas come from personal pain. Source: rosenfeldmedia.com/books/lean-user-research

The rewrite​

Our app relies heavily on PRoot for the Linux part and Wayland for the GUI desktop part. The components must be run in NDK, and we used to have an Android app with Kotlin and C++ code. In theory, we can do all the logic in C++, but it was much more complicated and more error-prone, so we tried to push as much logic to Kotlin as possible. And there was the surface handling part, where we had to pass references from JVM to native, native to JVM, chaotically.

Having 2 languages in a code base makes it hard to maintain, and it is a large barrier for someone who would like to contribute to the app. Only the Coroutine section of Kotlin took me days to complete, and it is just a small part of the language. About C++, I found it very difficult to write just correct code, not to mention efficient code. After realising that the object I put into a HashMap silently vanishes as soon as the function returns (even though the HashMap is still being used), I added these 2 books to my wishlist:

ChatGPT recommended me these books, they seem like some good reads, but would take a mountain amount of time. And nothing guarantees that only those who have read the books will work on your project.

So we decided to do a rewrite. We declared a NativeActivity in AndroidManifest.xml, and we're done. All the logic happens in NDK now. But this time, we use Rust instead of C++ for NDK development. Why Rust?

The community are showing increasing appreciation for Rust performance, as all the tools I was working with are either being rewritten in Rust:

• "....we've migrated some of the most expensive and parallelizable parts of the framework to Rust, while keeping the core of the framework in TypeScript for extensibility." - A new engine, built for speed - TailwindCSS.
• "...there is an ongoing effort to build a Rust-port of Rollup called Rolldown" - Vite.

or have a new Rust rival: Tauri (a lighter Electron), Helix (a more modern Vim), paru (a newer yay), Zed (a faster VSCode),...

Now I sympathise with this appreciation.

The Good​

Rust enforces correctness​

Fun fact:

The typical Rust code when you jot down your thought	The typical C++ code when you jot down your thought

There are a lot of compiler errors to fix, but when a Rust program is compiled, things usually work flawlessly! This contradicts C++, where changes are usually compilable, but when I hit run, waiting for like 5 minutes on my mediocre laptop, the app crashed. I have to trace the whole code with the logic inside my head to figure out why it crashed, fix it, then wait for another 5 minutes to rerun. My app didn't crash immediately anymore, but when I click on the black screen, it crashes. This cycle repeated n times. It took me like 1/4 hour to fix Rust compiler errors, but it saved me hours (or days) to trace what went wrong.

The Rust Book is all you need to write effective Rust code, as Rust itself is designed with efficiency in mind!

Rust lang is logically strict. Anyone working with TypeScript knows that its typing is just an annotation layer, there is no guarantee that the variable labelled by the type actually belongs to that type. Runtime errors occur whenever these assumptions are wrong. In Rust, you can rest assured that if it is a duck, it is a duck. Once I tried to cheat the mutex lock, but the ownership rule makes cheating impossible, no // IMPORTANT! blocks, no CAREFULLY_README.md files, it's just ownership rules, a part of the language. Whoever invented the ownership rules or designed the Rust smart pointers really needs a raise, to be the CTO at some big tech for real. Now we have a whole ecosystem being enforced under these rules, making the usage of each library (such as Smithay) so logical and secure. You cannot mistakenly add a relative coordinate in place of an absolute coordinate (even though they have the same shape), or you cannot handle touch events if the event source only emits mouse events. In C++, you can end up doing something much more silly, such as placing the keyboard handle into the slot for a mouse handle. Nothing is preventing you from doing so, that's why the Effective C++ books are best-sellers.

Everything is under your control​

Rust libraries, called crates, are mostly (or always?) open source. They are not yet thoroughly documented, nor complete, but the better thing is that whenever things don't go the way you expect, you can always follow a Go to Definition from your IDE, or even put breakpoints and see how they work internally. You can easily experiment with changes, which is usually impossible with TypeScript libraries, as the code is usually minified or obfuscated. This allows us to move fast without blocking, and learn more.

Lighter tools, lighter app​

Another good thing: we now use Visual Studio Code to develop the app, so in the future we can continue development directly on Local Desktop (Android Studio does not have a release for ARM64 Linux ). Intellisense and Debugging Rust code in VS Code is a better experience than in Android Studio, in my opinion. Once upon a time, I updated Android Studio, and Dual debugging stopped working. I eventually fixed the issue somehow after a couple of hours. In our new setup, only 1 programming language needs to be debugged.

What's more, the new APK file is ~4Mb in release mode.

The conclusion​

After proofreading this blog, I feel like it is a lengthy criticism of C++. However, I'm not apologising for the hustle I've been through. I encourage everyone to start their new native project with Rust, and I firmly believe Rust has the potential to become the unified programming language of the future, the one that lets you code everything from interactive web sites to server-side, desktop/mobile apps, games,... correctly and efficiently.