# Is iodéOS the best alternative to DivestOS?

**URL:** https://discuss.privacyguides.net/t/is-iodeos-the-best-alternative-to-divestos/33857
**Category:** Questions
**Created:** 2025-12-15T13:46:41Z
**Posts:** 38

## Post 1 by @headphone — 2025-12-15T13:46:41Z

DivestOS used to be recommended and it looked like a good option for anyone who couldn’t get a Pixel or had to use an older Android. It has been a while since it ended development and Privacy Guides still only has the GrapheneOS recommendation so I am looking for alternatives myself. It looks like most people here don’t prefer [LineageOS](https://discuss.privacyguides.net/t/lineageos-android-rom/15404) or [/e/OS](https://discuss.privacyguides.net/t/e-os-murena-and-fairphone/13184) but opinions on [IodeOS](https://discuss.privacyguides.net/t/opinions-on-iodeos/29300) are not clear. The accepted answer is just a large comparison chart that is hard for me to interpret so I wanted to ask more directly if IodeOS is now the next best option after GrapheneOS?

I see people in other threads claiming anyone can afford a Pixel if you just buy used but that isn’t true everywhere. There are many countries where most people have to use outdated Samsung or Chinese phones. Even getting an old Pixel can be too expensive or rare to find.

---

## Post 2 by @anon39279085 — 2025-12-15T13:51:50Z

yeah it seems the general consessus is if a Pixel simply cannot be an option, feel free to get a phone and try using LineageOS or iodeOS, better yet just get an android phone and debloat it if you got that capacity, Im hoping to work on a guide but I am getting a little indecisive lately so idk when will that be.

---

## Post 3 by @hydride — 2025-12-15T15:00:48Z

Any major OEM with original operating system is better than iodéOS, /e/OS, or LineageOS. Especially phones from profitable companies which claimed to be focused on privacy like Murena and Jolla(they spread misinformation about GrapheneOS).

---

## Post 4 by @anon63378630 — 2025-12-15T15:01:41Z

> [@hydride](#):
>
> just disable it

this is useless and arguably harmful

---

## Post 6 by @Anvil — 2025-12-15T15:12:49Z

> [@headphone](#):
>
> I wanted to ask more directly if IodeOS is now the next best option after GrapheneOS?

I think the reason you haven’t seen an easy answer to this is because it depends on who you are, what your needs are, and what your threat model is. Without GOS, there’s not really an easy recommend for everyone because GOS is just so much better than everything else. For regular people with a low threat model, I would be inclined to say look for anything you can find that GOS still allows you to install GOS on and make use of GrapheneOS extended support which provides software updates but not firmware updates. Even without firmware updates, the privacy is going to be better than anything else out there and the security will still likely be better than most if not all of the alternatives.

If a pixel with GrapheneOS is truly an impossibility, major phone manufacturers with stock android are likely going to be the better option for security and usability over custom ROMs. Degoogled ROMs like the ones you mentioned are significantly less usable than GrapheneOS because they don’t have sandboxed google play services. So it depends on what apps you need. These ROMs are also significantly less secure than stock android and GrapheneOS because they tend to lag behind on updates and I don’t believe any have verified boot.

As for which of the ROMs are best, I would probably personally lean towards LineageOS because it is just the most well established option and I believe the most private as well.

---

## Post 7 by @anon63378630 — 2025-12-15T15:18:35Z

> [@Anvil](#):
>
> GrapheneOS extended support

These were recently delisted from the website since they are all over afaik.  
Pixel 6 at minimum is necessary but EOL in October. Best to get at least an 8 so you have MTE.

---

## Post 8 by @Anvil — 2025-12-15T15:19:25Z

> [@anon63378630](#):
>
> These were recently delisted from the website since they are all over afaik.

Oh wow I checked just the other day and they were still there. Never mind OP.

In that case, I would say, if GOS is not an option and security matters at all or the apps you need won’t work without google play services → stock android

If security and usability don’t matter and you just want the most private (purely in terms of OS-level snooping) non-GOS option → likely LineageOS is best

---

## Post 9 by @null — 2025-12-15T15:43:11Z

What about [AXP.OS](https://axpos.org/) do you know anything about them?

---

## Post 10 by @anon63378630 — 2025-12-15T15:54:02Z

They’re still on Android 13 afaict.

edit: it looks like they’re about to switch to 15 soon.

---

## Post 11 by @hydride — 2025-12-15T19:31:29Z

Only the latest Android version can get full security patches, I don’t understand why staying at older versions is an advantage.

---

## Post 12 by @null — 2025-12-15T21:06:27Z

Why are you asking me?

---

## Post 13 by @ignoramous — 2025-12-15T21:56:17Z

> [@hydride](#):
>
> Only the latest Android version can get full security patches

This is a misconception that mostly stems from OEMs dragging their feet in supporting frequent Over-the-Air updates (it is expensive, especially if multiple devices across multiple AOSP versions need to be supported by large OEMs).

The Android Security team promises to push out security patches [every month](https://source.android.com/docs/security/bulletin/asb-overview), including backporting it. On any (certified) Android, the security patch level information is useful to verify just how removed one’s installation is from the current patch level.

Since Android 8 (or whenever _Project Treble_ was rolled out), Google has sought to make it easier for OEMs to update the Android Commons Kernel/OS separately from breaking any vendor-specific modifications.

And since Android 10, some of the core AOSP components (like the Android RunTime) have been independently updatable (that is, without the involvement of OEMs). I think, may be I’m wrong, OEMs and silicon vendors can (have?) adopt the same setup Google follows for their own components, including device drivers.

---

## Post 14 by @anon12918199 — 2025-12-15T22:28:41Z

Google definitely makes it pretty confusing for what Android versions get security updates and yeah it’s then up to OEM’s to distribute it. According to [Android OS | endoflife.date](https://endoflife.date/android) Android 13 is the oldest version to still get updates which checks out with Google’s last security bulletin. It seems like Android 13 will be EOL soon, so moving to 15 is a good call.

---

## Post 15 by @anon63378630 — 2025-12-15T22:46:51Z

> [@ignoramous](#):
>
> This is a misconception

Google does not backport all security patches, only high and critical.

> [@ignoramous](#):
>
> update the Android Commons Kernel/

Google barely bothers to fully utilize the latest GKI on their own Pixels last I checked.

If you’re not on Android 16 QPR2 right now, you’re missing patches.  
If you’re running GrapheneOS (security preview channel) right now, you get patches that aren’t going to be released until June 2026.  
I strongly urge people to move to either of those, preferably the latter.  
The situation is downright abysmally horrendous.

---

## Post 16 by @ignoramous — 2025-12-16T08:18:37Z

> [@anon63378630](#):
>
> Google does not backport all security patches

_High_ & _Critical_ seem to cover a fair ground for the parts that Google maintains (ACK/GKI + Framework/Platform)? I haven’t been following, but do _Moderate_ and _Low_ end up being a severe concern, especially post Stage Fright (Android 6+) and sandboxed HALs (Android 8+)?

At least from experience, the OEM I worked for (Bender/Cupcake through to Marshmallow), did contract silicon/SoC vendors to backport most if not all patches, while the OEM also had a dedicated team working across the entire framework & platform (including the Kernel & parts of BSP) evaluating and even making patches (interestingly, some of these people now work on AOSP at Google in leadership positions, with one of them in charge of ACK/GKI…). In several high-profile cases though, it was the vendor themselves who had to be patching their own code, anyway.

> [@anon63378630](#):
>
> Google barely bothers to fully utilize the latest GKI on their own Pixels last I checked.

I always thought Google built GKI for other SoC vendors… as they themselves never had to convince their own selves shipping latest Kernels to Pixels? That said, _latest_ GKI may also not be the most stable version out there for the combination of drivers a Pixel or any device may need to support?

---

## Post 17 by @anon63378630 — 2025-12-16T11:14:15Z

> [@ignoramous](#):
>
> severe concern

Given the new prolonged patch gap, these are only making it easier for attackers.

> [@ignoramous](#):
>
> _latest_ GKI may also not be the most stable version

I should clarify, I didn’t mean latest branch, but patch level.  
For example (on the Pixel 6):

- [kernel.org](http://kernel.org) is shipping 6.1.159
- GrapheneOS is shipping 6.1.158, which is/was the latest GKI revision
- Google is shipping 6.1.145, from July 2025

---

## Post 18 by @headphone — 2025-12-16T15:03:41Z

> [@Anvil](#):
>
> These ROMs are also significantly less secure than stock android and GrapheneOS because they tend to lag behind on updates

Isn’t it better to use a custom ROM on a phone no longer receiving updates from the manufacturer? Even the cheapest phones still receiving updates like the Samsung Galaxy A03 and A04 receive security updates every [3-6 months](https://security.samsungmobile.com/workScope.smsb), but IodeOS receives them in [2-4 weeks](https://eylenburg.github.io/android_comparison.htm) and LineageOS receives them in 1-2 weeks. Or am I misunderstanding?

> [@Anvil](#):
>
> and I don’t believe any have verified boot.

LineageOS doesn’t but IodeOS supports it when the device supports it. I’m confused about /e/OS.

> [@Anvil](#):
>
> As for which of the ROMs are best, I would probably personally lean towards LineageOS because it is just the most well established option

I think LineageOS is definitely better if your device can’t support verified boot with IodeOS, but for devices supporting it I guess we have to choose between quicker updates with LineageOS or verified boot with IodeOS.

---

## Post 19 by @Anvil — 2025-12-16T15:33:48Z

> [@headphone](#):
>
> Isn’t it better to use a custom ROM on a phone no longer receiving updates from the manufacturer?

Probably, yes. I was assuming the devices you were talking about were still supported by the manufacturer.

> [@headphone](#):
>
> I think LineageOS is definitely better if your device can’t support verified boot with IodeOS, but for devices supporting it I guess we have to choose between quicker updates with LineageOS or verified boot with IodeOS.

Yeah, not sure how the math works out on that one to be honest

---

## Post 20 by @Cyber-Typhoon — 2025-12-16T15:33:59Z

> [@hydride](#):
>
> Any major OEM with original operating system is better than iodéOS, /e/OS, or LineageOS.

In terms of security there is some advantage. The original operating system doesn’t require to leave the bootloader unlocked.

---

## Post 21 by @anon39279085 — 2025-12-16T15:42:59Z

But in privacy unless you wanna go to the debloating route that’s a no

---

## Post 22 by @Cyber-Typhoon — 2025-12-16T16:56:49Z

Yes, I think is kind of the pick your poison situation.

---

## Post 23 by @ignoramous — 2025-12-17T20:01:26Z

> [@anon63378630](#):
>
> - GrapheneOS is shipping 6.1.158, which is/was the latest GKI revision
> - Google is shipping 6.1.145, from July 2025

Gotcha. Can’t remember where Daniel Micay mentioned it, but he’s said something along the lines of … the reason Pixel’s Kernel trail GrapheneOS is because Google doen’t trust the latest patch level to be stable enough. And so, they are rather conservative about moving up.

That said, now that I think about it, if Google is withholding security related changes by not moving to latest ACK/GKI… that sounds like a _drastic_ decision, indeed, and one they may not have made lightly (I hope). Do they port just the security patches over to the older Kernels they ship?

> [@anon63378630](#):
>
> these are only making it easier for attackers.

I looked at AOSP’s documentation on severity levels ([link](https://source.android.com/docs/security/overview/updates-resources)), and in my (rather uninformed) opinion, high & critical seem to cover enough ground.

I say that because in the “Moderate” level, I only find `A general bypass for a defense in depth or exploit mitigation technology in a privileged context, THB, or the OS kernel` concerning. That said, and if I read it right, compromising one defense among several “defenses in depth” is not all that severe (even for priv context) and definitely not for _exploit mitigations_ (as these mitigations never addressed the root-cause anyway to absolutely prevent the exploit, as it were).

Genuinely curious about your views on this, and if there’s some stuff that I overlooked.

---

## Post 24 by @anon12918199 — 2025-12-20T21:45:16Z

Just wanted to note that this is exactly what GOS posted about a few days ago: [Trying to understand how system update work on GOS - GrapheneOS Discussion Forum](https://discuss.grapheneos.org/d/28897-trying-to-understand-how-system-update-work-on-gos/15)

In particular “Many high importance privacy and security improvements are not considered bug fixes and not candidates for being backported regardless of severity. Many things would simply be too hard to backport.”

---

## Post 25 by @anon82422799 — 2025-12-21T04:21:35Z

If you are looking for a recommendation, I can hopefully try to help you out. Firstly, I have tried and used both GrapheneOS and LineageOS for microG on a Google Pixel 7, so I do possess some experience with the both of them.

Before I go a bit further, here is a TL;DR: I would either go with GrapheneOS or LineageOS (either the stock vanilla or the microG Lineage builds) and skip /e/ OS and IodeOS altogether unless if there is a feature specific to either one that piques your interest or you have a need for.

Longer Answer:

IF you either currently have a newer Google Pixel or are planning to buy one that will have solid software support for at least the next few years if it is available to you, GrapheneOS is by far your best choice. It’s got a lot of hardening and security improvements, sandboxed Google Play Services, a robust app permissions system, among other [features and improvements](https://grapheneos.org/features) on top of AOSP that you can have a look at on their official website. In addition, it is the official mobile operating system that PrivacyGuides fully recommends. A few minor downsides that I will disclose are that it is on the barebones and basic side when it comes to the preinstalled apps that it has out of the box, and that the project’s developers and community has had a little bit of a rocky background and history. However, those don’t really affect the operating system itself or the security of it, and the developers have done a fantastic job with the project. I would highly consider donating to them to help support the project if you are able and willing, in case you elect to use it.

IF you can’t get a recent Google Pixel or just simply prefer using a different brand or mobile device, then this is where I recommend either the vanilla or microG builds of LineageOS. LineageOS has support for tons of devices and has solid documentation and instructions on how to install it whatever device you have, provided that it is one that Lineage has a build specifically for it. It’s clean, functions well, and provides a really solid experience. In general, LineageOS publishes and pushes out OTA updates in a solid timely manner, and their updater is easy to use. The only downsides that I will note are that it does not have any of the security features or advantages that GrapheneOS has and requires an unlocked bootloader. However, these won’t matter much if you care more about privacy than security and you don’t have a high threat model.

LineageOS for microG is essentially a soft fork of LineageOS from the microG project that publishes builds that have microG preinstalled, which is an open source implementation of the Google Play services that enable better compatibility for apps that rely on it. These are builds that have microG preconfigured and properly set up so that you get full functionality out-of-the box compared to installing microG manually. Between vanilla LineageOS and the microG build, I personally like and recommend the microG variant, but both are really good and just depend on whether you want microG or not.

Why do I not recommend Iode or /e/ OS?

- They are essentially just forks of LineageOS that don’t offer much of anything that is worth using over vanilla and come preinstalled with things that you can install yourself if you wish.
- Both of them lag behind on updates with AOSP compared to LineageOS and GrapheneOS.

Please note that the recommendations reflected in this post are just my own opinions and should not be taken as fact. These are only my own suggestions that I have found work for me based on my own experiences.

I hope that you have a good one, and Happy Holidays!

---

## Post 26 by @null — 2025-12-21T14:56:23Z

I wish we had a alternative to GrapheneOS mainly because if GOS shutdown for one reason or the other we are fucked and has no places to go. We has also seen examples of people who can’t get a pixel in their countries because they are to expensive or something else. I don’t think iodéOS going to be it. If they can’t even keep op with Android releases.

I honesty don’t care if it going to be LineageOS, iodéOS, /e/OS or some DivestOS fork as long they a least is keeping op with Android releases and has some devices with lockable boatloader. I am not asking for much. Everything extra security and privacy related can come after they got the basic in check. I don’t expect them to be as secure as GrapheneOS.

As for the GrapheneOS team’s drama department. I’m honestly pretty numb to it at this point. I can’t take GOS drama serious anymore they are crying wolf way to much. I have used GrapheneOS since pixel 3a and followed them sent the late CopperheadOS days. They have done it sent day one. Every few mouth a new project or dev attacking them. :face_exhaling: I wish they would put as must energy in development as they do on social media.

---

## Post 27 by @ignoramous — 2025-12-21T21:12:14Z

> [@null](#):
>
> GOS shutdown for one reason

They secured £1m from Jack Dorsey only a few years ago. Think they are covered for a while, and I don’t see any danger of this, tbh.

> [@null](#):
>
> As for the GrapheneOS team’s drama department. I’m honestly pretty numb to it at this point. I can’t take GOS drama serious anymore they are crying wolf way to much

At some level, GrapheneOS developers are mostly misunderstood. I’ve found their views to be based on pretty solid security and privacy grounds. It is another thing that such absolutism rubs the pragmatists or realists the wrong way. The arena GrapheneOS operates in is pretty high stakes, anyway, and so there’s bound to be “drama” (like you put it) with or without them.

> [@null](#):
>
> Every few mouth a new project or dev attacking them. :face_exhaling:

As someone who’s been on the receiving end of GrapheneOS developers’ criticism and personally know a couple other AOSP developers who have been, I can tell you that this is all reconcilable. From the pattern I’ve observed, I can tell that the differences stem from whether you’re willing to stand the ground just to push an agenda to sell & position your project, or recognize the shortcomings & potential misleading marketing material on the part of your project.

> [@null](#):
>
> wish they would put as must energy in development

Hm. They are? Their update cadence, as @anon63378630 points out, for GrapheneOS and Vanadium is still as fast as it could be, for example. Software engineering involves a tonne of stuff other than writing code for new features. And the kind of features GrapheneOS wants to implement (app scopes, for instance) aren’t getting any simpler. That said, I do get your point; but from GrapheneOS perspective, they must also defend their choices, community and the project, be it on social media or elsewhere.

For instance, if you ran the GrapheneOS project, could you let such allegations slide?

> [@Thread on r/privacy on Reddit Critical of Privacy Guides Forum](https://discuss.privacyguides.net/t/thread-on-r-privacy-on-reddit-critical-of-privacy-guides-forum/32531/15):
>
> Daniel Micay & the GrapheneOS moderators in particular have been trying to push this narrative for years now, that Privacy Guides is going to randomly change all of our recommendations to iPhone only any second now, because he has some grudge. Why on Earth would we do that?

That said, I agree that pettiness is a waste of everyone’s time, but let’s not forget the roles everyone else plays, in this mud fight, too.

* * *

To your point about other ROMs besides GrapheneOS and the upcoming GrapheneOS phone, I have high hopes for iodéOS and SailfishOS (Jolla), especially since /e/OS & Fairphone have been a disappointment.

---

## Post 28 by @any1 — 2025-12-22T09:15:49Z

> [@ignoramous](#):
>
> SailfishOS (Jolla)

Considering that they ship with Firefox ESR 91 and plan on updating to 102, I don’t.

---

## Post 29 by @anon16234852 — 2025-12-22T09:47:46Z

wt\*??

---

## Post 30 by @null — 2025-12-22T22:35:05Z

> [@ignoramous](#):
>
> They secured £1m from Jack Dorsey only a few years ago. Think they are covered for a while, and I don’t see any danger of this, tbh.

My point was **“if”** something happened to GrapheneOS there isn’t a alternative. It don’t have to be finances lol.

I don’t want anything to happened to GrapheneOS. It’s pretty much a perfect OS for my use case and I would highly recommend them for anyone who ask me.

I have pretty good idea what alternative I could use if needed for most software that I use besides phone OS/ROM it’s a bit blurry.

> [@ignoramous](#):
>
> I’ve found their views to be based on pretty solid security and privacy grounds.

I Agree. I have nothing against GOS giving advice, criticism or help other projects, it’s a good thing. As long it doesn’t have any conflict with set project goal, ideologi, or whatever.

I’m just dumbfounded how they constantly accuses others of harassment with no self reflection. I’m just tried of seen them going from 0 to 100 and crying everyone is out to get them afterwards. It is just like kids in a kindergarten.

> [@ignoramous](#):
>
> The arena GrapheneOS operates in is pretty high stakes, anyway, and so there’s bound to be “drama” (like you put it) with or without them.

I disagree. You don’t see other so called “high stakes“ projects going to project after project keep getting in silly drama like how GOS do.

> [@ignoramous](#):
>
> I can tell you that this is all reconcilable.

Just as a example How would the [Bromite drama be reconcilable?](https://github.com/bromite/bromite/issues/2141) The Bromite developers did nothing wrong.

I’m not going to list every stupid drama GOS have been in. people here probably has one in mind. And I pretty sure someone on the internet probably has already done a better job that I ever could do.

> [@ignoramous](#):
>
> Hm. They are?

Debatable. :laughing:

Edit: Yeah I can see you point on absolutism. I just don’t think it is a excuse for been a a\*\*hole for no reasons and then crying wolf after.

> [@ignoramous](#):
>
> I can tell that the differences stem from whether you’re willing to stand the ground just to push an agenda to sell & position your project, or recognize the shortcomings & potential misleading marketing material on the part of your project.

I’m not sure what you mean by this if you mean people like Rob Braxman. I think as a community as a whole are good at calling bad apples out.

---

## Post 31 by @anon12918199 — 2025-12-22T22:44:56Z

Why are you worried about something happening to GOS if all of their stuff is open sourced? [Source code | GrapheneOS](https://grapheneos.org/source) In theory a new group could fork and take over. I’m not saying it would be easy take over due to the size and complexity of the project, but it’s definitely possible especially as there seems to be a great demand (as I see it) for that type of project.

---

## Post 32 by @null — 2025-12-22T22:51:32Z

I’m not worried about GOS. but we never got a DivestOS fork idk. I just want a safety net, if something **should** happened some day.

---

## Post 33 by @anon39279085 — 2025-12-22T22:58:17Z

I mean…  
(whistles)

idk 4th post? Just saying (as of the time writing).

we do have axp os but we’ll see where it evolves and we definitely need more GOS Based Android ROMs/OSes

---

## Post 34 by @null — 2025-12-23T19:18:44Z

> [@anon12918199](#):
>
> is open sourced? [Source code | GrapheneOS](https://grapheneos.org/source) In theory a new group could fork

I have always wondered why 0 of the new OS’s didn’t use GrapheneOS as base for their OS. Maybe a Android developer can explain it?

---

## Post 35 by @anon12918199 — 2025-12-23T20:24:38Z

I’m curious to hear about this too. I’m not an Android dev, but some factors I would guess are:

- GOS is vast in its scope so it’s more complicated to fork and maintain rather than something that follows AOSP more closely
- GOS aims to replace a bunch of Google services which adds more complexity and cost to try to maintain that forked architecture
- GOS reduces the Android system performance with their hardening. It’d be hard for me to believe that their hardened malloc implementation doesn’t carry some kind of a performance burden otherwise it’d be the default malloc.

---

## Post 36 by @null — 2025-12-23T20:32:46Z

> [@anon12918199](#):
>
> GOS reduces the Android system performance with their hardening. It’d be hard for me to believe that their hardened malloc implementation doesn’t carry some kind of a performance burden otherwise it’d be the default malloc.

Fun fact about this one. We can thanks Techlore for apps isn’t Taking 1-3 second to open anymore. GrapheneOS fixed it after the Techlore, GOS drama.

---

## Post 37 by @Vincent75 — 2026-04-05T12:29:43Z

I generally understand the recommendations, especially the security-related ones. But when it comes to privacy, it doesn’t seem to me that LineageOS blocks trackers, unlike IodéOS and e/os, does it? Which is actually a good thing, though that doesn’t negate the security issues

---

## Post 38 by @trilobyte — 2026-04-05T13:52:41Z

Calyx is supposed to be close to being ready again, relatively speaking. I expect it to be available this year.

> **[CalyxOS progress report - a detailed breakdown](https://calyxos.org/news/2026/04/01/calyxos-progress-update-3/)**
>
> CalyxOS progress report - a detailed breakdown

I’m on LineageOS with a relocked bootloader and a device maintainer that does weekly updates, which seems like a reasonably good solution to me. That’s also niche enough that I can see why it’s not recommended.

Signing the keys myself isn’t that complicated and now each update takes less than 10 minutes, though to learn it was very confusing and took more time. I can provide more information if anyone else is interested in doing this. I wouldn’t go with a fork of a fork when this is an option for me.

With my specific old phone, there are also still vulnerabilities related to wifi and bluetooth. That isn’t great given [I have hearing aids that I keep paired with bluetooth in public spaces](https://discuss.privacyguides.net/t/hearing-aids-and-privacy/35988/4). I think this qualifies as “actually pretty bad,” even if it would technically difficult to exploit these vulnerabilities. Anything we are doing in this type of context is a temporary and partial mitigation suitable at best for low risk situations.

I hope the Motorola deal can bring GrapheneOS to more countries.
