Mobile Progress Report: July 2026
Thunderbird Mobile is moving forward with large steps on both platforms we support. On iOS, we’re working on the very foundation of a new app—our first built from scratch—and continuing to make progress in bringing the Thunderbird for iOS app to the App Store. For Android, it’s a matter of updating what we have in place to make it easier to use, more reliable, and more efficient. Both platforms are rushing forward to deliver exactly what our users expect from us.
iOS
Starting off with iOS, we’ve focused on a few vital components. This includes the compose screen, account drawer, and OAuth, which allows users to add their accounts using the sign in page of their email provider. For the compose view, our HTML rich text editor is coming along nicely. We forked a WYSIWYG repository, Infomaniak’s “swift-rich-html-editor,” to create a rich text view for both composing and editing. We also added view headers, fixed a bug where we weren’t applying links properly to the DOM, and began porting a proof of concept over to the main app code. This will eventually become the compose view for the final app. We also started the technical design phase for the new account drawer design.
Android
The Android team has been busy looking into drastic changes to the app to make it more user-friendly, faster, and more reliable. We’re directly targeting feedback we’ve received. We’re also continuing work on developer-friendly features to make contributing to the project easier and faster.
Database Rewrite
We’ve started our large database refactor with a tentative selection of Room. We chose this for a number of reasons, including performance, easier writing of data entities, and the ease of introduction for new engineers. Room is common in Android development, which means we can more quickly onboard new contributors with it. We’ll have an RFC out by the end of August detailing how we’ll implement the new database.
So why are we rewriting the database? It’s the source of a number of issues with the app. Everything runs through it, from fetching locally-stored drafts, triggering notifications for new messages, syncing, reliability, and even power consumption. By updating the database, we make it possible to drastically improve everything in the app it touches, which is to say, everything.
Feature Flags
Developers will also be happy to know we’re improving the feature flag process. We’ve completed an RFC for a new schema and began work on the technical documentation. We’re looking to develop a local feature flag library that will use OpenFeature and eventually enable remote feature flag management, though that’s not our short term goal. For now, we want to make it easier to create and modify feature flags across build types, without needing to edit so many files to do so. In the future, however, this will make it easier for us to roll out releases, updated features, and even rolling back features that may have issues without having to wait for the app release and approval cycle. It allows us to make a more reliable app with faster feature implementations.
Notifications
Finally, we’ve heard that our users do not like how we handle notifications. We’ve been investigating reported bugs and working to find a path forward that allows us to use previous work to improve notifications.
We’re also looking into a key complaint: setting up notifications and “push” (IMAP Idle) notifications is just too difficult. We don’t make it easy enough for users to set up their notifications and ensure they get email notifications when their email server reports updates. Users have made it clear: that has to change.
We’re currently discussing options with design to consolidate some settings, bring other settings to the forefront, and will be working next month to activate “push” notifications by default for new accounts that support it.
We know notifications are a cause of headaches, even for those who understand how to use the app’s existing features, so we want to address them as quickly as possible. We’ll also focus on identifying issues and helping our users report problems with notifications in detail with user-enabled and anonymous logging that can help us see why a notification did not show for a new email if they want to help us work through it.
Bolt Design Library
Android has also begun the work of moving our Bolt design library out of the app to serve as a standalone library. Currently, we’ve pulled out the foundation layer for mobile that includes fonts, colors, spacing, and other repeated values. Eventually we’ll use WebASM to render the design system and allow contributions directly to the design system, without needing to touch the Android app, potentially allowing it to be platform independent.
Community
Two crashes were caught in the beta, including a crash related to relative date formats and another to webviews. We want to thank our amazing community of beta testers who helped us catch these before they made it to a full release. Our community contributors have also directly fixed bugs, like issues scrolling horizontally in message views, fixing a button that couldn’t be seen properly in dark mode, fixing an issue with the wrong number of messages in confirmation dialogs, and updates to our historical changelog data to be in a more readable and usable format. We can’t thank our community of testers, contributors, and users enough for the work they put in helping us make Thunderbird a better email client.
We couldn’t do what we do without you, and, as always, thank you for being part of the Thunderbird community. Here’s to another month making the best email client we can, together!
– Danielle G. (she/her), Senior Android Engineer
0 responses