Towards a Sovereign Mobile Stack
Recently we’ve seen a growing interest in “digital sovereignty” in European policy circles, both at the EU level and nationally in countries like Germany and France. While there are different interpretations as to what this means in practice, there does seem to be some momentum behind the idea that free software solutions should be adopted as part of it, which would be a big step forward from our perspective.
In this context there’s a lot of talk about a “EuroStack”, an “Open Internet Stack”, or even a “Deutschland Stack”, to replace the proprietary silos of US Big Tech companies. However, looking at existing proposals from a practical lens, one thing looks very off: The software part of all these initiatives is focused around building “sovereign clouds”, with end-user devices barely a consideration.
For example, the “Deutschland Stack” website has a category called “Access”, which lists the three major browser engines, Android, and iOS. This does not make much sense given that Germany has no influence on these technologies. All of them (Mozilla being a partial exception) are funded, developed, and governed by US Big Tech, so there’s nothing sovereign about them. This means that if all their other plans work out they could be left with no way to actually use their sovereign cloud, because they have no sovereign end-user devices.
Looking at the broader software landscape, if you’re interested in sovereignty the problem is not really the server, or even on the desktop. An EU company or government can already go to SUSE, Nextcloud, etc. and get fully sovereign workstations and cloud services from a European vendor. What is completely lacking though is sovereign solutions for phones. There are no comprehensive, competitive alternatives to Google’s Android and Apple’s iOS.
The Digitization Trap
The iOS/Android duopoly is especially problematic because more and more of public life is being tied to the phone. Banking and digital payments, public transport, bike rental or car sharing services, event tickets and reservations, and increasingly even government services tend to require a phone.
It is our position that participation in society should not require having a computer, let alone a phone. It should definitely never require running proprietary software from a specific vendor. We believe that it should not only be possible but easy and seamless to book appointments, take the train, pay for things, etc. in a fully analog, data-minimizing way. This is not only important from a privacy point of view, it’s also a crucial fallback to ensure resilience in case of war, natural disasters, or other crises.
Whether we like it or not, digitization is happening (or has already happened) in a growing number of areas, and phones are at the center of it. Given the current geopolitical context it would seem unwise to do this without making sure there is a sovereign alternative for the most important, and hardest to change, pieces of this infrastructure: The phone operating system and the app platform. Yet unfortunately, that’s exactly where we’re at.
Android and iOS are still largely seen as neutral technology platforms, but by now we’ve seen enough evidence to know that they’re really instruments of US power. They can be turned against individuals, groups, and institutions the US doesn’t like at any given moment. Soon countries might face scenarios like “Give us Greenland, or we turn off all your devices”.
There are two obvious actions here: First, reduce dependency and create resilience by only digitizing things in a careful, optional way that also allows for convenient analog access. And second, build out and start deploying a fully sovereign client stack for phones.
The Modal Stack
While we don’t always talk about it in these terms, we (the Modal team) have spent the past decade building this stack as members of various communities including systemd, GNOME, postmarketOS, and p2panda. When we say our goal is “A free software iPhone” it’s tongue-in-cheek, but only slightly. The stack we’re working on still has rough edges and is not fully ready for deployment, but we’re convinced it’s the most promising path towards a viable sovereign alternative to the iOS/Android duopoly in the long term.
In this post we’ll provide a high-level technical overview of the most important components.
Kernel
The Linux kernel is an obvious choice, given its broad device support and large global developer community. This is important because hardware enablement for phones is especially challenging. Unlike desktops or laptops with x86 CPUs, there’s very little standardization between different ARM devices, and individual phones are usually designed in tandem with the vendor-supplied proprietary software. This makes getting different software running on those devices a very time-consuming process.
Projects like postmarketOS have been working towards running mainline Linux on phones for years, with their community supporting many different devices that originally ship with Android. While the level of support for some Android phones is pretty good, there isn’t yet a device that is supported perfectly. However, this is mostly a resource problem. Given some targeted funding we think it would be feasible to get a few existing devices over the line relatively quickly.
There is of course also the option of working with phone OEMs to build new hardware, but the challenges in bringing up mainline Linux on new devices are similar, because those devices would use similar components.
Longer-term, the process of new devices getting mainline Linux support could be made significantly faster and more sustainable with some changes in public policy. For example, if device manufacturers were required to open their bootloaders and provide device documentation, this would make it much easier to get free software operating systems running on phones. Going a step further, ARM SoC vendors could be required to adhere to a standard for how devices boot, and to allow installing your own firmware, such as coreboot. This would make it as easy to reinstall the OS on phones as it is on desktop computers with x86 CPUs.
System
At the system layer we use the standard Linux userland and free desktop stack, including components like systemd, Wayland, Pipewire, and so on. This is a mature option that is widely deployed across every major Linux distribution.
Obviously phones are not quite the same as desktops or laptops. There are a number of additional things you need, including mobile network integration, on-screen keyboard, emergency calls, audio routing, and push notifications. The good news is that the community has been working on this for the better part of a decade, and many of these pieces are either done or not far off. Here, too, targeted funding could unlock a lot of community potential.
The desktop Linux stack currently lacks some platform security features compared to Android and iOS. The good news is that for the last few years there have been efforts to introduce technologies like immutable systems, atomic updates, TPM-powered encryption, secure enclaves, and code signing. This has been a community-wide push, but systemd’s implementation has emerged as the most comprehensive, so that’s what we’re going with. There’s a lot of ongoing work in this area, and we will see major progress here in 2026 and beyond.
App Platform
The widget toolkit used by apps is the single most important part of the transition to a new user-facing OS stack, because it has the highest switching costs. Porting an app ecosystem to a new toolkit entails rewriting every app more or less from scratch. Worse, it also requires that every app developer re-learns how to do much of their job. This has a powerful lock-in effect, and is a big part of the reason why it’s so hard to imagine moving past iOS and Android.
The question is, what should be used instead? An ideal stack needs to be independent, resilient, and approachable. An established third-party app developer community is a big plus.
Given these goals, we think the GTK/GNOME ecosystem is the best-positioned option by far. It’s a complete, vertically-integrated stack where every component is openly licensed and developed in public by an international community. It supports multiple platforms, can be used with all major programming languages, and there is a vibrant ecosystem of high quality third-party apps. Importantly, most of these apps already work on phones because GNOME’s Adwaita design system and widget library make it easy for app developers to support both desktop and mobile for factors.
App Distribution
App stores, and app distribution technologies more broadly, are another technique that Apple and Google use to enforce lock-in. App stores mediate the relationships between developers and end users, which can be easily abused by vendors for commercial or political goals. A recent, stark example of this is the ICEBlock app being banned to placate the Trump government.
While this is less of an issue on Android compared to iOS today due to the availability of alternative app stores, this is no protection in the long run. Google could change this via software update at any time, and is in fact planning to significantly lock down the Android app ecosystem in 2026.
App stores inherently need to be somewhat centralized, because the centralization provides valuable things like search, discovery, quality control, and reviews for malware. However, there are things we can do to mitigate the potential for abuse of this position, on both a technical and structural level. One important check on this power is using an open, independent packaging format that can be easily distributed via alternative app store infrastructure if needed. Having the app store run by an independent non-profit organization rather than a commercial entity is another.
On Linux, Flatpak is the only realistic option for this, because it’s the only format that is vendor-independent, sandboxed, and works across distributions. Flathub, a community-run app store built on the Flatpak format, is already a solid alternative to the Big Tech app stores. But it’s also easy for anyone to host their own Flatpak repository, preventing lock-in.
There are things that still need work across this ecosystem, such as more and better permission APIs, but there’s ongoing work to close these gaps. More consistent and focused funding could accelerate this.
Networking and Services
In our view, the focus on cloud and server infrastructure is a blind spot in the various “sovereign stack” proposals and initiatives. There are areas where a cloud-centered architecture makes sense, but it also has big downsides in environments where offline support and asynchronous collaboration are important. In those cases, a local-first approach to networking is preferable to relying on the cloud.
Local-first means keeping a full local copy of the data so it’s available offline, but synchronizing across the network when it is available. Cloud infrastructure can optionally be used to improve the quality of service, by providing always-online sync nodes. Because it treats the network as optional, local-first is more resilient against server and network failures, targeted attacks on infrastructure, and other threats.
Local-first technology is still at an early stage, with some of its foundational technologies (like CRDTs) only having become viable recently. However, we believe that for many use cases local-first will become a competitive alternative to the cloud-first software in the coming years. This is why our stack includes local-first sync, powered by p2panda, as a foundational feature. In the medium term we will build a system sync service, so any app can implement collaboration features easily. In order to ensure availability, we’re also working towards an ecosystem of optional always-online sync servers.
How Do We Get There?
The good thing about this stack is that it already exists today, and is slowly getting better and more mature over time. Hundreds of people are working towards this every day, either as volunteers or working for companies with an interest in certain components. There’s a large pool of world-class developers who would love nothing more than to spend more of their time making this happen.
The problem is primarily that there’s not nearly enough funding in some important areas. These are often specifically the ones that are most relevant to mobile, in part because there aren’t yet any commercially available phones based on this stack. This leaves developers to work on these problems only in their free time in many cases, so progress can be slow and is hard to predict.
This is where the public sector could step in. A comparatively small investment in this ecosystem can yield huge results, as the Sovereign Tech Agency’s investment in GNOME in 2023 and 2024 has shown.
Unfortunately, the ideal funding instrument for this kind of thing doesn’t exist at the moment. Open source grant programs like Sovereign Tech Fund, NLnet, or Prototypefund are too small in scope. Research grants like Horizon are too complex and require larger organizations than free software projects typically have. Given the urgency of the problem we think this is something policy makers at all levels should think about.
If you have ideas for how we can make this happen, drop us a line.
