Glad to hear E2EE is coming soon, but it’s been “soon” for probably a year now. It’s a bit odd that encrypted notifications still don’t work, and I’d argue it’s a very big caveat with regard to privacy and security.
Our main reason for using Zulip is that we work in a highly regulated space (healthcare) and would like to be able to safely talk about things. I suspect this sort of situation is a major motivator for Zulip adoption, so it’s weird that transit encryption was left as an afterthought.
(There has always been an option to just not include message content in mobile notifications).
Cryptography is not something you can do sloppily, and requires coordination between the mobile and server teams. Zulip 11.x included the protocol, but while doing the mobile implementation, we decided to make several more changes which have delayed it to the upcoming Zulip 12.0.
Some important context is that we retired the old React Native mobile app this summer in favor of the new Flutter apps (https://blog.zulip.com/2025/06/17/flutter-mobile-app-launche...), which has been an enormous improvement in the quality of the app and developer experience.
But as you can imagine, the cutover and relentlessly addressing feedback after it took a lot of time for the mobile team. We've also experienced an AI slop bombardment in the last few months that has consumed a lot of time. I'll save that story for another time.
What was wrong with React Native that caused it to be slow? How did you figure out that flutter was the reason for improved performance, rather than simply rebuilding the app with lessons learned from the old app?
Put another way, given enough time, what was not possible to do with react Native and is now possible with flutter?
Our main reason for using Zulip is that we work in a highly regulated space (healthcare) and would like to be able to safely talk about things. I suspect this sort of situation is a major motivator for Zulip adoption, so it’s weird that transit encryption was left as an afterthought.