# Why YOU Will Drop Ubuntu Touch Entirely
### A complete, sourced guide to Ubuntu Touch, UBports, and where Linux mobile is actually going
#### For newcomers trying to understand the landscape — not an attack, a map

---

## A Personal Note — And a Bit of History

Some of you may recognise my username. About a year ago I posted something here with no
reply. Then in October 2025 I posted "We Drop Ubuntu Touch Entirely" — a detailed
strategic critique of UBports' resource allocation. The spam filter rejected it until I
ran it through an AI to sanitise the language. The first reply was "AI slop." The thread
accumulated -10 on my posts and +3 on the dismissals before being locked.

Then I submitted nine technical questions to [Q&A 176](https://forums.ubports.com/topic/11482/ubuntu-touch-q-a-176-call-for-questions).
The thread was locked before the call. Zero answers given.

I'm not angry about any of this anymore. I was angry because I thought Ubuntu Touch was
trying to be something it was never trying to be. Once I understood what it actually is,
the frustration dissolved. This post is what I wish had existed when I first arrived —
a clear map of the territory for newcomers, without the heat.

It is not an attack. It is a map.

---

## If You Want to Contribute to Real FOSS Mobile Linux — Start Here

These are the projects building shared infrastructure, upstreaming everything, and moving
the entire ecosystem forward. Every contribution compounds permanently and benefits every
project simultaneously.

---

### [postmarketOS](https://postmarketos.org)

Founded 2016 by **Oliver Smith**. One rule: mainline kernel, ten-year device lifecycles.
[723 device models](https://postmarketos.org/blog/2026/02/26/pmOS-update-2026-02/)
supported as of February 2026. Ships GNOME 49, KDE Plasma Mobile 6.5.3, and Phosh 0.51
simultaneously from one codebase. Adopted systemd in v25.06 because it's what the shared
Linux ecosystem needs. February 2026:
[generic mainline kernel packages](https://docs.postmarketos.org/pmaports/main/generic-kernels.html)
— one person's upstream contribution improves every supported device at once.

Every architectural decision asks: does this reduce friction for upstream?

---

### [Phosh](https://phosh.mobi)

Lead: **Guido Günther (agx)**. Standard Wayland via
[wlroots/phoc compositor](https://gitlab.gnome.org/World/Phosh/phoc). Six-week release
cycles. Every component upstream. Standard GTK/libadwaita apps adapt to mobile screens
without modification — no custom packaging, no walled garden.
[Phosh.mobi e.V.](https://phosh.mobi) registered February 2025 — independent legal and
financial home so the project outlives any single employer. Used by default on PureOS,
Mobian, Fedora Phosh spin, postmarketOS, Manjaro ARM, openSUSE Tumbleweed.

---

### [KDE Plasma Mobile](https://plasma-mobile.org)

Lead: **Bhushan Shah (bshah)**. Qt/Kirigami — same framework as KDE Plasma desktop,
25+ years of continuous development, corporate backing from Red Hat, SUSE, Blue Systems.
One codebase scales phone to desktop. Plasma Mobile 6.5.3 (December 2025). In
[February 2026](https://postmarketos.org/blog/2026/02/26/pmOS-update-2026-02/), bshah
joined postmarketOS as Trusted Contributor, working on Fairphone 5 call audio. When he
patches ModemManager he writes: *"this work will benefit @phosh or any other #LinuxMobile
project using ModemManager."* One developer. Multiple projects. All benefit.

---

### [Mobian](https://mobian.org)

Debian on mobile. Mainline kernel only. Every device patch upstreamed to Debian.
[Mobian 13 / Trixie](https://mobian.org) (October 2025): kernel 6.12, Phosh 46.0,
Plasma Mobile 6.3. When Mobian adds device support it lands in Debian and benefits every
downstream distribution.

---

### The Shared Infrastructure Nobody Talks About

**Aleksander Morgado** — primary ModemManager maintainer. The reason calls and mobile
data work at all on Linux phones. Shared by every project. That is what infrastructure means.

**Caleb Connolly** — mainlining Qualcomm Snapdragon SoCs for postmarketOS.
[FOSDEM 2022: "From Android to mainline on the Snapdragon 845"](https://fosdem.org/2022/schedule/event/smartphones_mainline/).
Every driver upstreamed runs on every distro. Permanently. No vendor negotiations.

**Mike Gabriel** — packaging Lomiri for Debian since 2021. 135 packages. 215 issues
resolved. Lomiri in Debian 13 Trixie stable. The right model: pull UT components into
the ecosystem rather than keeping them walled in. The one person within UBports' orbit
whose work durably scales beyond Ubuntu Touch itself.

---

## The Original Sin: Inherited from Canonical, Preserved by UBports

To understand Ubuntu Touch's architecture you have to go back to 2013.

Canonical had publicly committed to Wayland. Then, behind closed doors, they secretly
built their own display server called Mir. When they announced it on March 4, 2013, the
response from the Linux display community was immediate and unanimous.

[Phoronix covered the reaction](https://www.phoronix.com/news/MTMxNzY):

**Lennart Poettering** (Red Hat, creator of systemd):
> *"I am sure 'Mir' is going to be a project with a fantastic future, just like bazaar,
> or Upstart, or Project Harmony before it."*

**David Airlie** (X.Org/Mesa, Red Hat):
> *"They should call the next Ubuntu 'Jumping Sharks'."*
> *"I would just say 'ignore mir/canonical and just keep plodding on with wayland'."*

Intel developers removed XMir from their video driver in September 2013:
> *"We do not condone or support Canonical in the course of action they have chosen,
> and will not carry XMir patches upstream."*

GTK added a Mir backend in 3.16. GTK 4 removed it entirely. SDL added Mir support in
2.0.2. SDL 2.0.10 dropped it entirely. Canonical required a CLA for Mir contributions —
contributors signed over IP rights — the opposite of how wlroots built its community.

**April 2017:** Canonical abandoned Unity 8, Ubuntu Touch, and convergence. Pivoted Mir
to IoT. Canonical's own Michael Hall: *"Using Mir simply isn't an option we have."*

The pattern complete:
- **Bazaar** (VCS) — dead. Git won.
- **Upstart** (init system) — dead. systemd won.
- **Mir** (display server) — IoT niche. Wayland won.
- **Unity 8** — abandoned.
- **Ubuntu Touch** — abandoned.

**May 2017:** UBports inherited: a display server the community had rejected four years
earlier, a shell abandoned by its own creator, an Android kernel abstraction nobody else
wanted to maintain, a custom packaging format, and a full custom app suite duplicating
existing FOSS software.

They kept all of it. Every architectural decision. For eight years.

That is not a criticism of UBports as people. It is a description of what they inherited
and chose not to change. Ubuntu Touch is the last place on earth where the mirclient
protocol runs on a phone — not because it is the right protocol, but because it is the
one they cannot fully leave.

---

## Now: Ubuntu Touch — What It Is, Honestly

Ubuntu Touch is a pet project.

Not said with contempt. Said with clarity.

Canonical built it 2013–2017 as a commercial mobile OS. When it failed commercially they
abandoned it. A community of volunteers — the UBports Foundation — picked it up and kept
it alive for eight years on donations and spare time, running 185 biweekly Q&As, shipping
real updates, getting VoLTE working on MediaTek, and caring deeply about it.

**That is admirable.** Genuinely. For users who run it on their Volla or Fairphone, it
works and it means something. The community is warm and real.

But "pet project" has a specific meaning in terms of ecosystem impact. The numbers are
what they are.

---

## The Upstream Contribution Balance Sheet

What did eight years of UBports give to the broader Linux ecosystem?

**Linux kernel mainline contributions: zero.**

Every [UBports kernel repository](https://github.com/ubports) is a downstream vendor
Android kernel fork. Their
[AppArmor backports repository](https://github.com/ubports/apparmor-backports-ut) moves
security patches from mainline *into* vendor forks — the reverse of upstreaming. A
community member [documented the actual kernel work](https://forums.ubports.com/topic/11611/progress-on-kernel-updates)
in November 2025:

> *"Please be aware that this is a tedious process, taking incremental patches from
> upstream kernel.org, applying them, checking conflicts, building them and testing
> them on the device."*

This is maintenance of a downstream fork. It does not move mainline Linux forward by a
single line. And it is structural — you cannot upstream patches from a 5.4 vendor Android
kernel to mainline 6.12. The API gap is too large. The vendor kernel architecture
guarantees all kernel work stays inside the walled garden. Permanently.

**Wayland/wlroots, ModemManager, PipeWire, BlueZ, GNOME, KDE, GTK, Qt, Phosh,
Plasma Mobile:** zero documented contributions.

**[Halium](https://halium.org):** ~95% of contributions
([their own 2023 figure](https://en.wikipedia.org/wiki/Halium)) — their one genuine
ecosystem contribution. In 2017–2020 this was meaningful. But by 2018 bhushan shah was
[publicly documenting](https://blog.bshah.in/2018/03/26/plasma-mobile-and-open-devices/)
that vendor kernels *"generally range from version 3.4 to 3.18 — most already marked as
EOL on kernel.org."* In December 2020,
[KDE formally dropped Halium](https://plasma-mobile.org/2020/12/14/plasma-mobile-technical-debt/):

> *"Maintaining this was always an uphill battle. Most of these components needed to depend
> on the binary blobs provided by the device vendors, required various device-specific
> quirks or hacks that cannot be upstreamed."*

postmarketOS never used Halium. Mobian never used Halium. By 2020, UBports was alone,
and their [own dev acknowledged it](https://forums.ubports.com/topic/5307/kde-plasma-mobile-is-dropping-halium):

> *"UT was/is the only project that really invests in Halium... If UT continues to be the
> only contributor then we might take over the repositories and just maintain it inside
> UBports."*

Halium was a helpful beginning that became a misleading direction. The ecosystem used it
as a signal to head toward mainline. UBports used it as a permanent home. The bridge
became the destination.

**Lomiri via Mike Gabriel's Debian packaging:** genuine. Lomiri is now in Debian 13,
NixOS 24.05, Rhino Linux 2025.4, available on postmarketOS.

From a [commit count documented on their own forum](https://forums.ubports.com/topic/11377/why-is-wayland-compositor-and-lomiri-so-far-in-terms-of-functionality-compared-to-compiz-and-unity7-released-some-20-years-ago/9):

> *"roughly 18000 commits between 2013 and 2017 (end of Ubuntu involvement) and 1400
> commits between 2018 and 2025."*
> *"I think that a large part of these 1400 commits are just translations."*

Lomiri is 93% Canonical's abandoned codebase. UBports added ~7% over 8 years.

**The full accounting:**

| Contribution | Direction | Who actually benefits |
|---|---|---|
| Halium (2017–2020) | Built for sharing | Droidian only by 2026 |
| Kernel backports | Upstream → EOL vendor fork | That one device only |
| Lomiri in Debian (Mike Gabriel) | UT → Debian packages | Debian, NixOS, Rhino, pmOS |
| Custom apps, browser, Click packages | Internal | Nobody outside UT |
| ModemManager / wlroots / PipeWire | None found | — |
| Phosh / Plasma Mobile contributions | None found | — |

Net upstream contribution to shared Linux mobile infrastructure beyond Halium
and Mike Gabriel's Debian packaging: approximately zero.

---

## "Compatibility Means Bloat and Compromise"

[Q&A 175, October 2025](https://ubports.com/blog/ubports-news-1/ubuntu-touch-q-a-175-3976),
core dev Marius, on Flatpak:

> *"Compatibility means bloat and compromise."*

This one sentence explains every downstream consequence. When a lead developer frames
ecosystem compatibility as the enemy, everything follows: custom browser instead of
Firefox, custom apps for every function, a packaging format no other project uses,
standard Linux apps as second-class requiring containers, Flatpak blocked while a
community member builds NixManager to add it anyway — because users need it regardless.

It is not a resource problem. It is a philosophy problem. And it starts at the top.

---

## The Architectural Ceiling They Cannot Escape

[Q&A 178, November 2025](https://ubports.com/blog/ubports-news-1/ubuntu-touch-q-a-178-3982):

> *"We are not going to go Wayland only because that would mean a lot of functionality lost."*

Standard Wayland is the 2026 baseline for Fedora, Ubuntu, Debian, postmarketOS, Phosh,
and Plasma Mobile. UBports explicitly ruled it out because their Mir-based confinement
model depends on Mir-specific extensions with no standard Wayland equivalent. They
[introduced Miroil in 2021](https://forums.ubports.com/topic/5222/introducing-miroil) to
bridge this. The Mir team lead who proposed it called it "very low priority." Five years
later it is still not complete. Standard Linux GUI apps still need containers on UT.

Same Q&A, their own developer on the codebase:

> *"Unfortunately, lots of the obvious possibilities are held together by glue and
> practically unrepairable."*

[Q&A 185, March 2026](https://ubports.com/blog/ubports-news-1/ubuntu-touch-q-a-185-3992),
on the kernel:

> *"For reference, the Fairphone 5 uses 5.4 kernel. We are pretty happy with 24.04 at
> the moment so there is no rush."*

Linux 5.4: EOL December 2022. Flagship device. 4-year-EOL kernel. "No rush."

---

## 15+ Years of Mobile UX Evolution — Ignored

Android's UI patterns are not aesthetics — they are psychological infrastructure built
through a decade of user testing with billions of people. Muscle memory, learned gestures,
notification hierarchy, information architecture. You don't have to like Android to
acknowledge that fighting those patterns, without being dramatically better, is a losing
proposition.

When the UX critique was raised on this forum, the response was:

> *"Android UI is a mess, but the more time passes, the more it adopts Unity design language."*

and:

> *"Just go use Android if you want something like that."*

No user research. No usability data. No engagement with the argument.

Phosh understands this. It does not copy Android but respects learned patterns: swipe
down for notifications, simple gesture navigation, straightforward app drawer. Humble
about what users already know. Lomiri's Unity8 paradigms — stage hints, edge swipes,
the launcher behaviour — are a 2013-era Canonical design language that never gained
widespread adoption even when Canonical was pushing it commercially with a dedicated
professional UX team.

---

## AppArmor Confinement: Where Standard Linux Tools Go to Die

UBports maintains their [own AppArmor backports repository](https://github.com/ubports/apparmor-backports-ut)
because vendor Android kernels don't ship AppArmor 3 — every port requires manually
backporting security patches into EOL vendor trees. A recurring per-device tax.

AppArmor's default confinement on UT blocks FUSE mount syscalls by design. No FUSE means:

- No SSHFS — mount a remote server over SSH, one command on any standard Linux
- No rclone mounts — S3, Google Drive, Nextcloud as local filesystem
- No AppImage support — requires FUSE loop mounting
- No overlayfs build tooling
- No sandboxed developer environments

On Debian, Mobian, postmarketOS: a developer runs all of these with no elevated privileges
because unprivileged FUSE has been in the Linux kernel since 4.18 (2018). On Ubuntu Touch,
AppArmor denies the underlying syscalls — not as a deliberate security tradeoff, but as
an architectural consequence of running on EOL vendor kernels where you cannot safely
expose the full kernel API surface.

Windows has had FUSE-equivalent support via WinFSP since 2015. Linux has had it since
2005. Ubuntu Touch, a Linux derivative, cannot do what Windows has done for a decade.

This is why professional developers do not target Ubuntu Touch. The platform removes tools
they depend on at the kernel level, and there is no roadmap to fix it because fixing it
requires the mainline kernel they do not have.

---

## The Browser: Six Years of Evidence

A [Mozilla Discourse thread](https://discourse.mozilla.org/t/reviving-firefox-for-ubuntu-touch-in-2025-new-perspectives/142861)
requesting native Firefox for Ubuntu Touch was opened August 2019. Revived April 2025.
Still no official port in 2026.

[Q&A 182, January 2026](https://ubports.com/blog/ubports-news-1/ubuntu-touch-q-a-182-3989):
*"A new Morph browser Click package based on Qt6 has landed... it unfortunately weighs
in at 300 MB. Hopefully within months."* Requires LVM partition resizing. In 2026.
To ship a browser update.

The "ad blocking" solution (uAdBlockNG) is a DNS hosts-file blacklist — useless against
YouTube ads, integrated native ads, or first-party ad networks. Not an extension.
Not comparable to uBlock Origin.

Community volunteers built [uFirefox](https://gitlab.com/debclick/uFirefox) (Firefox 143)
and [uWolf](https://open-store.io/app/uwolf.chromiumos-guy) (Librewolf). The community
identified the right answer in 2019. The core team spent six years maintaining the
wrong one.

---

## The Custom App Stack: A Parallel Universe Nobody Asked For

- **Custom calculator, calendar, email, clock, gallery, music player, notes, file manager**
  instead of GNOME/KDE apps with decades of combined development.
- **Click packages** — a third packaging format on top of Snap and apt, used by no other
  project on earth. Even Mozilla declined to maintain them.
- **Libertine containers** — a custom solution for running "desktop" Linux apps, because
  standard apps don't work natively under Lomiri's confinement model.
- **Lomiri/Unity8** — abandoned by Canonical in 2017, gaining some traction in Debian and
  NixOS (genuinely positive), but Phosh and Plasma Mobile solve the same convergence
  problem with larger contributor bases and standard Wayland.

---

## The Lomiri Roadmap Quietly Admits Everything

The [official Lomiri roadmap](https://ubports.com/lomiri-roadmap) targets:
- **Q1 2026:** "Full Desktop Readiness" — Lomiri selectable from Debian installer
- **Q4 2026:** "Enterprise Readiness" — tablets and laptops with touchscreen

This describes Lomiri on **standard Debian with mainline kernels.** Exactly what critics
have asked for. But this roadmap is for *Lomiri on Debian* — not Ubuntu Touch. Ubuntu
Touch has no equivalent milestone. Their own enterprise vision for UT is
["not over the next three years."](https://ubports.com/blog/ubports-news-1/ubuntu-touch-q-a-178-3982)

They know what the correct architecture is. They are building it. Just not for their own OS.

---

## Five Devices

Eight years. Five fully functional daily-driver devices out of 84 listed on the
[UBports device page](https://devices.ubuntu-touch.io).

postmarketOS: 723 device ports, generic mainline kernels, three desktop environments
simultaneously, systemd, NLnet/NGI funding.

---

## The Comfort Trap

The opportunity cost is invisible inside the UT community because they only measure their
own output. They cannot see the counterfactual — what those same developer-hours would
produce directed upstream.

The community generates just enough warmth and mutual validation to make people feel
productive without moving the needle on the hard problems. [Q&A 182](https://ubports.com/blog/ubports-news-1/ubuntu-touch-q-a-182-3989)
headline items include an app for cataloguing watch collections, a French newspaper reader
built by Claude AI tested on one device, and a QR code generator — in the same session
where Halium 16 has nobody working on it and the flagship device runs an EOL kernel with
"no rush" to fix it.

Shipping a new calculator theme registers as progress. It isn't. It is activity mistaken
for momentum.

The brutal irony: UT's own flagship argument — convergence, a real Linux desktop in your
pocket — requires mainline kernel support, proper Wayland, real package management, broad
hardware compatibility. Exactly the things being deprioritised. The project is decorating
a house with no foundation, and the architects know it — they are designing a better house
on the Lomiri roadmap page, for a different OS, on the correct foundation they never
applied to this one.

Mobian, postmarketOS, and KDE Plasma Mobile are building that foundation. Every kernel
patch upstreamed, every device tree merged, every Phosh widget contributed back — that
work compounds and benefits the entire ecosystem permanently.

---

## So: Should You Use Ubuntu Touch?

**Yes, if:** you enjoy the experience for its own sake, a Volla or Fairphone works for
you, you want to be part of a warm and close-knit community, you enjoy maintaining
interesting software history. You want to run model trains, not build railways.

**No, if:** you want your contributions to move the needle on Linux mobile broadly, you
want to upstream kernel support for new hardware, improve Wayland for all phone users,
ship apps that work everywhere, or be part of something that compounds at the ecosystem
level.

In that case: **[postmarketOS](https://postmarketos.org), [Phosh](https://phosh.mobi),
[KDE Plasma Mobile](https://plasma-mobile.org), [Mobian](https://mobian.org).**
Listed at the top of this post.

---

*Every claim in this post is sourced to primary documents. All quotes are verbatim from
official Q&A transcripts, forum posts, and published sources.*

*Written by a former Ubuntu Touch user who wanted it to be something it was never
trying to be — and who has nothing but respect for the people who built it.*