Quick Answer: The Molly Signal fork has not shipped a release since 31 July, according to a discussion on PieFed. The poster says it still lacks security fixes that landed in mainline Signal 8.27. If you use it, check its release history yourself, then decide whether to move to the official Signal APK (kept current with an update tool such as Obtainium) or to Signal-FOSS.
If you installed the Molly Signal fork because you wanted a privacy-focused Signal client, you probably assumed updates would keep coming. That assumption is now in question. A thread in the r/ysk community, cross-posted from PieFed, makes a specific claim: Molly's latest release is v8.19.2-4 from 31 July, and it is missing a fix that mainline Signal shipped in 8.27.
I can't independently confirm the exploit details, and you shouldn't take my word or the poster's alone. What I can do is walk through what the thread reveals, why people run Molly anyway, and how to switch without losing notifications.
What the update gap actually means
Forks live or die by how fast they track upstream. Signal's Android client changes often, and a fork has to rebase its patches on each release. When a fork goes quiet, every security fix in upstream becomes a gap it has to close manually, and that work tends to pile up.
Here's the practical problem. Molly's distribution channel is the same one its users rely on. If the fork doesn't publish a new APK, your phone keeps running the old code, even after the upstream fix is public. A three-month gap in a messaging app is long enough for public write-ups to appear, so attackers have time to read the diff.
The thread's claim is that the fix shipped in 8.27 and was disclosed in October. Treat that as the poster's account. Before you act, check the Signal release notes and the Molly repository on GitHub (github.com/mollyim/mollyim-android) to see whether the fork has published anything since July.
Why people run Molly in the first place
Most commenters in the thread weren't running Molly for fun. Three reasons came up again and again.
First, UnifiedPush. Signal's official Android app depends on Firebase Cloud Messaging (FCM), which is Google's push service. On a degoogled phone, that dependency means either a Google-free push route or no timely notifications at all. One commenter ran Molly specifically to get UnifiedPush support. Another said Signal worked fine with microG on a GrapheneOS phone, but that the push still flowed through Google's infrastructure in some setups.
Second, Play Store independence. Some people don't want Google Play on the device, and Signal's Play listing is the only route they see. The thread points out that Signal's website does offer an APK, so this reason is weaker than it looks.
Third, multi-device use. Older Signal versions only allowed one Android phone per account, so people used Molly to run a phone and tablet side by side. That's changed. Signal now allows Android phones to be linked as secondary devices, and one commenter confirmed it. Here's the catch, though: the limit is two devices, not unlimited.
Most people stop here and assume Molly's remaining advantage is UnifiedPush. That's only partly right. For many users, the reasons to stay on Molly have shrunk, while the cost of running an unmaintained fork has grown.
The "just use Signal" advice is incomplete
The lazy answer in the thread is "Why run Molly when Signal is right there?" That's the common advice, and it's incomplete in two ways.
Yes, mainline Signal is current. But on a Play-free device, the APK on signal.org doesn't auto-update the way Play does. You have to fetch new builds yourself, or use a tool that does it for you. That's where the work sits.
The good news is that the official build has a documented update endpoint. According to the thread, the download page fetches updates.signal.org/android/latest.json, which points to the current APK. Any periodic update service that can read a URL can use that file. Obtainium is the tool most commenters named.
The counterintuitive point is this: a fork can feel safer because it's "the privacy version," but its security depends entirely on how quickly it ships. Official Signal's update cadence is the more reliable signal here.
This next part matters more than it looks. Signal's official APK doesn't use the same push path as Molly. Standalone APK builds support a WebSocket connection, which avoids Google's FCM but polls differently, and you don't get UnifiedPush from the official build at all.
Comparing your realistic options
Here's how the main choices stack up, based on what the thread describes. Check each project's current status before you commit.
| Option | Update channel | Push without Play Services | Main trade-off |
|---|---|---|---|
| Molly (mollyim) | Manual APK releases; last noted release 31 July | UnifiedPush and blobfree FCM, via MollySocket | Possible security lag; MollySocket adds a server-side device |
| Official Signal APK + Obtainium | Signal's latest.json feed, polled by Obtainium | WebSocket, no UnifiedPush | You manage updates yourself; no UnifiedPush |
| Signal-FOSS (Twinhelix) | Automated patch builds | WebSocket and UnifiedPush support | Third-party build; you trust its maintainer's patches |
| Signal from Google Play | Automatic | FCM | Requires Google Play Services |
Signal-FOSS is worth a closer look. One commenter described it as a deblobbed build that removes Firebase messaging and maps, adds UnifiedPush, and keeps automated patch updates. Another commenter said they planned to switch to it. It does not remove payments with MobileCoin, and the thread notes that MobileCoin has little exchange support, so it's a minor point for most users.
The UnifiedPush trade-off nobody mentions
If you do want UnifiedPush, go in with eyes open. A commenter who measured the effect on a Pixel 8a running GrapheneOS reported that UnifiedPush polls about once a minute. That means a notification can arrive up to a minute late. The same commenter found that a WebSocket build used about 3% of battery over 12 hours idle with airplane mode and Wi-Fi on, and noted that the cost mostly matters for people who rarely open Signal.
The bigger issue is architecture. UnifiedPush requires the Signal server to support it, and Signal's servers don't officially do so. That means you either self-host MollySocket or trust someone who runs it. MollySocket registers as another device on your account. The thread says it discards the decryption key and receives only a "you have a message" signal, but the commenter who said so admitted they hadn't researched it deeply. Treat that as an unverified claim, and remember that every extra device is more attack surface.
Here's the trade-off in plain terms: UnifiedPush saves you Google's push service, but you pay for it with delayed notifications and an extra server in your threat model.
How to switch safely
If you decide to leave Molly, do it in this order.
- Back up first. Export your chat history through Molly's own backup feature, and confirm you can restore it before you uninstall anything.
- Get the APK from the official source. Download it from signal.org/android/apk, not from a search result. The thread warns that some hidden or mirrored APKs circulate, so check the source.
- Verify the signature. Use the Verified-Apps tool from PrivacyGuides to check the APK's signature before installing. The thread says that before this kind of tool existed, checking a signature was obscure work.
- Set up automatic updates. Point Obtainium at Signal's
latest.jsonfeed so you aren't relying on memory to fetch new versions. - Test notifications. Send yourself a message from another device and check the delay. If you need UnifiedPush, decide whether a short polling delay is acceptable before you rely on it.
Once Signal is running, check whether the secondary-device link works for your tablet or second phone, since that was the main reason some users stayed on Molly.
Caveats and what could change
Three things could change this picture. The Molly maintainers could publish a release, which would reduce the update-lag concern. Signal could add official UnifiedPush support, which would remove the main reason to run a fork. Or a new vulnerability could surface in Signal's official build, which would matter to everyone equally.
The thread also points to a related effort: a git-carrier project from the Molly side, which the poster said had been released about a month before the discussion. Whether that changes Molly's release cadence is still unknown.
Frequently Asked Questions
What is the Molly Signal fork?
Molly is an independent fork of the Signal Android app. It adds features such as UnifiedPush support and blobfree Firebase messaging, and it removes some Google dependencies. Its value depends on how quickly it applies upstream Signal security patches, which is the concern raised in the thread.
How do I update Signal outside Google Play?
Download the APK from signal.org/android/apk, verify its signature, then point an update tool such as Obtainium at updates.signal.org/android/latest.json. That lets the tool check for new versions automatically without relying on Google Play.
Why does Molly stop getting updates?
Forks depend on volunteers or small teams to rebase patches onto each upstream release. When maintainers are busy or leave, releases slow down, and security fixes from upstream can sit unapplied for months.
Is the Molly Signal fork safe to use right now?
It depends on whether the fork has shipped the latest upstream security fixes. Check its release history and Signal's release notes. If the gap is real, as the thread claims, moving to the official Signal APK or Signal-FOSS is the safer choice.
Can I use Signal on two Android devices at once?
Yes. Signal now supports linking Android phones as secondary devices, with a limit of two. Earlier versions didn't allow this, which is one reason people once switched to Molly.
If you rely on Molly today, don't wait for a dramatic failure to revisit that choice. Check the last release date, compare it against Signal's current version, and test the switch on a spare account. Pass this to anyone wrestling with the Molly Signal fork on a Play-free phone, and ask them to confirm the update date before they trust it.